Customizing

Customizing bezeichnet das Anpassen einer Standardsoftware an die Abläufe eines Unternehmens, ohne ihren Programmcode zu verändern: über Konfiguration, Parametrierung, Erweiterungspunkte und Zusatzmodule, die ein Update der Basis überleben.

Der Begriff wird im Alltag großzügig verwendet, und genau darin liegt die Ursache vieler teurer Projekte. „Wir haben das System nur ein bisschen angepasst“ kann bedeuten, dass jemand in einer Konfigurationsmaske einen Haken gesetzt hat. Es kann auch bedeuten, dass jemand den Kern der Software umgeschrieben hat und damit jedes zukünftige Update zu einem Projekt macht. Zwischen diesen beiden Fällen liegen Größenordnungen an Folgekosten.

Die drei Stufen: Konfiguration, Erweiterung, Modifikation

Wer über Customizing entscheidet, sollte immer zuerst klären, auf welcher Stufe er sich bewegt. Die Stufen unterscheiden sich nicht im Ergebnis für den Anwender, sondern im Preis, den man Jahre später zahlt.

Stufe 1: Konfiguration im Standard

Alles, was die Software selbst als Einstellung anbietet: Buchungskreise, Nummernkreise, Rollen und Rechte, Steuerkennzeichen, Workflows, Pflichtfelder, Belegvorlagen, Preisfindungsschemata. Das ist der vom Hersteller vorgesehene Weg, und er ist updatefest, weil diese Einstellungen als Daten gespeichert werden und nicht als Code.

SAP hat diese Stufe am sichtbarsten formalisiert: Über den Einführungsleitfaden, den man mit der Transaktion SPRO öffnet, wird ein System in tausenden Einzeleinstellungen an die Organisation angepasst, und der Begriff Customizing bezeichnet in der SAP-Welt genau diese Tätigkeit. Die Einstellungen sind teils mandantenabhängig, teils mandantenübergreifend, und sie wandern über das Transportwesen aus dem Entwicklungs- ins Produktivsystem. Das ist kein Detail für Administratoren, sondern der Grund, warum sich SAP-Einführungen über Monate ziehen, ohne dass eine Zeile Code entsteht.

Stufe 2: Erweiterung über definierte Schnittstellen

Was die Konfiguration nicht hergibt, lässt sich bei gut gebauten Systemen über vorgesehene Erweiterungspunkte ergänzen: Plugins, Apps, Events, Hooks, eigene Felder, ausgetauschte Services. Der Hersteller sagt zu, diese Punkte stabil zu halten, und man bewegt sich innerhalb eines dokumentierten Vertrags.

Shopware 6 ist ein gutes Beispiel für diese Denkweise. Anpassungen laufen über Plugins beziehungsweise das App-System, wobei Dienste dekoriert und Ereignisse abonniert werden, statt Kerndateien zu editieren. Microsoft hat für Dynamics 365 Business Central denselben Schritt gemacht und die frühere direkte Codeanpassung durch ein Erweiterungsmodell ersetzt. Der gemeinsame Gedanke: Die Anpassung liegt neben dem Standard, nicht in ihm.

Stufe 3: Modifikation am Kern

Hier wird ausgelieferter Code verändert. Das funktioniert immer, deshalb ist es so verführerisch, und es erzeugt eine Verbindlichkeit, die kaum jemand beim Beschluss mitkalkuliert: Jedes Update muss die Änderung erneut einarbeiten oder wird verschoben. Nach zwei verschobenen Major-Updates ist ein System faktisch eingefroren, und aus der gekauften Standardsoftware ist ein gewachsener Eigenbau geworden, für den niemand Wartungsverträge hat.

Die vierte Zeile fehlt in den meisten Projektplänen, obwohl sie oft die wirtschaftlichste ist. Nicht jede Abweichung zwischen Standard und gelebtem Prozess ist ein Wettbewerbsvorteil. Manche ist nur die Gewohnheit, die sich um eine Einschränkung des Vorgängersystems gebildet hat.

Warum Customizing die Gesamtkosten verschiebt

