Standardsoftware oder Individualsoftware? Das ehrliche Make-or-Buy-Framework fürs ERP

Wer „Standardsoftware vs. Individualsoftware” oder „Make or Buy ERP” sucht, findet eine erstaunlich uniforme Suchergebnisseite: Dutzende Pro-und-Contra-Tabellen, fast deckungsgleich aufgebaut — und fast alle münden in derselben Empfehlung, nämlich das anpassbare Standardprodukt des jeweiligen Anbieters zu kaufen. Das ist kein Zufall. Wer die Tabelle schreibt, verkauft meist das, was am Ende der Tabelle steht. Dieser Leitfaden versucht das Gegenteil: eine neutrale Entscheidungslogik aus der Perspektive von jemandem, der beides baut und integriert — und dem es egal ist, ob ihr am Ende kauft oder baut, solange es das Richtige ist.

Warum die meisten Vergleiche schieflaufen

Das Problem ist strukturell, nicht böswillig. Ein Anbieter von Standard-ERP hat ein Interesse daran, dass „individuell” als teuer, langsam und riskant erscheint. Eine Individualentwicklungs-Agentur hat das umgekehrte Interesse. Beide Seiten schreiben ihre Vergleiche entlang dieser Voreinstellung — und die Pro-und-Contra-Tabelle ist genau das Format, in dem sich eine Voreinstellung am elegantesten verstecken lässt. Man muss nur die Zeilen auswählen, die zur gewünschten Schlusszeile führen.

Der tiefere Fehler liegt aber in der Achse selbst. „Standard vs. individuell” ist die falsche Frage, weil sie suggeriert, ein Unternehmen müsse sich pauschal für eine Seite entscheiden. Das tut es nie. Kein Mittelständler baut seine eigene Finanzbuchhaltung, und kaum einer findet von der Stange genau die Logik, mit der er sich vom Wettbewerb abhebt. Die nützliche Linie verläuft nicht zwischen Standard und individuell, sondern zwischen Commodity und Differenzierer — und die liegt quer zu jeder Anbieter-Tabelle. Genau das macht sie ehrlicher: Sie verläuft mitten durch euer System, nicht an seinem Rand.

Was man immer kaufen sollte: Commodity

Es gibt einen großen Bereich betrieblicher Software, in dem Eigenentwicklung schlicht keinen Sinn ergibt. Buchhaltung, Lohnabrechnung, Umsatzsteuer-Voranmeldung — das sind gelöste, regulierte, für alle gleiche Probleme. Niemand gewinnt einen Kunden, weil sein Hauptbuch origineller ist oder seine Lohnsteuer-Anmeldung eleganter berechnet wird. Im Gegenteil: Hier ist Abweichung vom Standard ein Risiko, kein Vorteil, weil der Gesetzgeber die Regeln vorgibt und der Anbieter sie für euch aktuell hält.

Standardsoftware ist in diesem Feld nicht der Kompromiss, sondern die richtige Wahl — und das gehört in einem ehrlichen Vergleich klar gesagt, bevor man auf die Gegenseite kommt. Ein etabliertes Standardsystem bringt jahrzehntelang gehärtete Logik, regulatorische Updates, ein Ökosystem aus Beratern und eine Stabilität mit, die man selbst kaum nachbaut. Für Commodity-Funktionen heißt die ehrliche Empfehlung: kaufen, nicht bauen. Wer hier individuell entwickelt, zahlt für Originalität, die niemand braucht, und übernimmt eine Wartungslast, die der Anbieter sonst trägt.

Was sich zu bauen lohnt: der Differenzierer

Anders sieht es genau dort aus, wo ein Unternehmen tatsächlich anders arbeitet als der Wettbewerb: die Art, wie ihr kalkuliert, wie ihr Aufträge konfiguriert und plant, wie ihr eine bestimmte Kundengruppe oder ein Nischensegment bedient, wie ihr eure spezielle Produktionslogik steuert. Das ist der Teil, der euch unterscheidet — und genau der Teil, den ein Standard-ERP per Bauart nicht kennen kann. Standardsoftware bildet den Durchschnitt einer Branche ab; euer Vorteil ist die Abweichung vom Durchschnitt. Diese beiden Dinge sind nicht versehentlich im Konflikt, sie sind es prinzipiell.

Was dabei passiert, ist in der Praxis immer dasselbe Muster: Wo der Prozess euer Wettbewerbsvorteil ist, presst ihr ihn in die Zwänge der Standardsoftware — und gebt ihn an der gefährlichsten Stelle ein Stück weit auf. Oder ihr baut eine wachsende Schicht aus Excel-Tabellen, Zusatztools und Workarounds über das ERP, die genau diesen Vorteil außerhalb des Systems abbildet. Beides ist teuer, nur auf unterschiedliche Weise. Daraus folgt die Kernregel, die wir auch dem Pillar-Artikel zu individueller ERP-Software zugrunde legen:

