Systemeinstellung ohne Code

Was ist Customizing in SAP?

Customizing heißt, den SAP-Standard über Tabellen und Parameter im Einführungsleitfaden auf die Prozesse eines Unternehmens einzustellen, ohne dabei Programmcode zu schreiben oder zu ändern.

Fast jede Projektfrage, ob das System etwas auch anders kann, endet bei einer Tabelleneinstellung im Einführungsleitfaden und nicht bei einer Programmierung.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Werkzeug: Einführungsleitfaden, Transaktion SPRO
Ergebnis: Einträge in Customizing-Tabellen
Verteilung: Transportauftrag durch die Systemlandschaft
Abzugrenzen von: Modifikation am SAP-Standard

Wie eine Einstellung entsteht und ins Zielsystem kommt

Der Einstiegspunkt ist der Einführungsleitfaden, Transaktion SPRO. Er ist nach Anwendungsbereichen gegliedert und führt zu den einzelnen Pflegeaktivitäten, hinter denen im Kern Tabelleneinträge stehen: Belegarten, Nummernkreise, Kontenfindung, Bewertungsklassen, Partnerrollen, Kalkulationsschemata.

Änderst du eine solche Tabelle, schreibt das System die Einträge in einen Customizing-Auftrag. Der wird freigegeben und wandert über die Systemlandschaft, üblicherweise vom Entwicklungssystem ins Qualitätssicherungssystem und erst nach dem Test ins Produktivsystem. Damit ist jede Einstellung nachvollziehbar und wiederholbar, was bei Rückfragen aus der Revision zählt.

Mandantenabhängig oder systemweit

Ein Teil des Customizings gilt nur im aktuellen Mandanten, ein anderer Teil systemweit für alle Mandanten. Kalenderpflege, Einheiten oder bestimmte technische Einstellungen gehören zur zweiten Gruppe. Wer dort etwas ändert, verändert die Einstellung gleichzeitig im Schulungs-, Test- und Entwicklungsmandanten desselben Systems, oft ohne es zu merken.

Eine bekannte Ausnahme sind Nummernkreisintervalle. Sie werden in der Regel nicht mit transportiert, sondern müssen im Zielsystem gepflegt werden, sonst startet die Nummernvergabe dort an einer falschen Stelle oder scheitert ganz.

Der teuerste Fehler

Direkt im Produktivsystem einzustellen, weil es schnell gehen soll, ist der Klassiker. Selbst wenn die Änderung technisch funktioniert, fehlt sie im Entwicklungssystem und wird beim nächsten regulären Transport wieder überschrieben. Der Aufwand kommt dann doppelt zurück, meist zum ungünstigsten Zeitpunkt.

Fast ebenso häufig fehlt die Begründung. Eine Einstellung ohne dokumentierten Anlass wird zwei Jahre später niemand anzufassen wagen, weil keiner weiß, welcher Prozess daran hängt. Ein Satz im Auftrag, warum diese Belegart so eingestellt ist, spart später Tage.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Customizing und was oft damit gleichgesetzt wird

Customizing gegen Eigenentwicklung

Bei der Eigenentwicklung entstehen neue Objekte im Kundennamensraum, also eigene Programme, Tabellen oder Klassen. Customizing nutzt dagegen ausschließlich das, was der Standard an Einstellmöglichkeiten vorsieht.

Customizing gegen Modifikation

Eine Modifikation ändert ein Objekt von SAP selbst. Sie muss bei jedem Upgrade abgeglichen werden und erzeugt damit Aufwand, solange sie im System steht. Customizing überlebt Upgrades dagegen unverändert.

Customizing gegen Erweiterung

Erweiterungen hängen eigene Logik an vorgesehene Stellen des Standards, etwa über BAdIs oder Enhancement Spots. Sie sind mehr als Customizing, aber im Gegensatz zur Modifikation vom Standard vorgesehen.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Die Einstellung ist in Minuten gemacht, der Weg ins Produktivsystem ist die Arbeit

Eine Einstellung entsteht im Entwicklungssystem, wird auf einen Transportauftrag geschrieben und wandert von dort ins Qualitäts- und schließlich ins Produktivsystem. Der Aufwand steckt selten im Setzen des Häkchens, sondern darin, die Abhängigkeiten mitzunehmen: Eine neue Belegart nützt nichts, wenn Nummernkreis, Kontenfindung und Berechtigung nicht denselben Weg gehen.

Nummernkreise sind dabei der Klassiker, weil sie in der Regel nicht transportiert, sondern im Zielsystem gepflegt werden. Wenn im Produktivsystem eine Buchung mit fehlendem Intervall abbricht, obwohl im Test alles lief, liegt genau das dahinter.

Die zweite Falle ist die Unterscheidung zwischen mandantenabhängigen und systemweiten Tabellen. Wer eine systemweite Einstellung im Sandkasten ausprobiert, testet damit nicht nur im Sandkasten. Vor einer solchen Änderung lohnt der Blick, ob die Tabelle überhaupt am Mandanten hängt.

Customizing lernen

Welche Einstellungen zu deinem Prozess gehören und wie sie sauber ins Produktivsystem kommen, behandeln die Trainings zur Einrichtung der SAP Module .

Wenn der Standard an einer Stelle wirklich nicht ausreicht, führt der nächste Schritt zu den Kurse rund um eigene Erweiterungen im System .

Kurse, die Customizing behandeln

Häufige Fragen

Brauche ich zum Customizing Programmierkenntnisse?

Nein. Du arbeitest mit Pflegebildern und Tabellen. Was du brauchst, ist Prozesswissen, denn die Einstellungen bilden ab, wie dein Unternehmen arbeitet. Verstehen zu können, wie das System Werte ableitet, hilft allerdings enorm bei der Fehlersuche.

Was unterscheidet Customizing-Auftrag und Workbench-Auftrag?

Der Customizing-Auftrag transportiert Tabelleneinträge, also Einstellungen, und ist mandantenbezogen. Der Workbench-Auftrag transportiert Repository-Objekte wie Programme und Tabellendefinitionen, die systemweit gelten.

Warum ist meine Einstellung im Testsystem nicht angekommen?

Prüfe drei Punkte in dieser Reihenfolge: Wurde der Auftrag freigegeben, ist er im Zielsystem fehlerfrei importiert worden, und handelt es sich um eine Einstellung, die überhaupt transportiert wird. Nummernkreise und einige mandantenabhängige Tabellen musst du im Ziel manuell pflegen.

Persönlich für dich da