Der Lizenzpreis einer Standardsoftware ist die Zahl, über die verhandelt wird. Der Customizing-Anteil ist die Zahl, die das Projekt bestimmt. In Einführungsprojekten von Warenwirtschafts- und ERP-Systemen übersteigt der Aufwand für Beratung, Konfiguration, Datenmigration, Schulung und Anpassung die Lizenzkosten regelmäßig um ein Mehrfaches. Das ist kein Skandal, sondern die Natur der Sache: Man kauft ein Fundament und bezahlt dafür, dass es zu einem konkreten Haus passt.

Relevant wird es dort, wo Customizing dauerhafte Verpflichtungen erzeugt. Jede Erweiterung ist Code, der gepflegt, getestet und bei Updates geprüft werden muss. Jede Modifikation ist eine Bremse für zukünftige Releases. Beides landet in der Total Cost of Ownership, und beides fällt in der ersten Angebotsrunde nicht auf, weil es erst ab Jahr zwei sichtbar wird. Wer Customizing ohne Betriebskonzept beauftragt, kauft sich eine technische Schuld ein, die er nicht gebucht hat.

Der versteckte Posten: Testen

Jede Anpassung verändert das Verhalten eines Systems, das der Hersteller nicht mit dieser Anpassung getestet hat. Damit wandert ein Teil der Qualitätssicherung zum Anwenderunternehmen. Wer fünf Erweiterungen im Einsatz hat, braucht eine Liste der Abläufe, die nach jedem Update nachweislich funktionieren müssen: Bestellung anlegen, Rechnung erzeugen, Zahlung verbuchen, Schnittstelle übertragen. Ohne diese Liste wird jedes Update zur Stichprobe, und Fehler fallen im Tagesgeschäft auf statt in der Vorbereitung. Der Aufwand dafür ist überschaubar, wenn er beim ersten Customizing mitgeplant wird, und unangenehm, wenn er nach dem ersten Vorfall nachgeholt werden muss.

Wann Customizing kippt

Für die Entscheidung gibt es eine brauchbare Heuristik, die ohne Excel funktioniert. Prüfe, wie viel des realen Prozesses ein Standardprodukt ohne Eingriff abdeckt:

• Deutlich über vier Fünftel abgedeckt: kaufen, konfigurieren, den Rest per Prozessanpassung schließen. Die Lücke ist kleiner als die Kosten ihrer Beseitigung.
• Zwischen der Hälfte und vier Fünfteln: Standard als Kern behalten, die Lücke über Erweiterungen schließen, nichts am Kern anfassen. Das ist der klassische Hybridfall.
• Unter der Hälfte: Das Produkt passt nicht. Wer es trotzdem nimmt und dann vollständig umbaut, zahlt Lizenz und Eigenentwicklung gleichzeitig und bekommt die Nachteile beider Welten.

Die harte Version dieser Regel lautet: Wenn das Customizing teurer wird als eine gezielte Individualsoftware für den betroffenen Prozess, war die Produktauswahl falsch, und kein weiteres Budget korrigiert das. Genau das ist der Punkt, an dem die Make-or-Buy-Entscheidung noch einmal auf den Tisch gehört, statt weiter am Standard zu schrauben.

Praxisbeispiel: das eine Feld, das alles kostet

Ein Muster, das sich in Einführungsprojekten wiederholt: Ein Unternehmen braucht im Bestellprozess ein zusätzliches Feld, etwa eine interne Projektnummer, die auf Beleg, Lieferschein und Rechnung mitlaufen soll. Stufe 1 prüft, ob das System freie Zusatzfelder anbietet, was bei ERP-Systemen und Shops meist der Fall ist. Stufe 2 ergänzt eine kleine Erweiterung, die das Feld in die Belegdruckvorlagen und die Schnittstelle zur Buchhaltung übernimmt.

Stufe 3 sieht anders aus: Weil der Standarddruck das Feld nicht an der gewünschten Stelle zeigt, wird die ausgelieferte Vorlage direkt bearbeitet. Beim nächsten Update kommt die Herstellerversion zurück, das Feld verschwindet, jemand baut es erneut ein, diesmal schneller und ohne Dokumentation. Nach drei Runden weiß niemand mehr, welche Änderungen bewusst und welche Reparaturen waren. Der Aufwand für das Feld war nie das Problem; das Problem war die gewählte Stufe.

Governance: Customizing dokumentieren und begrenzen

Customizing ist weniger eine technische als eine organisatorische Disziplin. Vier Regeln erledigen den größten Teil der Arbeit:

