ERP-Anpassung: Wie weit gehen und wo aufhören?

Die am häufigsten diskutierte Frage in ERP-Projekten lautet: Passen wir das System an die Prozesse des Unternehmens an, oder das Unternehmen an den Standard des Systems? Die Antwort liegt an keinem der beiden Extreme. Ein Ansatz bei der ERP-Anpassung, der jede Anforderung akzeptiert, blockiert Versionsupdates und treibt die Wartungskosten in die Höhe. Gar keine Anpassungen vorzunehmen, schickt die Anwender hingegen zurück zu Excel und manuellen Arbeitsschritten.

In diesem Beitrag erläutern wir, auf welchen Ebenen ERP-Anpassungen vorgenommen werden, welche Anforderungen eine Anpassung rechtfertigen und wo Sie einen Schlussstrich ziehen sollten. Am Ende finden Sie einen Entscheidungsrahmen und eine Checkliste, die Sie gemeinsam mit Ihrem Projektteam nutzen können.

Was ist ERP-Anpassung? Unterscheiden Sie vier verschiedene Ebenen

Der Begriff „Anpassung“ fasst in den meisten Projekten sehr unterschiedliche Arbeiten unter einem Dach zusammen. Ein Bildschirmfeld auszublenden, birgt nicht dasselbe Risiko wie die Änderung der zentralen Rechnungslogik. Wenn Sie Anforderungen schon vor den ersten Gesprächen in Ebenen einteilen, werden sowohl Angebote als auch Risiken besser lesbar.

Ebene	Was bedeutet das?	Beispiel	Update-Risiko
Konfiguration	Einstellung über die vorgesehenen Parameter des Systems	Freigabe-Workflow, Steuerkennzeichen, Belegnummerierung	Sehr gering
Personalisierung und Reporting	Anpassungen von Masken, Formularen, Berichten und Dashboards	Management-Dashboard, individueller Vertriebsbericht	Gering
Erweiterung / Extension	Zusatzmodul gemäß Herstellerrichtlinien, ohne den Kern anzutasten	Versandetiketten-Modul, Außendienst-Erweiterung	Mittel
Externe Integration	Anwendung, die außerhalb des ERP läuft und per API angebunden wird	B2B-Händlerportal, E-Commerce-Anbindung	Gering bis mittel
Änderung am Kerncode	Direkte Änderung der Standard-Geschäftslogik	Den Kalkulationsalgorithmus neu schreiben	Hoch

Die Faustregel ist einfach: Je weiter Sie in der Tabelle nach unten gehen, desto höher sollte die Begründungslast für eine Anforderung sein. Die ersten beiden Ebenen sind in nahezu jedem Projekt vertretbar. Die letzte Ebene sollte nur mit außergewöhnlichen, dokumentierten Begründungen geöffnet werden.

Die unsichtbaren Kosten übermäßiger Anpassung

Die Kosten einer Anpassung enden nicht mit der Entwicklungsrechnung. Der eigentliche Preis wird über die gesamte Lebensdauer des Systems gezahlt und taucht im Budget oft gar nicht auf.

Update-Schulden: Bringt der Hersteller eine neue Version heraus, muss jede individuelle Änderung neu getestet und manchmal neu geschrieben werden. Bei Cloud-ERP-Systemen mit häufigen Updates fällt diese Last noch stärker ins Gewicht.
Wissensabhängigkeit: Verlässt die Person, die den Individualcode geschrieben hat, das Unternehmen, trägt eine undokumentierte Logik weiterhin kritische Prozesse des Unternehmens.
Test- und Schulungsaufwand: Jeder nicht standardkonforme Ablauf vergrößert den Umfang von Anwenderschulungen und Regressionstests.
Schwierigerer Support: Der Herstellersupport kann Fehler in angepassten Bereichen vom Leistungsumfang ausnehmen.
Verlangsamte Veränderung: Je stärker ein System angepasst ist, desto schwieriger wird der Wechsel zu einem neuen Geschäftsmodell.

Ein realistisches Szenario

