Welche Geschäftsprozesse verändert Ihr SAP-Custom-Code?

Wenn es um die Umstellung auf S/4HANA geht, kommt früher oder später die Frage, welche Prozesse das Unternehmen eigentlich verändert hat. Als Antwort bekommt man meistens eine Liste mit ein paar tausend Programmen, sortiert nach Paket und Namensraum. Damit lässt sich die Frage nicht beantworten. Dafür müsste der Custom Code nach Geschäftsprozess geordnet sein, und diese Zuordnung pflegt in den wenigsten Unternehmen jemand.

Jede Eigenentwicklung hatte einen Grund

Hinter jeder Eigenentwicklung stand einmal eine Anforderung, die der Standard nicht erfüllt hat. Meist war es einer von drei Gründen, und nur der erste macht ein Unternehmen tatsächlich anders:

• Wettbewerbsvorteil. Der Prozess soll bewusst anders laufen als in der Branche üblich.
• Pflicht. Ein Gesetz, der Kollektivvertrag, eine Behörde oder ein wichtiger Kunde verlangt es.
• Lücke von damals. Der Standard konnte es zum Zeitpunkt der Entwicklung nicht. Ob er es inzwischen kann, hat niemand nachgeprüft.

Teuer wird vor allem die dritte Gruppe, weil sie mit den Jahren niemand mehr als solche erkennt. Der Entwickler ist in Pension, das Konzept liegt auf einem Laufwerk, das es nicht mehr gibt, und das Programm läuft jede Nacht. Clean Core hilft bei dieser Frage übrigens nicht weiter: SAPs Stufenmodell von A bis D bewertet, wie eine Erweiterung an den Standard angebunden ist, nicht, ob man sie noch braucht.

Ein Kundensystem, nach Modul geordnet

Einen ersten Überblick gibt die Verteilung auf die SAP-Module. Die Grafik stammt aus der Analyse eines Kundensystems. Wir haben sie anonymisiert und die Werte leicht verändert.

Das System hat rund 3.500 Custom-Programme, fast ein Drittel davon in der Materialwirtschaft. Zusammen mit Vertrieb und Qualitätsmanagement sind es gut zwei Drittel. Ob die 590 Programme im Qualitätsmanagement das sind, was dieses Unternehmen auszeichnet, oder ob sie ein Prüfwesen nachbauen, das der Standard längst abdeckt, lässt sich an der Zahl nicht ablesen.

Dazu kommen 240 Programme im Modul Basis, also Werkzeuge, Schnittstellen und Hilfsprogramme. Bei ihnen muss man erst klären, welche Prozesse sie unterstützen und wer fachlich dafür zuständig ist.

Schon diese Modulsicht liefert das System nicht von selbst. Pakete wachsen über Jahre und Projekte, und in einem Paket für den Vertrieb liegen oft auch Programme, die Materialstämme pflegen oder Buchhaltungsbelege erzeugen. Das Paket sagt also wenig darüber, wozu ein Programm gehört. Sysparency leitet das Modul deshalb aus dem Code ab: aus den Tabellen, die ein Programm liest und schreibt, den Standardschnittstellen, die es aufruft, und der fachlichen Beschreibung, die Sysparency für jedes Programm erzeugt.

Eine Prozesssicht ist das noch nicht. Über zehn Bereiche mit je einem Verantwortlichen lässt sich aber leichter reden als über 3.500 einzelne Objekte.

Vom Modul zum Prozess

Ein Modul ist aber noch kein Prozess. Order-to-Cash läuft durch Vertrieb, Logistik und Finanzwesen, und ein SD-Programm kann zur Auftragserfassung genauso gehören wie zur Reklamationsbearbeitung. Im SAP-System ist die Zuordnung zu Prozessen nirgends hinterlegt. Das ABAP Test Cockpit prüft die Objekte technisch, und Process Mining zeigt den Ablauf, aber nicht den Code, der dahintersteht.

Aus dem Code lässt sich die Zuordnung aber recht gut ableiten. Dieselben Hinweise, die das Modul verraten, führen weiter, also Tabellen, Standardschnittstellen und fachliche Beschreibung. Dazu kommen die Transaktion, über die ein Programm gestartet wird, und wie oft es laut Nutzungsdaten im Produktivsystem läuft. Zusammen zeigt das ziemlich genau, zu welchem Vorgang ein Programm gehört. Sysparency ordnet auf dieser Basis jedes Custom-Objekt einem Modul und einem End-to-End-Prozess zu und beschreibt je Prozess, was gegenüber dem Standard erweitert wurde.

Diese Zuordnung ist ein Vorschlag, den man am Code nachprüfen kann. Ob eine Abweichung einen Wettbewerbsvorteil darstellt, lässt sich aus dem Code nicht ablesen. Das beurteilt der Prozessverantwortliche, der dafür jetzt eine vollständige Liste hat.

