Standardsoftware oder Individualsoftware im ERP
Wie Unternehmen die Make-or-Buy-Frage für ihr ERP je Prozess entscheiden, wo eine Eigenentwicklung trägt und was KI an der Rechnung ändert
Kernaussagen
- Für den ERP-Kern ist Standardsoftware die Regel. Finanzbuchhaltung, Einkauf, Lager und Auftragsabwicklung unterscheiden ein Unternehmen selten vom Wettbewerb, und dort pflegt der Hersteller Funktionen und gesetzliche Änderungen für alle Kunden.
- Entschieden wird je Prozess. Je stärker ein Prozess das Unternehmen vom Wettbewerb unterscheidet, desto weiter darf die Lösung vom Standard abweichen, bis hin zur eigenen Anwendung neben dem ERP.
- KI-Werkzeuge senken vor allem den Aufwand, neuen Code zu schreiben. Betrieb, Wartung, Pflichten wie die GoBD und das Wissen über den Code bleiben bei dem Unternehmen, das selbst entwickelt [6].
- In der Auswahl wird das Erweiterungsmodell eines ERP damit so wichtig wie seine Abdeckung im Standard: Die Individualität, die bleibt, braucht einen Platz, der Updates übersteht.
Die Definitionen ziehen die Grenze an unterschiedlichen Stellen
Make or Buy bezeichnet im Gabler Wirtschaftslexikon die Wahl zwischen Eigenproduktion und Fremdbezug. Für jede Aktivität stellt sich die Frage, ob das Unternehmen sie selbst erbringt und koordiniert oder als Marktleistung zukauft; in die Rechnung gehören auch die Transaktionskosten, die bei der Koordination entstehen [4]. Bei Software heißt das: selbst entwickeln oder Standardsoftware kaufen. Wo die Grenze zwischen beiden verläuft, beschreiben die Quellen unterschiedlich.
| Quelle | Definition (sinngemäß, gekürzt) | Schwerpunkt |
|---|---|---|
| Gabler Wirtschaftslexikon, Individualsoftware [1] | Software, die für den Einsatz in einem speziellen Betrieb entwickelt wird, in Eigenerstellung oder im Auftrag eines externen Softwareherstellers. Gegensatz ist die Standardsoftware | Für wen die Software entsteht |
| Gabler Wirtschaftslexikon, Standardsoftware [2] | Software, die zu einem Anwendungsgebiet für den anonymen Markt erstellt wird. Sie muss an die Anforderungen der Benutzer angepasst oder auf die Ablauforganisation ausgerichtet werden (Customizing) | Markt statt Einzelkunde, Anpassung gehört dazu |
| BSI, IT-Grundschutz-Baustein APP.7 [3] | Softwarelösungen, die auf die Bedürfnisse einer Institution zugeschnitten sind. Dazu zählen Basislösungen wie ERP-Systeme, deren Grundfunktionen angepasst und um individuell benötigte Funktionen erweitert werden, ebenso vollständige Neuentwicklungen | Zuschnitt, auch beim angepassten Standard |
Gabler grenzt nach der Entstehung ab: für einen Betrieb oder für den Markt. Das BSI zieht die Grenze weiter. Wer ein ERP anpasst und um eigene Funktionen erweitert, entwickelt aus Sicht der Informationssicherheit bereits Individualsoftware und muss Sicherheit und Dokumentation von Anfang an mitplanen [3]. Für ERP-Entscheidungen ist diese zweite Sicht die brauchbarere, weil sie auf die Pflege nach der Einführung zielt. Die allgemeine Abwägung für jede Art von Software beschreibt find-your-software.de unter Standardsoftware vs. Individualsoftware.
Unser Verständnis
Wir ordnen ERP-Lösungen je Prozess ein, und zwar danach, wer sie pflegt. Im Standard pflegt der Hersteller Funktion, Updates und gesetzliche Änderungen. Bei der Konfiguration nutzt das Unternehmen Einstellungen, die der Hersteller vorgesehen hat. Ab der Erweiterung pflegt das Unternehmen eigene Logik, und bei der Individualentwicklung trägt es Code, Betrieb und Dokumentation einer ganzen Anwendung. Individualsoftware im engen Sinn ist ein vollständiges System, das für ein Unternehmen entwickelt wurde (siehe Glossar, Individualsoftware). Für die Entscheidung zählt aber jeder Anteil eigener Logik, auch im Standard-ERP. Die Make-or-Buy-Entscheidung fällt im ERP deshalb je Prozess, und für den Kern fällt sie in aller Regel auf den Standard.
Das ERP ist von der Eigenentwicklung zum Standard mit Erweiterungen gewandert
Viele Unternehmen setzten früher für ihre betrieblichen Abläufe auf eigene Entwicklungen, etwa auf IBM AS/400, und lösen sie seitdem Schritt für Schritt ab. Mit dem Wechsel auf ein Standard-ERP verschwand die Individualität nicht, sie zog in das System ein. In On-Premise-Installationen hieß das oft, den Programmcode des Herstellers zu ändern. Tiefe Eingriffe in den Systemkern machen jedes neue Release teurer (siehe Glossar, Standardsoftware).
Eine Literaturstudie von Abendroth, Bender und Gronau zeigt, dass Anpassungen in Cloud-ERP-Systemen über Schnittstellen und Integration laufen statt über Änderungen am ERP-Code wie in On-Premise-Systemen [5] (siehe Glossar, Clean Core). Heute denkt man Individualentwicklung eher in Modulen oder Erweiterungen. Die Frage nach Standard oder Individual stellt sich damit selten für das ganze ERP und meist für einzelne Prozesse. Wo eine Erweiterung im System bleibt und wo sie daneben läuft, beschreibt das Stufenmodell im Beitrag zum ERP-Customizing.
Mit der aktuellen Entwicklung der KI wird die Frage wieder häufiger diskutiert. Wenn Programmieren billiger wird, liegt der Gedanke nahe, das ERP doch wieder selbst zu bauen. Wie weit er trägt, hängt an den Kosten, die nach dem Programmieren kommen.
Im Beispiel bleibt nur die Ersatzteilsuche eine Eigenentwicklung
Ein Hersteller von Anbaugeräten für die Landtechnik verkauft über Landmaschinenhändler und liefert Ersatzteile auch für Geräte, die seit Jahrzehnten im Einsatz sind. Seine Auftragsabwicklung und Ersatzteilverwaltung laufen auf einer Eigenentwicklung, die die eigene IT vor langer Zeit gebaut hat. Sie läuft stabil, doch nur noch zwei Mitarbeitende verstehen den Code, und jede gesetzliche Änderung wird zum Projekt. Die Geschäftsführung will das System ablösen und entscheidet je Prozess mit einer Leitfrage: Wie stark unterscheidet dieser Prozess das Unternehmen vom Wettbewerb?
| Prozess | Unterscheidet er das Unternehmen? | Lösung | Pflege liegt bei |
|---|---|---|---|
| Finanzbuchhaltung, Mahnwesen, Zahlungsverkehr | nein, gesetzlich und branchenüblich geregelt | Standard | Hersteller |
| Einkauf, Lager, Fertigung, Auftragsabwicklung | nein | Standard mit Konfiguration, etwa Lagerorte, Dispositionsparameter und Freigaben | Hersteller, die Einstellungen beim Unternehmen |
| Händlerpreise und Konditionen | kaum, Konditionen hat jeder Hersteller | Konfiguration | Hersteller, die Einstellungen beim Unternehmen |
| Garantieanträge der Händler | teilweise, der Ablauf ist eingespielt und den Händlern wichtig | Erweiterung an vorgesehenen Punkten im ERP | Unternehmen oder Implementierungspartner, mit Tests bei jedem Update |
| Ersatzteilsuche über die Seriennummer, auch für ersetzte Teile | ja, darüber bindet der Hersteller seine Händler | eigene Anwendung neben dem ERP, über Schnittstellen angebunden | Unternehmen: Code, Betrieb und Dokumentation |
| Sonderauswertungen und Druckprogramme aus dem Altsystem | nein, Gewohnheit | entfallen oder durch Standardberichte ersetzt | entfällt |
Lehrbeispiel, kein Kundenprojekt.
Übrig bleibt eine einzige Eigenentwicklung, und sie läuft neben dem ERP. Die Ersatzteilsuche liest Stücklisten und Bestände aus dem ERP und legt dort die Aufträge der Händler an; gebucht wird nur im Standard. So bleibt der Kern updatefähig, und die eigene Anwendung lässt sich unabhängig weiterentwickeln. Wie stark ein Prozess das Unternehmen wirklich unterscheidet, zeigt sich oft erst, wenn das Team den Standard kennt. Vor der Erweiterung für die Garantieanträge lohnt deshalb ein kurzer Test mit echten Vorgängen im Standard.
KI senkt die Kosten des Programmierens, nicht die des Betriebs
KI-Werkzeuge beschleunigen das Schreiben von Code. In einem kontrollierten Experiment lösten Entwickler mit einem KI-Assistenten eine abgegrenzte Programmieraufgabe 55,8 Prozent schneller als die Vergleichsgruppe [7]. Eine randomisierte Studie aus dem Jahr 2025 kam bei erfahrenen Entwicklern in großen, über Jahre gewachsenen Open-Source-Projekten zum umgekehrten Ergebnis: Mit KI-Werkzeugen brauchten sie 19 Prozent länger, obwohl sie selbst mit einer Beschleunigung gerechnet hatten [8]. Eine selbst entwickelte Warenwirtschaft ist nach wenigen Jahren genau so ein gewachsenes Projekt.
Die größeren Kosten einer Eigenentwicklung entstehen ohnehin nach dem ersten Programmieren. Gabler nennt als Vorteile der Standardsoftware gegenüber der Eigenentwicklung unter anderem geringere Entwicklungs- und Wartungskosten, eine bessere Dokumentation und eine geringere Abhängigkeit von einzelnen Entwicklern [2]. KI-Werkzeuge verschieben davon vor allem den ersten Punkt.
| Aufgabe über die Lebensdauer | Was KI-Werkzeuge ändern | Was beim Unternehmen bleibt |
|---|---|---|
| Neue Funktionen programmieren | bei abgegrenzten Aufgaben schneller [7] | Anforderungen klären, Ergebnis prüfen und abnehmen |
| Gewachsenen Code weiterentwickeln | Wirkung offen, in einer Studie langsamer [8] | Architektur verstehen, Fehler eingrenzen, Nebenwirkungen testen |
| Gesetzliche Änderungen umsetzen | schneller programmiert, sobald klar ist, was sich ändert | Änderungen erkennen und rechtzeitig umsetzen, etwa bei der E-Rechnung |
| Verfahrensdokumentation nach GoBD | Entwürfe für Texte | Dokumentation vollständig halten und für jede eingesetzte Programmversion nachweisen [6] |
| Betrieb und Sicherheit | wenig | Plattform aktualisieren, Daten sichern, Berechtigungen pflegen, Störungen beheben |
| Wissen über das System | Erklärungen auf Abruf | Menschen, die das System verantworten und bei Personalwechsel weiterführen |
Einordnung von Find-Your-ERP auf Grundlage von [2], [6], [7] und [8].
Die GoBD machen den Unterschied für Buchhaltung und Warenwirtschaft greifbar. Für die Ordnungsmäßigkeit ist allein das Unternehmen verantwortlich, auch wenn es Aufgaben an Dritte auslagert [6]. Jedes DV-System braucht eine Verfahrensdokumentation, ausdrücklich auch Warenwirtschaft, Fakturierung und die Schnittstellen zwischen den Systemen, und für die gesamte Aufbewahrungsfrist muss nachgewiesen sein, dass sie den eingesetzten Programmversionen entspricht [6]. Beim Standard-ERP liefert der Hersteller einen großen Teil der Anwender- und Systemdokumentation und setzt gesetzliche Änderungen in Updates um; bei einer Eigenentwicklung erledigt das Unternehmen beides selbst. Wie oft sich die Vorgaben bewegen, zeigt die E-Rechnung: Ihre Einführung zwischen inländischen Unternehmen seit Januar 2025 hat eine weitere Änderung der GoBD nach sich gezogen [6]. Die Kurzdefinition steht im Glossar unter GoBD.
Wann Fachbereiche mit KI-Werkzeugen selbst bauen können und wann Profis übernehmen sollten, beschreibt find-your-software.de unter Vibe Coding im Unternehmen.
Customizing, Clean Core, Composable ERP und Legacy beantworten angrenzende Fragen
Vier Begriffe fallen in diesem Zusammenhang fast immer. Jeder berührt die Make-or-Buy-Frage, keiner ersetzt sie.
| Begriff | Frage dahinter | Bezug zu Standard oder Individual |
|---|---|---|
| Customizing | Wie wird ein Standard-ERP über die Konfiguration hinaus angepasst? | eigene Logik im oder am Standard; je tiefer der Eingriff, desto näher an der Individualsoftware |
| Clean Core | Wie bleibt der ERP-Kern updatefähig? | Individualität wandert an vorgesehene Erweiterungspunkte oder neben den Kern |
| Composable ERP | Welche Prozesse laufen im Kern, welche in eigenständigen Bausteinen? | ein Baustein kann ein zugekauftes Produkt oder eine Eigenentwicklung sein |
| Legacy-System | Wann trägt ein eingesetztes System nicht mehr? | eine Spielart ist die Individualsoftware, die nicht mehr dem heutigen Stand entspricht |
Einordnung von Find-Your-ERP auf Grundlage des ERP-Glossars.
Die Kurzdefinitionen stehen im ERP-Glossar unter Customizing, Clean Core, Composable ERP und Legacy-System. Customizing und Individualentwicklung gehen fließend ineinander über. Eine Erweiterung, die als eigener Dienst neben dem ERP läuft, hat eine eigene Release- und Betriebslogik und ist damit technisch eine kleine Individualsoftware, mit allen Pflichten, die daraus folgen.
Drei Annahmen führen zu teuren Eigenentwicklungen
In Auswahlprojekten begegnen uns drei Annahmen, die für eine Eigenentwicklung sprechen sollen und es bei näherem Hinsehen selten tun.
Die erste lautet, der eigene Prozess sei einzigartig. Oft beschreibt sie einen Ablauf, der sich unter den Grenzen des Altsystems eingespielt hat. Im Beitrag zum ERP-Customizing entfielen in einem Produktionsunternehmen acht von elf als zwingend formulierten Anforderungen, nachdem das Team zwei Wochen im Standard gearbeitet hatte.
Die zweite: Individualsoftware mache unabhängig. Sie ersetzt die Abhängigkeit vom Hersteller durch eine Abhängigkeit von den Menschen, die den Code kennen, im Beispiel von zwei Mitarbeitenden. Den Vendor-Lock-in beim Hersteller begrenzen Verträge mit Datenexport und Ausstiegsregeln, das Wissen in einzelnen Köpfen nur Dokumentation und Vertretung.
Die dritte: Ein angepasstes Standard-ERP bleibe Standardsoftware. Mit jeder Änderung am Kern übernimmt das Unternehmen einen Teil der Pflege, die vorher der Hersteller trug, im Sinne des BSI also Individualsoftware [3]. Wer viel angepasst hat, zahlt beim nächsten Release-Wechsel für beides.
In der Auswahl wird das Erweiterungsmodell zum Prüfpunkt
Die Make-or-Buy-Entscheidung gehört vor die Longlist. Im Anforderungskatalog markiert das Projektteam die wenigen Prozesse, in denen sich das Unternehmen unterscheidet, und legt fest, ob sie im ERP, als Erweiterung oder als eigene Anwendung daneben laufen sollen. Wie aus einer Wunschliste ein belastbarer Katalog wird, beschreibt der Beitrag ERP-Anforderungen richtig definieren. Für alle übrigen Prozesse ist der Standard das Ziel; wo er nicht reicht, zeigt die Fit-Gap-Analyse.
In der Anbieterpräsentation zeigt sich, ob ein System die verbleibende Individualität aufnehmen kann. Diese Prüffragen helfen dabei:
| Prüffrage | Woran Sie es erkennen |
|---|---|
| Wo sieht das System Erweiterungen vor? | Der Anbieter zeigt Erweiterungspunkte im System und den Weg für Anwendungen daneben, mit Beispielen aus Ihrer Branche |
| Überstehen Erweiterungen ein Update? | Er benennt, welche Schnittstellen und Erweiterungspunkte als updatestabil freigegeben sind und wie lange ältere Versionen unterstützt werden |
| Wer pflegt die Erweiterungen nach dem Go-live? | Das Angebot nennt Pflege, Tests bei Updates und Zuständigkeit je Erweiterung, getrennt vom Einführungsprojekt |
| Kommen gesetzliche Änderungen mit dem Update? | Der Anbieter beschreibt, wie er Änderungen wie die E-Rechnung ausliefert und was das Unternehmen dafür selbst tun muss |
| Wie werden Erweiterungen dokumentiert? | Jede Erweiterung ist mit Version und Verantwortlichem beschrieben, sodass sie in die Verfahrensdokumentation eingehen kann |
| Welche Bescheinigungen liegen vor? | Testate oder Zertifikate Dritter dienen als Entscheidungskriterium, binden die Finanzbehörde aber nicht [6] |
| Kommen die Daten wieder heraus? | Ein vollständiger Export von Stammdaten und Belegen ist vertraglich zugesichert |
Welche Prozesse in den Kern gehören und wo eine eigene Anwendung sinnvoll ist, klären wir mit Unternehmen in der Leistung ERP-Strategie und Roadmap.
Häufige Fragen
Was passiert mit gewachsenen Eigenentwicklungen, wenn ein neues ERP kommt?
Jede Eigenentwicklung kommt mit Zweck, Nutzern, Daten und den Menschen, die sie kennen, auf eine Liste und wird nach derselben Leitfrage eingeordnet wie die Prozesse. Ein großer Teil entfällt oder geht im Standard auf, wenige werden als Erweiterung neu gebaut. Die Daten der abgelösten Systeme müssen für die Aufbewahrungsfrist auswertbar bleiben. Das Altsystem muss nur dann nicht weiter vorgehalten werden, wenn die aufbewahrungspflichtigen Daten samt Stamm- und Bewegungsdaten und ihren Verknüpfungen gleichwertig in ein anderes System überführt sind [6].
Lohnt sich bei rund 200 Mitarbeitenden ein eigenes ERP, wenn der Standard nicht passt?
Selten. Passt ein Standard-ERP bei den Pflichtprozessen nicht, ist zuerst zu prüfen, ob es das falsche System ist, denn das falsche System bleibt auch angepasst das falsche System. Eine Branchenlösung oder ein anderes Standardprodukt deckt die Prozesse oft besser ab. Ein eigenes ERP verlangt dauerhaft ein Team, das Buchhaltung, Steuerrecht, Schnittstellen und Betrieb beherrscht, und das ist in dieser Größe kaum zu halten. Realistischer ist ein Standard-ERP mit wenigen Erweiterungen und, wo nötig, einer eigenen Anwendung für den Prozess, der das Unternehmen ausmacht.
Sollte der Implementierungspartner oder ein eigenes Team die Erweiterungen entwickeln?
Der Partner kennt das Erweiterungsmodell des Systems und baut schneller, das eigene Team kennt den Prozess und bleibt nach dem Projekt im Haus. Bewährt hat sich eine Teilung: Der Partner entwickelt nach den Regeln des Herstellers, und im Unternehmen versteht mindestens eine Person jede Erweiterung fachlich und entwickelt sie mit dem Partner weiter. Nutzungsrechte am Code, Dokumentation und Pflege bei Updates gehören in den Vertrag. Was einen Implementierungspartner ausmacht, steht im Glossar unter Implementierungspartner.
Weiterlesen
Kurzdefinitionen zu Individualsoftware, Standardsoftware, Make-or-Buy, Customizing und Composable ERP.
Das Stufenmodell von der Konfiguration bis zur Kernmodifikation und die Kriterien, nach denen jede Anpassung bewertet wird.
Wie aus Wunschlisten ein Anforderungskatalog wird, der Pflicht von Gewohnheit trennt.
Zielarchitektur und Umsetzungspfad für Kern, Erweiterungen und eigene Anwendungen: unser Beratungsangebot.
Die Grundsatzentscheidung für jede Art von Software, mit Kostenblöcken und Mischformen wie Low-Code.
Wann Fachbereiche mit KI-Werkzeugen selbst bauen können und wann Profis übernehmen sollten.
Quellen
[1] Lackes, R.; Siepermann, M.: Individualsoftware. Gabler Wirtschaftslexikon, Springer Gabler. Abgerufen am 9. November 2026.
[2] Lackes, R.; Siepermann, M.: Standardsoftware. Gabler Wirtschaftslexikon, Springer Gabler. Abgerufen am 9. November 2026.
[3] Bundesamt für Sicherheit in der Informationstechnik (2023): APP.7 Entwicklung von Individualsoftware. IT-Grundschutz-Kompendium, Edition 2023. Abgerufen am 9. November 2026.
[4] Schewe, G.: Make or Buy. Gabler Wirtschaftslexikon, Springer Gabler. Abgerufen am 9. November 2026.
[5] Abendroth, A.; Bender, B.; Gronau, N. (2024): The Evolution of Original ERP Customization: A Systematic Literature Review of Technical Possibilities. Proceedings of the 26th International Conference on Enterprise Information Systems (ICEIS 2024), S. 17–27.
[6] Bundesministerium der Finanzen (2019): Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD). BMF-Schreiben vom 28. November 2019, BStBl I S. 1269, geändert am 11. März 2024 und am 14. Juli 2025; herangezogen Rz. 20, 21, 142, 151 bis 154 und 179 bis 181 sowie der Anlass der Änderung von 2025. Abgerufen am 9. November 2026.
[7] Peng, S.; Kalliamvakou, E.; Cihon, P.; Demirer, M. (2023): The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590.
[8] Becker, J.; Rush, N.; Barnes, E.; Rein, D. (2025): Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089.
Dr. Benedict Bender
Co-Founder der Sectorlens GmbH
Besprechen Sie Ihre Make-or-Buy-Entscheidung mit einem ERP-Berater
Im Gespräch klären Sie mit einem Berater, welche Prozesse Ihr ERP im Standard abdecken sollte und wo sich eine eigene Lösung rechnet. 30 Minuten, kostenlos und unverbindlich. Anbieterneutral: Kein Anbieter kann seine Platzierung kaufen oder beeinflussen.
Sie haben eine Frage? Dann schicken Sie uns gern eine Nachricht.