Nicht jeder Sonderprozess verdient ERP-Customizing

In ERP-Projekten beginnt die Liste der Sonderwünsche oft früh. Ein zusätzlicher Status wird benötigt, eine Maske soll wie im Altsystem aussehen, eine Freigabe folgt einer historisch gewachsenen Reihenfolge und ein Bericht soll dieselben Spalten wie die bisherige Excel-Datei besitzen.

Jeder einzelne Wunsch kann vernünftig klingen. In Summe entsteht ein System, das zwar den alten Zustand nachbildet, aber bei Tests, Updates, Support und Prozessänderungen immer mehr Sonderwissen verlangt.

Die falsche Gegenreaktion lautet: „Wir machen grundsätzlich nur Standard.“ Auch das kann fachlich notwendige Kontrollen oder echte Differenzierung verhindern.

Die bessere Leitfrage ist: Welche Abweichung schafft so viel notwendige oder unterscheidbare Geschäftswirkung, dass das Unternehmen ihren gesamten Lebenszyklus tragen will?

„Customizing“ muss zuerst präzisiert werden

Der Begriff wird in Projekten für sehr unterschiedliche Eingriffe verwendet:

• Konfiguration: vorgesehene Einstellungen, Rollen, Workflows oder Felder innerhalb des Produktstandards,
• Erweiterung: zusätzliche Logik über vorgesehene Erweiterungspunkte,
• Integration: Datenaustausch oder Prozessübergang zu einem anderen System,
• individuelle Entwicklung: eigene Funktion oder eigenes Modul,
• Kernmodifikation: Änderung von Standardcode oder nicht vorgesehenem Verhalten,
• Bericht oder Auswertung: zusätzliche Sicht auf vorhandene Daten.

Diese Varianten besitzen unterschiedliche Folgen für Wartung und Updates. Eine zusätzliche Konfiguration ist nicht automatisch unkritisch. Eine sauber entkoppelte Erweiterung kann beherrschbarer sein als ein komplexer Standard-Workflow. Dennoch braucht das Projekt eine gemeinsame Sprache, bevor es Aufwand und Risiko bewerten kann.

Der Prozesszweck kommt vor der Lösungsform

„Wir benötigen drei Freigabestufen“ ist bereits eine Lösung. Die fachliche Anforderung könnte lauten: „Bestellungen oberhalb bestimmter Risiken müssen von einer unabhängigen Rolle geprüft werden.“

Erst diese Formulierung erlaubt die Prüfung:

• Unterstützt der Standard das Kontrollziel bereits?
• Kann eine Organisations- oder Rollenänderung das Ziel erfüllen?
• Reicht Konfiguration?
• Wird tatsächlich eine Erweiterung benötigt?
• Ist eine Integration zu einem spezialisierten System sinnvoller?

Der Leitfaden zur Prozessprüfung vor Digitalisierung trennt Anlass, Ergebnis, Regeln, Rollen und Ausnahmen. Diese Arbeit verhindert, dass ein historischer Ablauf vorschnell zur Softwareanforderung wird.

Die aktuelle SAP-Dokumentation zum Fit-to-Standard-Ansatz beschreibt den Abgleich benötigter Geschäftsprozesse mit Standardprozessen und die Identifikation von Funktionen, die im Standard tatsächlich fehlen. Die Methode ist produktspezifisch. Das übertragbare Prinzip lautet: Erst den Standard am realen Prozessziel prüfen, dann die verbleibende Lücke gestalten.

Sieben Prüfungen vor einer ERP-Erweiterung

1. Ist die Anforderung verpflichtend?

Eine Abweichung kann notwendig sein, wenn sie eine gesetzliche, vertragliche oder kontrollbezogene Pflicht erfüllt. Das Projekt sollte diese Pflicht konkret benennen:

• Welche Regel oder Zusage gilt?
• Für welche Gesellschaft, Produktgruppe oder Transaktion?
• Welche Nachweise werden benötigt?
• Gibt es eine andere zulässige Umsetzung?

„Das verlangt der Prüfer“ oder „Das war schon immer so“ genügt nicht. Die Quelle und die tatsächliche Kontrollwirkung müssen erkennbar sein.

2. Differenziert der Prozess das Geschäft?