Ein Beispiel: Hire-to-Retire

Das folgende Beispiel haben wir konstruiert, die Zahlen sind erfunden. Wer in der Personal-IT arbeitet, wird das Muster trotzdem wiedererkennen.

Ein Unternehmen setzt seit zwanzig Jahren SAP HCM ein. Im Personalbereich sind rund 450 Custom-Programme mit über 700 eigenen Dynpros entstanden: eigene Infotypen, Erfassungsmasken für die Zeitwirtschaft, Auswertungen rund um die Abrechnung. Die Mainstream-Wartung für SAP ERP läuft Ende 2027 aus, optional gibt es Extended Maintenance bis Ende 2030. Zur Wahl stehen SAP SuccessFactors und SAP HCM für S/4HANA. SuccessFactors kennt keine Dynpros, bei einem Wechsel dorthin muss also für jede der 700 Masken entschieden werden, was aus ihr wird.

In der Matrix sieht man, was in einer Objektliste untergeht. Zeitwirtschaft und Abrechnung werden fast vollständig genutzt, und der Grund ist bekannt, nämlich Kollektivvertrag und Betriebsvereinbarungen. Diese Anforderungen müssen auch im Zielsystem erfüllt werden. Ob dafür die bestehende Umsetzung übernommen wird, ist eine eigene Frage.

Im Reisemanagement wurde in dreizehn Monaten nur jedes achte Programm überhaupt gestartet. Das muss nichts heißen, ein Jahresabschlussprogramm läuft einmal im Jahr, und nicht jede Nutzung wird gemessen. Nachfragen sollte man hier aber auf jeden Fall.

Die meiste Arbeit steckt in der Personaladministration. Dort gibt es 310 Dynpros, gut die Hälfte der Programme ist in Verwendung, und bei den meisten kann niemand mehr sagen, ob eine Anforderung dahintersteht oder eine Gewohnheit aus dem Jahr 2006. Mit eigenen Infotypen wurden über die Jahre viele Sonderfälle abgebildet, etwa Arbeitsmittel, Zulagen oder Zusatzvereinbarungen. Für manches davon gibt es heute einen möglichen Ersatz im Standard, ob er fachlich passt, muss man je Anforderung und Zielrelease prüfen. Mit der Prozesssicht werden aus 700 Einzelfällen eine Handvoll Entscheidungen, die eine Personalleitung auch tatsächlich treffen kann.

Was ein Agent dafür braucht

450 Programme und 700 Dynpros, und das ist nur ein einziger Prozess. Vor dem Projektstart prüft das niemand von Hand. Ein Agent schafft diese Menge, er liest ein Programm in Sekunden. Ob sich ein Neubau lohnt, kann er aus dem Quelltext allein aber nicht ablesen, denn dort steht nicht, zu welchem Prozess ein Programm gehört, ob es jemand benutzt und was davon abhängt. Ohne diese Informationen arbeitet ein Agent die Liste von oben nach unten ab und migriert gewissenhaft auch Programme, die man eigentlich stilllegen sollte.

Mit diesen Informationen kann er gezielter vorgehen. Der Sysparency-MCP-Server gibt ihm lesenden Zugriff auf den Wissensgraphen mit Prozesszuordnung, Nutzung, Abhängigkeiten, Clean-Core-Status und fachlicher Beschreibung, jeweils mit Verweis auf die Quellzeile. Was der Standard heute bietet, liefern SAPs Dokumentations-MCP-Server. Damit lässt sich eine Frage wie diese beantworten:

Welche Eigenentwicklungen in Hire-to-Retire wurden in den letzten 13 Monaten genutzt, greifen auf nicht freigegebene SAP-Objekte zu und bilden eine Funktion ab, für die es im Zielrelease einen Standardkandidaten gibt? Nenne je Treffer die Quelle.

Heraus kommt eine Vergleichsliste mit Belegen auf beiden Seiten. Entscheiden müssen am Ende Menschen, aber der Prozessverantwortliche kann sich dann auf die Fälle konzentrieren, bei denen es wirklich etwas zu klären gibt, statt sich durch 700 Masken zu arbeiten.

Drei Fragen für die nächste Budgetrunde

1. Welche Prozesse haben wir verändert, und mit wie viel Code?
2. Bei welchen Abweichungen kennen wir den Grund, und wann hat ihn zuletzt jemand bestätigt?
3. Wo hat jemand geprüft, ob der Standard das inzwischen abdeckt?

Mit belegten Antworten auf diese Fragen lässt sich vor der Migration begründen, welche Eigenentwicklungen übernommen, ersetzt oder stillgelegt werden.

Wie die Prozesslandkarte für Ihr System aussieht, zeigen wir Ihnen gerne an einer Analyse Ihres Custom Codes. Demo anfragen