Nehmen wir als Beispiel ein Vertriebsunternehmen, das seinen Händlern Aktionspreise anbietet. Das Vertriebsteam verlangt eine Änderung im Kern der Preisberechnung. Die Anforderung funktioniert und sorgt im ersten Jahr für Zufriedenheit. Wird die ERP-Version im zweiten Jahr aktualisiert, funktioniert das Preismodul nicht mehr, die Korrektur dauert Wochen und die Aktionsphase gerät in Gefahr.

Derselbe Bedarf hätte sich mit einem Design abdecken lassen, bei dem die Preisregeln in einem kleinen Service außerhalb des ERP berechnet und das Ergebnis per API ins ERP geschrieben wird. Das Ergebnis wäre identisch, aber ein Versionsupdate würde diesen Service nicht beeinträchtigen.

Auch zu wenig Anpassung hat ihren Preis

Um die Balance zu wahren, muss man auch die andere Seite betrachten. Die Entscheidung „Wir passen gar nichts an“ sieht auf dem Papier sauber aus, führt in der Praxis aber zu anderen Problemen. Anwender verlagern die vom System nicht abgedeckten Schritte in Tabellen, und die ERP-Daten bilden nur noch die Hälfte des tatsächlichen Prozesses ab.

Auch ein Prozess, der Ihnen einen Wettbewerbsvorteil verschafft (ein spezieller Fertigungsablauf, eine branchenspezifische Angebotslogik, ein abweichendes Preismodell), lässt sich nur kostspielig in den Standard pressen. Hier besteht das Risiko, dass das ERP Sie austauschbar macht. Das Ziel ist nicht, Anpassungen auf null zu bringen, sondern sie an den richtigen Stellen und auf der richtigen Ebene vorzunehmen.

Ein Rahmen aus 5 Fragen für die Entscheidung zur ERP-Anpassung

Lassen Sie jede Anforderung die folgenden Fragen durchlaufen. Die Antworten ordnen eine Anforderung einer der Kategorien „Standard übernehmen“, „konfigurieren“, „per Erweiterung lösen“ oder „den Kern anfassen“ zu.

Verschafft dieser Prozess einen Wettbewerbsvorteil? Wenn nicht (z. B. eine standardmäßige Einkaufsfreigabe), ist die Orientierung am Branchenstandard meist günstiger.
Handelt es sich um eine gesetzliche oder verpflichtende Anforderung? Pflichten zu E-Belegen, Steuern und Berichtswesen werden in der Regel durch die lokalen Pakete des Herstellers abgedeckt. Prüfen Sie diese zuerst.
Lässt sich der Prozess ändern? Manchmal steckt hinter dem Satz „Das machen wir seit Jahren so“ keine echte Notwendigkeit. Den Ablauf durch Prozessberatung zu vereinfachen, kann günstiger sein als Code zu schreiben.
Gibt es einen Weg innerhalb des Standardsystems? Die meisten ERP-Systeme bieten über Parameter, Workflows und rollenbasierte Einstellungen mehr, als man erwartet. Im Fit-Gap sollten diese Optionen den Anwendern konkret gezeigt werden.
Wer ist für die Wartung verantwortlich? Wenn nicht klar ist, wer die Anpassung schreibt, dokumentiert, testet und bei Versionsupdates aktualisiert, ist die Anforderung noch nicht reif.

Der beste Zeitpunkt für die Anwendung dieses Rahmens ist die Bedarfsanalyse vor Vertragsabschluss. Die Schritte in der Auswahlphase haben wir in unserem Leitfaden zur ERP-Auswahl ausführlich behandelt. Wenn Sie zwischen Standardprodukt und Individualentwicklung schwanken, unterstützt Sie auch unser Beitrag zur Entscheidungsmatrix Standard-ERP oder individuelles ERP bei Ihrer Entscheidungsfindung.

Bereiche, in denen sich Anpassung lohnt, und Bereiche, die Sie meiden sollten

Was sich in der Regel anzupassen lohnt

Fertigungs-, Preisgestaltungs- oder Angebotsprozesse, die Sie von Ihren Wettbewerbern abheben
Management-Berichte, Dashboards und rollenspezifische Masken
Oberflächenanforderungen besonderer Anwendergruppen wie Außendienst, Lager oder Filiale
Datenaustausch mit Drittsystemen (Marktplatz, Versanddienstleister, Bank, Händlerportal)
Branchenspezifische regulatorische Anforderungen, für die das Standardpaket keine Entsprechung bietet