Ein Prozess kann Wettbewerbsvorteil oder wesentlicher Teil des Leistungsversprechens sein. Dann darf der Standard nicht aus Bequemlichkeit die Geschäftslogik bestimmen.

Zu prüfen ist:

• Was kann das Unternehmen dadurch nachweisbar besser?
• Nimmt ein Kunde oder interner Leistungsempfänger den Unterschied wahr?
• Ist die Abweichung skalierbar oder nur historisch gewachsen?
• Würde eine Standardisierung den Nutzen tatsächlich zerstören?

Nicht jede Besonderheit ist Differenzierung. Manche ist nur eine lokale Gewohnheit oder Folge alter Systemgrenzen.

3. Wurde der Standard praktisch gezeigt?

Diskussionen über Standardfunktionen sollten nicht allein auf Listen oder Erinnerung beruhen. Der relevante Ablauf muss mit repräsentativen Daten und Rollen vorgeführt werden.

Die Dynamics-365-Implementierungsleitlinie empfiehlt, Standardfähigkeiten auf Geschäftsanforderungen abzubilden, um Anpassungen zu begrenzen und spätere Updates zu erleichtern. Daraus folgt für jedes Produkt: Eine Abweichung ist erst belastbar, wenn der Standard am konkreten Szenario geprüft wurde.

Eine Demonstration muss auch Ausnahmefälle, Berechtigungen, Belege und Folgeprozesse zeigen. Ein positiver Happy Path genügt nicht.

4. Welche Alternative ist einfacher?

Vor Entwicklung sind mindestens diese Alternativen zu prüfen:

• Prozess anpassen,
• Rolle oder Entscheidungsrecht klären,
• Standard konfigurieren,
• Auswertung statt Prozessänderung,
• kleine, entkoppelte Erweiterung,
• Integration zu einer bestehenden Fachanwendung,
• Anforderung bewusst nicht umsetzen.

„Nicht umsetzen“ ist eine legitime Option, wenn Nutzen und Wirkung gering sind. Das Projekt muss nicht jeden Wunsch in einen Backlog überführen.

5. Wer verantwortet Nutzen und Regel?

Eine Erweiterung braucht einen fachlichen Owner, der:

• die Anforderung und ihr Kontroll- oder Nutzenziel bestätigt,
• Priorität gegenüber anderen Anforderungen verantwortet,
• Regeln und Ausnahmen entscheidet,
• fachliche Tests abnimmt,
• spätere Änderungen und Stilllegung mitträgt.

Die IT oder der Implementierungspartner kann technische Folgen erklären. Sie sollte nicht unbemerkt zum Eigentümer einer fachlichen Sonderregel werden.

6. Was kostet der Lebenszyklus?

Entwicklungskosten sind nur der Anfang. Je nach Art der Abweichung entstehen:

• fachliche und technische Spezifikation,
• Sicherheits- und Berechtigungsprüfung,
• automatisierte und manuelle Tests,
• Dokumentation und Schulung,
• Fehleranalyse und Support,
• Regressionstests bei Releases,
• Anpassung an neue Produktversionen,
• Datenmigration und spätere Stilllegung.

Die Microsoft-Dokumentation zu Erweiterungen von Dynamics 365 nennt Auswirkungen auf Nutzbarkeit, Barrierefreiheit, Leistung, Sicherheit, Compliance, Skalierung, Wartung und Support. Diese Liste ist produktspezifisch formuliert, beschreibt aber eine allgemeine Wahrheit: Eine funktionierende Erweiterung ist nicht automatisch eine langfristig tragfähige Erweiterung.

Die Odoo-19-Upgrade-Dokumentation zeigt einen konkreten Lebenszyklus-Effekt: Eigene Module müssen für die Zielversion verfügbar und mit einer aktualisierten Testdatenbank geprüft werden. Andere ERP-Produkte besitzen andere Erweiterungs- und Updateverfahren. Der Aufwand verschwindet jedoch bei keinem Produkt allein deshalb, weil die erste Entwicklung abgeschlossen ist.

7. Wie wird getestet, überwacht und beendet?

Vor der Freigabe sollte geklärt sein:

• Welche fachlichen Testfälle beweisen die Wirkung?
• Welche Standardprozesse könnten beeinträchtigt werden?
• Welche Tests werden bei jedem Release wiederholt?
• Wie werden Fehler und Nutzung sichtbar?
• Welcher Owner entscheidet über Änderung oder Stilllegung?
• Wie lassen sich Daten und Prozesse zurück in den Standard überführen?

