Wenn in SAP-Transformationsprojekten über Eigenentwicklungen gesprochen wird,

klingen sie oft wie der größte Risikofaktor:

zu viele, zu komplex, zu undurchsichtig.

Unsere Benchmarks aus über 2.000 analysierten SAP-Systemen zeigen allerdings ein anderes Bild:

Nur rund 15 % der Eigenentwicklungen sind täglich produktiv im Einsatz.

Mehr als die Hälfte wird überhaupt nicht mehr genutzt.

Das eigentliche Problem ist also nicht die Menge der Eigenentwicklungen —

sondern ihre richtige Bewertung.

Drei Perspektiven schaffen Klarheit

Erst die Kombination aus Nutzung, Technik und Risiko liefert ein belastbares Bild darüber,

welche Eigenentwicklungen wirklich geschäftskritisch sind.

Top-Down – die Nutzungs- und Wertsicht

Hier geht es um die Frage:

Welchen tatsächlichen Beitrag leistet ein Programm heute noch im Geschäftsprozess?

Und noch wichtiger:

Ist dieser Beitrag auch für die zukünftige Zielarchitektur relevant?

Diese Perspektive trennt klar zwischen:

• wirklich benötigter Geschäftslogik

• und technischem Ballast, der nur noch im System existiert

Bottom-Up – die technische Sicht

Die zweite Perspektive betrachtet die technische Funktion jeder Eigenentwicklung.

Dabei wird analysiert:

• Welche fachliche Aufgabe erfüllt das Programm tatsächlich?

• Gibt es dafür heute bereits SAP-Standardfunktionen?

• Kann die Logik durch Fiori-Apps oder Simplification-Items ersetzt werden?

Das Ergebnis ist ein konkretes Mapping mit nachvollziehbaren Konfidenzleveln pro Empfehlung.

Security – die Risikosicht

Die dritte Perspektive wird häufig unterschätzt — ist aber oft die kritischste.

Hier geht es um Fragen wie:

• Welche Programme greifen schreibend auf geschäftskritische Daten zu?

• Wo werden Berechtigungsprüfungen umgangen?

• Welche Eigenentwicklungen öffnen potenzielle Manipulations- oder Betrugsrisiken?

Diese Sicht entscheidet häufig darüber,

ob ein Programm überhaupt noch im Produktivsystem existieren sollte.

Zusätzlich entstehen belastbare Fakten für Anforderungen wie:

• ISA 315

• LkSG

• Governance- und Audit-Anforderungen

Das eigentliche Ziel

Am Ende entsteht ein sehr klares Bild:

Ein großer Teil der noch genutzten Eigenentwicklungen kann bereits heute durch SAP-Standard abgedeckt werden.

Übrig bleibt die wirklich erfolgskritische Geschäftslogik —

und genau diese sollte erhalten bleiben.

Unabhängig davon, ob die Zielarchitektur später Public Cloud, Private Cloud oder Hybrid heißt.

Zwei kostspielige Fehler vermeiden

Mit dieser Transparenz lassen sich zwei typische Reflexe vermeiden:

❌ Eigenentwicklungen pauschal für S/4HANA weiterziehen

❌ Mit hohem Aufwand Bereiche restandardisieren, die keinen echten Mehrwert mehr liefern

Stattdessen entsteht eine faktenbasierte Entscheidungsgrundlage.

Minimaler Aufwand auf Kundenseite

Der Aufwand bleibt bewusst gering:

• ein einmaliger Datenexport

• kein Eingriff ins Produktivsystem

• Ergebnisse innerhalb kurzer Zeit

👉 Schreiben Sie mir gerne eine kurze Nachricht.

In einem 15-minütigen Gespräch klären wir, ob dieser Ansatz für Ihre Situation der richtige nächste Schritt ist.