Was man in der Regel vermeiden sollte

Zentrale Berechnungslogiken wie Buchhaltung, Bestandsbewertung und Kalkulation
Masken- und Berichtsanforderungen, die nur auf den Gewohnheiten einer einzelnen Person beruhen
Eine 1:1-Kopie des Altsystems im neuen ERP nachzubauen
Datenqualitätsprobleme mit Code zu verdecken. In diesem Fall muss man zunächst zur ERP-Datenbereinigung und Stammdatenverwaltung zurückkehren.
Probleme, die sich durch Anwenderschulung lösen ließen, mit Entwicklung zu lösen

Technische Prinzipien für sichere Anpassungen

Wenn eine Anpassung unvermeidlich ist, kommt es darauf an, wie sie umgesetzt wird, mindestens ebenso wie auf ihren Umfang. Die folgenden Prinzipien verhindern den Großteil der Überraschungen bei Versionsupdates.

Den Kern nicht anfassen: Nutzen Sie die vom Hersteller angebotenen Erweiterungsmechanismen (Extensions, ereignisbasierte Hooks, benutzerdefinierte Felder). Eine direkte Änderung des Standardcodes sollte das letzte Mittel sein.
Logik auslagern: Schreiben Sie häufig wechselnde oder komplexe Geschäftsregeln als Service außerhalb des ERP und binden Sie diesen per API-Integration an. So beeinträchtigt ein ERP-Update diese Logik nicht.
Jede Änderung dokumentieren: Warum sie vorgenommen wurde, welchen Prozess sie abdeckt, wer verantwortlich ist und mit welchen Tests sie verifiziert wurde, sollte festgehalten sein.
Versionskontrolle und automatisierte Tests nutzen: Individualcode sollte in einem vom ERP unabhängigen Repository liegen. Automatisierte Tests für kritische Abläufe verkürzen die Prüfung nach einem Update auf wenige Stunden.
Testumgebung einrichten: Jedes Update sollte zunächst in einer Umgebung mit einer maskierten Kopie der Produktionsdaten ausprobiert werden.

Ist eine umfassende Anpassung erforderlich, sollte man auch die Balance zwischen den auf ein Standardprodukt aufgesetzten Modulen und einer Lösung von Grund auf bewerten. In unserer Dienstleistung zur ERP-Softwareentwicklung klären wir diese Abgrenzung bereits in der Bedarfsanalyse.

Governance für Anpassungen: Anforderungen müssen durch eine Kontrolle

In Projekten wächst die Anpassung oft nicht aus einer einzigen großen Entscheidung, sondern aus Hunderten kleiner „Das hätten wir auch noch gern“-Wünsche. Um das zu verhindern, richten Sie ein schlankes, aber verbindliches Änderungsmanagement ein.

Jede Anforderung wird schriftlich mit Geschäftsbegründung und erwartetem Nutzen aufgenommen.
Die Anforderung wird anhand des oben beschriebenen Rahmens aus 5 Fragen gemeinsam von Technik und Fachbereich bewertet.
Für genehmigte Anforderungen werden zusätzlich zu den anfänglichen Entwicklungskosten auch der jährliche Wartungs- und Testaufwand berechnet.
Der Fachbereich, dem die Anforderung gehört, wird benannt. Ungenutzte Anpassungen werden in regelmäßigen Abständen überprüft und entfernt.

Bei der Budgetierung ist es sinnvoller, statt auf eine feste Preiszahl auf die preisbeeinflussenden Faktoren zu schauen:

Die Ebene der Anforderung (Bericht oder Kernlogik?)
Reifegrad und Dokumentation der Erweiterungsmechanismen des Herstellers
Anzahl der integrierten Systeme und Datenvolumen
Umfang von Tests, Datenmigration und Anwenderschulung
Häufigkeit der Versionsupdates und der danach erforderlichen Wartung
Grad der Dokumentation und Übergabefähigkeit der Entwicklung

Auch nach dem Go-live bleibt diese Last bestehen. Ein regelmäßiger Plan für Wartungs- und Supportleistungen verhindert, dass Anpassungen bei Updates für Überraschungen sorgen.

Checkliste für die Zeit vor Projektbeginn