1. Jede Anpassung bekommt eine fachliche Begründung. Wer sie nicht in zwei Sätzen aufschreiben kann, braucht sie vermutlich nicht.
2. Die Stufe wird explizit entschieden. Konfiguration, Erweiterung oder Modifikation ist eine Entscheidung mit Kostenfolge, keine Umsetzungsdetailfrage für die Entwicklung.
3. Modifikationen brauchen eine Freigabe und ein Ablaufdatum. Wenn sie unvermeidbar sind, gehört dazu die Frage, wann sie durch eine Erweiterung ersetzt werden.
4. Vor jedem Update wird der Anpassungsbestand geprüft. Eine aktuelle Liste dessen, was vom Standard abweicht, ist der Unterschied zwischen einem Update und einem Projekt.

In größeren Landschaften lohnt zusätzlich die Trennung: Anpassungen, die nur einen Prozess betreffen, laufen als eigenes Modul neben dem Standard und sprechen über eine API mit ihm. Das hält den Standard sauber und macht den Eigenanteil austauschbar. Eine kompakte Begriffsabgrenzung liefert auch der Eintrag zum Customizing bei Wikipedia.

Hilfreich ist außerdem eine schlichte Sprachregelung im Projekt: Wer „Anpassung“ sagt, nennt die Stufe mit. Das klingt pedantisch und verhindert die häufigste Fehlentscheidung überhaupt, nämlich eine Modifikation, die niemand als solche beschlossen hat.

Abgrenzung zu benachbarten Begriffen

Konfiguration ist die harmlose Teilmenge des Customizings. Parametrierung meint dasselbe in technischerem Ton. Individualentwicklung baut dort, wo nichts Passendes existiert, und ist keine Steigerungsform des Customizings, sondern eine andere Entscheidung. Und die verbreitete Gleichsetzung von Customizing mit Modifikation ist genau der Sprachfehler, der Projekte teuer macht, weil sie die Stufe verschleiert, auf der gearbeitet wird.

Häufige Fragen

Ist Customizing dasselbe wie Individualsoftware?

Nein. Customizing passt ein fremdes Produkt an, dessen Weiterentwicklung beim Hersteller liegt. Individualsoftware entsteht für einen konkreten Prozess und gehört dem Auftraggeber. Die Grenze verschwimmt in der Praxis nur deshalb, weil stark modifizierte Standardsoftware irgendwann wie ein Eigenbau gewartet werden muss, ohne dessen Vorteile zu haben.

Wie viel Customizing ist zu viel?

Ein belastbarer Indikator ist nicht die Menge, sondern die Updatefähigkeit. Solange ein Update ohne Nacharbeit am Anpassungsbestand durchläuft, ist die Grenze nicht überschritten. Sobald Updates wegen eigener Eingriffe verschoben werden, ist sie es, auch bei nur einer einzigen Modifikation.

Wer sollte das Customizing verantworten?

Fachlich der Prozessverantwortliche, technisch die Entwicklung oder der Implementierungspartner. Entscheidend ist eine benannte Person, die jede Abweichung vom Standard kennt und die Liste pflegt. Ohne diese Rolle sammelt sich über Jahre ein Anpassungsbestand, den niemand mehr überblickt.

Was bedeutet updatefestes Customizing?

Dass Anpassungen ausschließlich über Mittel erfolgen, die der Hersteller dafür vorgesehen hat: Einstellungen, Erweiterungspunkte, Plugins, Apps. Ausgelieferter Code bleibt unangetastet. Das ist keine Stilfrage, sondern die Bedingung dafür, dass Sicherheitsupdates und neue Versionen ohne Projekt einspielbar bleiben.

Gilt das auch für SaaS?

Im Prinzip ja, nur mit engeren Grenzen. Bei einer gemieteten Lösung entfällt Stufe 3 in der Regel vollständig, weil niemand Zugriff auf den ausgelieferten Code hat. Übrig bleiben Konfiguration und die Erweiterungspunkte, die der Anbieter freigibt, häufig gestaffelt nach Tarif. Das wirkt wie eine Einschränkung und ist meist ein Vorteil: Die Versuchung zur Modifikation fällt weg. Der Preis dafür liegt an anderer Stelle. Was der Anbieter nicht vorsieht, ist nicht verhandelbar, und die Frage nach dem fehlenden Erweiterungspunkt gehört deshalb in die Auswahl und nicht in die Einführung.