Standard kaufen, wo Software Commodity ist. Maßgeschneidert bauen, wo der Prozess euer Wettbewerbsvorteil ist.

Das ist kein Entweder-oder. Oft ist die richtige Architektur hybrid: ein solider Standard-Kern für die Commodity-Funktionen, integriert mit maßgeschneiderten Modulen dort, wo es zählt. Unsere Dokumenten-Pipeline ist genau so ein Custom-Modul — sie liest Belege template-frei aus und legt sie über offizielle Schnittstellen im bestehenden ERP an, statt es zu ersetzen.

Die versteckten Kosten beider Wege

Ein ehrlicher Vergleich zeigt beide Kostenseiten, nicht nur die unbequeme der Gegenpartei. Fangen wir mit der Individualentwicklung an: Sie kostet im Bau, und sie kostet in der Wartung. Wer ein eigenes System baut, übernimmt Verantwortung für Architektur, Tests, Betrieb und Weiterentwicklung — das ist real und gehört in jede Rechnung. Wird das Engineering vernachlässigt, kippt der Vorteil schnell ins Gegenteil. Die klassische Mahnung dazu liefern McKinsey und die University of Oxford in ihrem heute fast schon zeitlosen Benchmark von 2012: Große IT-Projekte (über 15 Mio. US-Dollar) liefen im Schnitt 45 Prozent über Budget und lieferten 56 Prozent weniger Wert als vorhergesagt. Eigenbau ohne Disziplin ist teuer — das war nie strittig.

Die Standard-Seite hat aber eine eigene, oft kleingeredete Kostenstruktur. Sie besteht nicht nur aus der Lizenz, sondern aus mindestens drei weiteren Posten: erstens den Anpassungskosten beim Einführen, zweitens der Anpassungs-Wartung bei jedem Release — denn jede individuelle Modifikation an einem Standardsystem ist eine Hypothek, die bei jedem Update erneut fällig wird — und drittens der Workaround-Schicht aus Tools und Tabellen, die das System nicht abdeckt. Trovarits „ERP in der Praxis 2024/25” (Stand 25.09.2024, über 1.700 Anwenderunternehmen, über 40 Systeme), die größte unabhängige Anwenderstudie im deutschsprachigen Raum, benennt genau diese Schmerzpunkte: Sie kritisiert ausdrücklich den Aufwand bei Release-Wechseln und die lückenhafte Dokumentation von Anpassungen. Bemerkenswert ist ein zweiter Befund derselben Studie: Die ERP-Zufriedenheit liegt im Schnitt bei Schulnote 1,80 — aber sie sinkt mit der Komplexität. Kleine, spezialisierte Lösungen schneiden besser ab als große, stark angepasste Standard-Installationen.

Und die Standard-Wahl endet überraschend oft beim Selberbauen — nur unkoordiniert. Panorama Consulting beziffert im 2024 ERP Report das Median-ERP-Projekt auf rund 450.000 US-Dollar und 15,5 Monate, mit „unerwartet nötiger Zusatz-Technologie” und spät entdeckten Misfits als Haupttreibern von Überschreitungen — Misfits, die dann zu Scope-Ausweitung und nachträglichen Custom-Builds führen. Anders gesagt: Der vermeintlich sichere Kauf-Weg mündet häufig in genau die Individualentwicklung, die man vermeiden wollte — nur teurer, weil sie als ungeplanter Umweg über die fehlgekaufte Lizenz kommt.

Ein praktischer Entscheidungs-Test

Kein Framework ersetzt das Nachdenken über den konkreten Fall. Die folgenden Fragen trennen die Fälle aber zuverlässiger als jede Anbieter-Tabelle:

• Ist der Prozess euer Wettbewerbsvorteil — und bildet die Stange ihn ab? Wenn er euch unterscheidet und kein Standardprodukt ihn trifft: starker Build-Kandidat. Wenn es Commodity ist: kaufen.
• Passt ihr euch der Software an oder die Software euch? Wenn ihr eure Arbeitsweise verbiegt, um das Standardsystem glücklich zu machen, zahlt ihr dauerhaft drauf — meist genau am Differenzierer.
• Wächst eine Workaround-Schicht aus Excel und Zusatztools über dem System? Das ist das deutlichste Signal, dass der Standard die Realität nicht mehr trägt.
• Wie kritisch sind Datenhoheit und Integrationstiefe? Je sensibler eure Konditionen, Kalkulationslogik und Kundendaten und je tiefer die nötige Anbindung, desto eher individuell — und desto wichtiger, dass das System bei euch läuft und zu euch passt.
• Ist „das System” in Wahrheit ein Tool-Flickenteppich? Dann lautet die Frage nicht Standard gegen Custom, sondern Konsolidierung. Dazu: SaaS-Wildwuchs und Insellösungen ablösen.

