IN3 MOVE

Clean Core ist kein Schalter. Und kein Berater legt da einen Hebel um. Trotzdem wird es oft genau so verkauft. SAP pusht das Thema – für Cloud-Migration, für RISE, für Upgrades. Die Realität dahinter ist komplexer, als es die Marketing-Folien vermuten lassen. Ein konkretes Beispiel: Ein gewachsenes S/4HANA-System. Upgrade für 2 Monate auf dem Schirm. Am Ende wurden es 6. IT-Planung aus dem Ruder, andere Projekte mussten hinten angestellt werden. Grund: Kernmodifikationen am Standardcode und Coding Enhancements. Gewachsen über Jahre, nie aufgeräumt, nie hinterfragt. Von ~20 Modifikationen und einer ähnlichen Zahl an Enhancements waren 80 % gar nicht mehr in Nutzung. Aber das weiß man eben nicht sofort. Wenn Systeme alt und gewachsen sind, erkennt man nicht auf den ersten Blick, was noch gebraucht wird. Diese Erkenntnis braucht man erstmal. Am Ende blieben 4 Modifikationen und 3 Enhancements, die funktional noch aktiv waren. Upgrade abgeschlossen – und dann als Lessons Learned eine Clean Core Strategie aufgesetzt: → Keine neuen Modifikationen → Keine Enhancements im Kern → Z-Programme überdenken → Die Übrigen sukzessive auf die BTP bringen – Side-by-Side Das geht nicht von heute auf morgen. Man muss sich entsprechend technologisch aufstellen, Erfahrung sammeln, Kunden-Coding in die BTP bringen. Der Hauptpunkt: Ab jetzt anders vorgehen. Das ist Mindset, Strategie und Technologie in einem. Und nebenbei: Wer seinen Kern freihält, wird Cloud-ready. In der Public Cloud bist du nur noch Systemnutzer – keine Hoheit mehr übers Coding. Clean Core ist dort per Definition gesetzt. Wie viele eurer Kernmodifikationen sind eigentlich noch aktiv?

26 Bewerber. LinkedIn's AI Rating hat 10 davon als "fit" eingestuft. Die einzigen, die wirklich brauchbar waren? Die hat die AI als "not fit" aussortiert. Völlig daneben. Branchenfremde Bewerber ohne SAP-Erfahrung? "Fit." Kandidaten mit EWM, Logistik und echtem SAP-Background? "Not fit." Die lästige Realität: Der Algorithmus versteht die Branche nicht. Er erkennt nicht, worauf es ankommt. Er sortiert nach Buzzwords, nicht nach Substanz. Ich sehe das ganze AI-Thema sehr, sehr entspannt. So ne KI können wir uns auch sparen. Die Wahrheit ist simpel: Screening funktioniert nicht automatisch. Recruiting ist kein Algorithmus-Problem. Man muss die Leute kennen. Man muss die Branche verstehen. Man muss wissen, wonach man sucht. Und das kann keine AI - zumindest noch nicht. Vielleicht in 5 Jahren. Vielleicht auch nie. Aber heute? Vergiss es. Eure Erfahrungen mit AI-Recruiting? Funktioniert das bei euch besser? Oder ist das überall so ein Desaster?

"Kennt ihr Neptune?" Die Frage stelle wir oft in SAP-Runden. 90% schütteln den Kopf. Dabei ist Neptune einer der interessantesten No-Code-Ansätze für Backend-Entwickler, den ich kenne. SAP Fiori? Zu langsam. Custom-Entwicklung? Zu teuer. Der bisherige Plan: Externes System aufbauen. Mit Schnittstellen. Mit Synchronisation. Mit allen Problemen, die das mit sich bringt. Dann kam Neptune ins Spiel: - Läuft direkt auf dem SAP-System (kein extra Server) - Nutzt die bestehende SAP-Autorisierung - Backend-Entwickler können plötzlich Fiori schreiben - Ohne Frontend-Entwickler, ohne UI5-Drama Das Beste? Die IT-Abteilung entspannt. Die Mitarbeiter zufrieden. Das Management happy. Neptune ist kein Wundermittel. Aber für viele SAP-Szenarien die eleganteste Lösung. Manchmal verstecken sich die besten Tools im Schatten der großen Namen. Arbeitet ihr schon mit Neptune? Oder kennt ihr andere "versteckte Perlen" in eurer SAP-Landschaft?

"Never change a running system" ist einer der gefährlichsten Sätze in der IT. Klingt erst mal vernünftig, oder? System läuft, Prozesse funktionieren, niemand beschwert sich. Warum also was ändern? Das Problem: Wer diesen Satz ausspricht, ist meist schon an einem kritischen Punkt angekommen. Die Lösung läuft, aber vermutlich auf Verschleiß. Erweiterungen? Schwierig. Anpassungen? Riskant. Neue Anforderungen? "Geht nicht mehr so einfach." Unser Ansatz: Wenn ihr an diesem Punkt seid, experimentiert nicht mehr am laufenden System. Plant die Ablösung. Nutzt die Restlaufzeit sinnvoll, aber baut parallel die Zukunft. "Never change a running system" ist kein Dauerzustand. Es ist ein Signal: Zeit für was Neues. Wie geht ihr damit um? Weiterlaufen lassen oder aktiv ablösen?

Code-Qualität? Bitte einmal TÜV für SAP. Bei einem Kunden haben wir SAP-Entwicklungen analysiert, die über Jahrzehnte gewachsen waren mit wechselnden Beratern und Entwicklern, ohne klare Standards. Fehler schlichen sich ein, wurden überspielt, Workarounds zur Norm. Punktuell konnten bestimmte Stellen beim Kunden nicht mehr angefasst werden. Geschäftsprozesse konnten nicht mehr angepasst werden, weil die Seiteneffekte des Codes den Ablauf zu sehr störten. Beim Kunden lief gar nichts mehr. Unser ABAP Code Review durch Sichtprüfung von erfahrenen Entwickler, automatisierte Checks mit Code Inspector und externen Tools, dazu eine tiefgehende Architekturdiagnose schaffte hier Abhilfe. Dadurch legten wir die strukturellen Schwächen im Custom Coding offen. Insbesondere redundantes Coding wurde als Hauptursache identifiziert. Der Ergebnisreport einschließlich der Empfehlungen zur Optimierung dient als Vorlage zur Überarbeitung. Wir prüften und gaben Empfehlungen. Damit neue Fehler gar nicht erst entstehen. Das ist wie bei einem Auto, das noch läuft, aber sein Potenzial nicht ausschöpft: Der Motor könnte effizienter arbeiten, der Verbrauch ließe sich optimieren, und mit dem richtigen Tuning würde es auch steile Anstiege mühelos meistern. Manchmal braucht es einfach den Blick von außen, um zu erkennen, wo noch Leistung schlummert. Mit einem strukturierten Code Review bauen wir die Brücke zurück zur Kontrolle, damit euer System nicht nur läuft, sondern wieder Fahrt aufnimmt. Habt ihr ähnliche Herausforderungen im Custom Coding und wollt Klarheit reinbringen?