Wurden alle Anforderungen in Ebenen (Konfiguration, Bericht, Erweiterung, Integration, Kern) eingeteilt?
Gibt es für jede Kerncode-Anforderung eine schriftliche Begründung und eine Alternativenanalyse?
Hat die Fit-Gap-Analyse den Anwendern die Möglichkeiten des Standardsystems gezeigt?
Wurden die lokalen Pakete des Herstellers für gesetzliche Anforderungen geprüft?
Sind Verantwortlicher, Dokumentation und Testszenario für den Individualcode festgelegt?
Wurden Testumgebung und Prozess für Versionsupdates definiert?
Wurde der jährliche Wartungsaufwand jeder Anpassung berücksichtigt?
Gibt es einen Zeitplan zur Überprüfung ungenutzter Anpassungen?

Häufig gestellte Fragen

Wie hoch sollte der Anteil der ERP-Anpassungen sein?

Es gibt keine allgemeingültige Quote, da sie je nach Branche und Besonderheit der Prozesse variiert. Ein aussagekräftigerer Maßstab ist, auf welcher Ebene sich die Anpassungen konzentrieren. Liegt die Mehrheit auf den Ebenen Konfiguration, Berichte und externe Integration und sind Änderungen am Kerncode die Ausnahme, ist Ihr Ansatz in der Regel gesund.

Was ist der Unterschied zwischen ERP-Anpassung und Konfiguration?

Konfiguration ist die Einstellung über die vorgesehenen Parameter des Systems und erfordert in der Regel keine Programmierung. Anpassung bedeutet dagegen, Verhaltensweisen, die das Standardsystem nicht kennt, per Code hinzuzufügen oder zu ändern. Konfiguration birgt bei Versionsupdates weniger Risiko.

In unserem ERP haben sich zu viele Anpassungen angesammelt. Was sollen wir tun?

Erstellen Sie zunächst ein Inventar aller Anpassungen und vermerken Sie Nutzungsstatus, Verantwortlichen und Risiko. Entfernen Sie ungenutzte, nehmen Sie diejenigen zurück, die der Standard abdecken kann, und prüfen Sie bei den übrigen, ob sie sich als Erweiterung oder externer Service neu strukturieren lassen. Bei großem Umfang sollte diese Arbeit als Softwaremodernisierungsprojekt geplant werden.

Sind Anpassungen im Cloud-ERP möglich?

Ja, aber die Grenzen bestimmen die vom Hersteller angebotenen Erweiterungsmechanismen. Der Zugriff auf den Kerncode ist meist gesperrt, und Updates erscheinen häufig. Daher ist der sinnvollste Weg im Cloud-ERP die Erweiterung über APIs und externe Services.

Mit wessen Freigabe sollten Anpassungsanforderungen weiterverfolgt werden?

Der Eigentümer des Fachbereichs sollte die Anforderung begründen, das technische Team oder der Berater sollte Risiko und Wartungsauswirkungen bewerten, und die endgültige Entscheidung sollte der Lenkungskreis des Projekts treffen. Diese Dreierstruktur verhindert, dass Anforderungen aufgrund persönlicher Vorlieben wachsen, und hält die Entscheidungsspur nachvollziehbar fest.

Fazit: ERP-Anpassung ist kein Ziel, sondern ein Budget

ERP-Anpassung ist in jedem Projekt nötig, muss aber in dem Wissen um ihre Grenzen erfolgen. Schützen Sie die Prozesse, die einen Wettbewerbsvorteil schaffen, nutzen Sie bei allem Standardmäßigen die Möglichkeiten des Systems und setzen Sie unvermeidliche Anpassungen außerhalb des Kerns um, dokumentiert und testbar. Wer jede Anforderung zuerst nach ihrer Ebene und dann nach ihren Wartungskosten bewertet, schützt sowohl das Projektbudget als auch die künftige Flexibilität des Systems.

Wenn Sie die Anpassungsentscheidungen in Ihrem bestehenden oder geplanten ERP-Projekt gemeinsam überprüfen möchten, kann Sie unser Team von der Fit-Gap-Analyse bis zum Architekturdesign begleiten. Um Ihre Anforderungsliste zu teilen und eine erste Einschätzung zu erhalten, nehmen Sie Kontakt mit uns auf.