Was sich in den letzten Jahren verschoben hat, ist die Schwelle für „bauen”: KI-Coding-Agenten senken die Kosten der Eigenentwicklung spürbar — wenn die Engineering-Disziplin stimmt. Wie das die Make-or-Buy-Rechnung verändert, vertiefen wir in ERP mit KI-Coding-Agenten entwickeln. Was sich dadurch nicht ändert: Für Commodity bleibt Kaufen die richtige Antwort.

Häufige Fragen

Standardsoftware oder Individualsoftware — was ist besser? Keines von beidem pauschal. Standardsoftware ist die richtige Wahl für Commodity-Funktionen wie Buchhaltung, Lohn und Umsatzsteuer — gelöste, regulierte Probleme, mit denen niemand Kunden gewinnt. Individualsoftware lohnt sich dort, wo ein Prozess euer Wettbewerbsvorteil ist und kein Standardprodukt ihn abbildet. Die ehrliche Faustregel: Commodity kaufen, den Differenzierer bauen.

Wie entscheide ich Make or Buy beim ERP konkret? Trennt die Frage nicht nach „Standard vs. individuell”, sondern nach „Commodity vs. Differenzierer”. Fragt für jeden Kernprozess: Unterscheidet er uns vom Wettbewerb, und bildet die Stange ihn ab? Verbiegen wir uns für die Software oder umgekehrt? Wächst eine Workaround-Schicht? Wie kritisch sind Datenhoheit und Integration? Die Antworten verlaufen meist quer durchs System — also baut man hybrid: Standard-Kern plus Custom-Module dort, wo es zählt.

Soll man ein ERP selbst bauen oder kaufen? Kaufen, wo Software Commodity ist — den Anbieter die regulatorischen Updates tragen lassen. Bauen, wo der Prozess euer Differenzierer ist, tiefe Integration oder Datenhoheit verlangt, oder wo „das System” in Wahrheit ein Flickenteppich aus Insel-Tools ist, der konsolidiert gehört. Wichtig ist die ehrliche Kostenrechnung: Eigenbau kostet in Bau und Wartung, Standard kostet in Lizenz, Anpassung, Release-Wartung und Workaround-Schicht. Die teuerste Variante ist meist die falsch gewählte.

Ist Individualsoftware nicht grundsätzlich teurer und riskanter? Sie ist anders teuer, nicht automatisch teurer — und der Risiko-Einwand stammt aus Vor-KI-Zeiten. Große IT-Projekte ohne Engineering-Disziplin liefen historisch deutlich über Budget (McKinsey/Oxford, 2012), das stimmt. Aber der Standard-Weg endet laut Panorama (2024) oft selbst im ungeplanten Custom-Build, nur teurer. Entscheidend ist nicht Standard oder Custom, sondern ob das Engineering stimmt — und dass ihr für Commodity nicht baut, was es fertig gibt.

Fazit

Die meisten Make-or-Buy-Vergleiche sind keine Entscheidungshilfen, sondern Verkaufsprospekte mit Tabellenformat. Die neutrale Logik ist einfacher und unbequemer zugleich: Trennt nicht nach Standard oder individuell, sondern nach Commodity oder Differenzierer. Commodity kauft man — niemand gewinnt mit einem originelleren Hauptbuch. Den Differenzierer baut man, weil ihn die Stange per Bauart nicht kennt und jeder Workaround ihn aus dem System drängt. Beide Wege haben echte Kosten, und ein ehrlicher Vergleich zeigt beide. Wer dort, wo er anders ist als der Wettbewerb, auch seine Software anders baut — und den Rest kauft — trifft die Entscheidung, die keine Anbieter-Tabelle für ihn treffen wird. Ein Hinweis zum „bauen“: Gemeint ist nicht, lauter Einzelmodule an den Standard zu kleben — das wäre nur der nächste Flickenteppich. Aus erprobten, wiederverwendbaren Komponenten entsteht ein zusammenhängendes System, das genau zu eurem Betrieb passt; wann und wie sich das lohnt.

---

kitun ist eine AI-native Software-Manufaktur für den Mittelstand: Zwei Senior-Architekten und Coding-Agents bauen Custom Business-Software und ERP-Module — on-premise oder EU-gehostet, ohne Abo und ohne Lizenz pro Nutzer. Im 20-minütigen Erstgespräch klären wir ehrlich, welcher Weg für euren Fall der richtige ist.

→ Die Lösung im Überblick: Custom ERP mit kitun

→ Der ausführliche Leitfaden: Individuelle ERP-Software für den Mittelstand · Proof: SaaS-Plattform heysuma