Eine Erweiterung ohne Exit wird leicht zum dauerhaften Zwang.

Konstruiertes Beispiel: Der zusätzliche Freigabestatus

Das folgende Beispiel ist konstruiert.

Ein Unternehmen möchte im neuen ERP einen zusätzlichen Status für Bestellungen einführen. Im Altsystem markiert er, dass ein Teamleiter den Vorgang gesehen hat. Die Anforderung wird zunächst als notwendiges Kontrollmerkmal beschrieben.

Im Workshop zeigt sich:

• Eine formale Genehmigung ist nur oberhalb einer Risikoschwelle erforderlich.
• Unterhalb der Schwelle erzeugt der Status keinen prüfbaren Mehrwert.
• Der ERP-Standard kann die risikobasierte Freigabe bereits konfigurieren.
• Der zusätzliche Status würde mehrere Masken, Berichte und Schnittstellen verändern.

Das Projekt übernimmt deshalb nicht die alte Bildschirmfolge, sondern bildet das eigentliche Kontrollziel im Standard ab.

Das Beispiel behauptet keine Einsparung und keinen Projekterfolg. Es zeigt, wie eine vermeintliche Funktionslücke durch die Trennung von Gewohnheit und Zweck verschwindet.

Wann Customizing ausdrücklich richtig ist

Standardnähe ist kein Selbstzweck. Eine Erweiterung kann richtig sein, wenn:

• eine konkrete Pflicht anders nicht angemessen erfüllt werden kann,
• ein geschäftskritischer Kontrollmechanismus fehlt,
• ein differenzierender Prozess nachweisbar Wert schafft,
• die Standardlösung unverhältnismäßige manuelle Arbeit oder Fehler erzeugt,
• Owner, Budget, Tests, Betrieb und Exit verbindlich geklärt sind.

In solchen Fällen sollte das Projekt die Erweiterung nicht verstecken, sondern als bewusstes Produktbestandteil führen.

Ein Abweichungs- und Customizing-Steckbrief

Feld	Inhalt
Prozess und Ziel	gewünschte fachliche Wirkung, nicht nur Funktion
Verpflichtung oder Differenzierung	belegter Grund für die Abweichung
Standardprüfung	gezeigter Ablauf und konkrete Lücke
Alternativen	Prozess, Konfiguration, Bericht, Integration, Verzicht
fachlicher Owner	Rolle mit Regel-, Priorisierungs- und Abnahmerecht
Lösungsform	Konfiguration, Erweiterung, Integration oder Entwicklung
Lebenszyklus	Erstellung, Test, Support, Release, Update und Stilllegung
Risiken	Sicherheit, Berechtigung, Daten, Leistung und Abhängigkeit
Abnahme	fachliche und technische Testfälle
Überprüfung	Termin und Kriterien für Beibehaltung oder Rückbau

Die Steckbriefe bilden zugleich ein Register der bewussten Abweichungen. Das ist wertvoller als eine technische Komponentenliste, weil jede Erweiterung mit ihrem Grund und Owner verbunden bleibt.

Gute Steuerung misst nicht nur die Zahl der Anpassungen

„Wir haben nur wenige Customizings“ kann eine Scheinkennzahl sein. Vielleicht werden sinnvolle Anforderungen unterdrückt oder komplexe Konfigurationen anders benannt.

Bessere Fragen sind:

• Besitzt jede Abweichung einen fachlichen Grund und Owner?
• Wurde der Standard am realen Szenario geprüft?
• Sind Tests und Updateverantwortung vorhanden?
• Werden kaum genutzte Abweichungen zurückgebaut?
• Bleiben Releases planbar?
• Können neue Mitarbeitende den Grund der Sonderlogik nachvollziehen?

Der erste sinnvolle Schritt ist ein Workshop für die zehn folgenreichsten Abweichungen. Jede wird auf Problem, Standardlücke, Owner, Lebenszyklus und Exit geprüft. Wenn niemand den fachlichen Grund oder die spätere Verantwortung vertreten kann, ist nicht die Spezifikation unvollständig – die Abweichung ist noch nicht freigabefähig.