Am Anfang einer Softwareauswahl steht fast immer dieselbe Tabelle: links die Anforderungen, oben die Anbieter, in den Zellen ein Häkchen, ein halbes Häkchen oder ein Strich. Am Ende steht ein Deckungsgrad in Prozent, und ab einer bestimmten Schwelle gilt die Sache als entschieden. Die Tabelle ist handwerklich sauber und beantwortet trotzdem die falsche Frage.

Sie misst, wie gut ein Produkt zum heutigen Ablauf passt, und unterstellt damit, dass der heutige Ablauf erhaltenswert ist. Meistens ist er das nicht: Er ist so entstanden, weil vor zwölf Jahren jemand eine Excel-Datei angelegt hat, und niemand hat ihn seitdem geprüft. Wo ein Ablauf beliebig ist, spricht eine schlechte Passung nicht gegen den Kauf, sondern für eine Änderung des Ablaufs. Die Entscheidung fällt deshalb nicht zwischen zwei Produktgattungen, sondern an einer einzigen Eigenschaft des Vorgangs selbst.

Warum der Deckungsgrad in die Irre führt

Ein Deckungsgrad von 85 Prozent klingt nach einer guten Nachricht und ist in Wahrheit eine offene Frage: Was passiert mit den restlichen 15 Prozent? Dafür gibt es zwei Wege. Entweder wird das Produkt angepasst — durch Customizing, Zusatzmodule oder Schnittstellen. Oder der Ablauf im Unternehmen wird an das Produkt angepasst.

Die Trovarit AG, die seit 2004 die Anwenderstudie „ERP in der Praxis“ herausgibt, beobachtet eine Verschiebung zum zweiten Weg: Unternehmen greifen häufiger zur standardisierten Lösung, statt aufwendig individuell anzupassen. Entlastend wirkt das laut der Auswertung vom Juni 2023 nur auf den ersten Blick, denn dann müssen die Unternehmensprozesse der Software folgen — der Aufwand wandert in Schulung, Organisation und Akzeptanz.

Genau hier entscheidet sich alles. Einen austauschbaren Ablauf an ein Produkt anzupassen, ist unangenehm und danach erledigt. Einen Ablauf anzupassen, der die eigene Leistung von der des Wettbewerbs unterscheidet, heißt dagegen, diese Unterscheidung aufzugeben — gegen eine Lizenzgebühr, die jeder Mitbewerber ebenfalls zahlen kann.

Make or Buy ist eine Strategie-, keine Preisfrage

Die betriebswirtschaftliche Grundlage dieser Unterscheidung ist älter als jede Softwarekategorie. Michael E. Porters Wertkette gliedert ein Unternehmen in Primär- und Unterstützungsaktivitäten und fragt für jede einzelne, was sie zum Wert für den Abnehmer beiträgt. Das Gabler Wirtschaftslexikon fasst den entscheidenden Satz so zusammen: Jede Wertaktivität kann sowohl die Kostenposition als auch die Differenzierung beeinflussen. Wettbewerbsvorteile entstehen, wo relevante Aktivitäten günstiger ausgeführt werden als beim Wettbewerb — oder wo ihre Ausgestaltung dem Abnehmer mehr Nutzen stiftet.

C. K. Prahalad und Gary Hamel haben dafür 1990 im Harvard Business Review drei Prüfungen formuliert: Eine Kernkompetenz eröffnet Zugang zu einer Vielzahl von Märkten, sie leistet einen erkennbaren Beitrag zu dem Nutzen, den der Kunde am Endprodukt wahrnimmt, und sie ist schwer nachzuahmen. Im selben Aufsatz warnen die Autoren davor, Fähigkeiten auszulagern, die man fälschlich für bloße Kostenstellen hält. Übertragen auf Software: Ein Standardprodukt zu kaufen ist eine Auslagerungsentscheidung — richtig genau dann, wenn der ausgelagerte Vorgang keine der drei Prüfungen besteht.

Der Test in einem Satz: Ist dieser Vorgang austauschbar?

Aus beiden Modellen folgt eine einzige Prüffrage, die ohne Beratungsprojekt auskommt: Könnte ein Wettbewerber dieselbe Wirkung erzielen, indem er dieselbe Software kauft? Wo das zutrifft, entsteht durch eine eigene Lösung kein Vorsprung, sondern nur eine eigene Wartungspflicht.

Gestellt wird die Frage pro Vorgang, nicht pro Unternehmen. Ein Handelsbetrieb kann in der Lohnabrechnung vollständig austauschbar sein und in der Preisfindung nicht — und braucht dann für das eine ein Produkt von der Stange und für das andere eine eigene Anwendung. Wer auf Unternehmensebene entscheidet, entscheidet für beide Fälle falsch.

Wo Standardsoftware ausnahmslos gewinnt

Buchhaltung, Lohnabrechnung und Zeiterfassung sind die klassischen Beispiele, und zwar aus einem strukturellen Grund: Ihre Regeln kommen von außen, und sie ändern sich laufend — Beitragsbemessungsgrenzen, Meldeverfahren, Steuertabellen. Kein Unternehmen gewinnt einen Kunden mit einer besseren Lohnabrechnung.

Darin liegt der eigentliche Wert des Lizenzmodells: Wer ein Standardprodukt kauft, kauft die Verpflichtung des Anbieters, die regulatorische Nachführung zu übernehmen und auf tausende Kunden umzulegen. Bei einer eigenen Anwendung fällt dieselbe Arbeit jedes Jahr im eigenen Haus an, in voller Höhe, für einen einzigen Nutzer. Daraus folgt eine Faustregel: Wer nach dem Raster noch schwankt, nimmt Standardsoftware. Individualsoftware rechtfertigt sich durch einen klaren Befund in mindestens zwei der acht Zeilen, nicht durch Unentschiedenheit.

Was Standardsoftware tatsächlich kostet

Die Lizenz ist der kleinste Posten. Für ERP-Projekte im Mittelstand nennt die Trovarit AG auf Basis ihrer Anwenderstudie rund 6.000 Euro je Arbeitsplatz für Auswahl und Einführung, eine Projektdauer von etwa zwölf Monaten und ein Kernteam aus etwa fünf internen und zweieinhalb externen Beteiligten (Stand Juni 2023).

In der Betriebsphase kommen jährlich rund 500 Euro je Arbeitsplatz für den Wartungsvertrag hinzu; über 90 Prozent der Anwender haben einen solchen Vertrag, marktüblich sind Sätze zwischen 12 und 25 Prozent der Lizenzpreise. Für die Administration setzt Trovarit rund anderthalb Vollzeitstellen an, für Modernisierungen alle fünf Jahre etwa ein Drittel der Anschaffungskosten. Die Nutzungsdauer eines ERP-Systems beziffert die Studie auf knapp 13 Jahre.

Die 79-Prozent-Regel: der Kaufpreis entscheidet nichts

Wie wenig der Anschaffungspreis über die Gesamtkosten aussagt, hat eine Untersuchung des Instituts für Wirtschaftsinformatik der Universität St. Gallen quantifiziert. Rüdiger Zarnekow, Jochen Scheeg und Walter Brenner erhoben die Istkosten von 30 IT-Anwendungen bei der Deutschen Telekom, der Deutschen Bahn und einem Schweizer Ministerium und ordneten sie den Phasen Planung, Erstentwicklung, Produktion und Weiterentwicklung zu.

Auf fünf Jahre gerechnet entfielen 79 Prozent der Kosten auf Betrieb und Weiterentwicklung, 21 Prozent auf Planung und Erstentwicklung; laut den Autoren dürfte der reale Anteil eher höher liegen, weil Anwendungen meist länger laufen. Über die Einzelfälle schwankte der einmalige Anteil zwischen 4 und 40 Prozent — der Mittelwert taugt als Größenordnung, nicht als Planwert.

Das gilt für beide Wege. Wer über Kauf oder Eigenentwicklung entscheidet, entscheidet über etwa ein Fünftel der Kosten. Die übrigen vier Fünftel hängen daran, wie lange die Anwendung läuft und wie oft sie sich ändern muss — also wieder an der Beweglichkeit des Vorgangs.

Ein durchgerechnetes Beispiel über fünf Jahre

Aus beiden Datensätzen lässt sich ein Schwellenwert bilden. Angenommen wird ein Betrieb mit 25 betroffenen Arbeitsplätzen; für den Standardweg gelten die Trovarit-Erfahrungswerte, für den Vergleichswert die 21 Prozent aus der St. Gallener Erhebung. Internes Personal bleibt in beiden Spalten außen vor, weil es auf beiden Wegen anfällt.

Die letzte Zeile ist kein Preis, sondern eine Schwelle: Liegt der Aufwand für die erste lauffähige Version unter etwa 55.000 Euro, ist der Fünf-Jahres-Vergleich offen. Zwei Einschränkungen gehören dazu. Erstens deckt eine eigene Anwendung fast nie den Umfang eines ERP-Systems ab, sondern einen abgegrenzten Vorgang — der Vergleich trägt nur bei gleicher Aufgabe. Zweitens verschiebt die Spanne von 4 bis 40 Prozent die Schwelle erheblich: im ungünstigen Fall auf rund 10.500 Euro, im günstigen auf rund 105.000 Euro.

Der dritte Weg: quelloffene Software

Zwischen Kaufen und Selbstbauen liegt eine Option, die die Frage nach der Austauschbarkeit anders beantwortet: Quelloffene Software ist ein fertiges Produkt und erlaubt zugleich, es zu ändern — der austauschbare Anteil kommt fertig, der unterscheidende wird ergänzt. Nach dem Open Source Monitor 2025 des Digitalverbands Bitkom, für den 1.152 Unternehmen ab 20 Beschäftigten befragt wurden, setzen 73 Prozent quelloffene Software ein; 2023 waren es 69 Prozent.

Als größten Vorteil nennen 26 Prozent Kosteneinsparungen, gefolgt vom Zugriff auf den Quellcode mit 19 Prozent — also der Möglichkeit, anzupassen und auf Schwachstellen zu prüfen. Dagegen sprechen fehlende Fachkräfte (20 Prozent), unklare Gewährleistung (15 Prozent) und rechtliche Unsicherheit bei Lizenzpflichten (13 Prozent).

Der Haken ist derselbe wie bei jeder Eigenentwicklung, und die 79-Prozent-Regel kennt hier keine Ausnahme: Eine dauerhaft abweichende Kopie muss bei jedem Upstream-Release nachgezogen werden, im eigenen Haus. Wer Änderungen in das Projekt zurückgibt, gibt auch die Pflegelast zurück. Quelloffenheit senkt die Einstiegshürde für Anpassungen — nicht die Folgekosten dauerhafter Abweichungen.

Wo Individualsoftware regelmäßig scheitert

Die häufigste Fehlannahme lautet, eine eigene Anwendung scheitere an der Programmierung. Die St. Gallener Erhebung deutet anders: Hohe Weiterentwicklungskosten führen die Autoren mehrfach darauf zurück, dass Anwendungen unter Zeitdruck oder ohne ausreichende Tests in Betrieb gingen — Arbeit, die zur Erstentwicklung gehört hätte, fiel danach an. Bei knapp der Hälfte der Anwendungen waren die Kosteninformationen zudem so lückenhaft, dass sich die Lebenszykluskosten gar nicht analysieren ließen.

Der letzte Punkt betrifft weniger die Technik als die Vertragsform. Weil vier Fünftel der Kosten nach dem ersten Livegang anfallen, ist ein Projektvertrag mit Abnahme schlecht auf die Lebensdauer zugeschnitten. Es gibt Entwicklungspartner, die daraus eine Konsequenz ziehen: Wer dort Individualsoftware entwickeln lassen will, bekommt kein Projekt mit Endtermin, sondern eine monatliche Pauschale mit festem Entwicklungskontingent, in der Betrieb, Fehlerbehebung und Weiterentwicklung enthalten sind und in der Code und Zugänge vom ersten Monat an beim Auftraggeber liegen. Der Hamburger Anbieter Kaido Studios, der so arbeitet, benennt die Grenze des Modells selbst und rät bei austauschbaren Vorgängen wie Buchhaltung, Lohn und Zeiterfassung ausdrücklich zu Standardsoftware. Die Frage Individualsoftware oder Standardsoftware beantwortet eine Vertragsform nicht — sie verschiebt nur, wer die vier Fünftel trägt, die nach dem Start entstehen.

Wann die Entscheidung fällt

Die Prüfung lohnt an wenigen erkennbaren Punkten: wenn ein Wartungsvertrag zur Verlängerung ansteht, wenn ein Release-Wechsel den Aufwand einer Neueinführung erreicht, wenn eine Tabellenkalkulation neben dem System entsteht, oder wenn dieselbe Zahl an drei Stellen gepflegt wird. Bis dahin ist die bestehende Lösung in aller Regel die günstigste.

1. Vorgänge auflisten, nicht Systeme. Die Einheit der Entscheidung ist der einzelne Ablauf — Angebotserstellung, Disposition, Reklamation — nicht „das ERP“.
2. Je Vorgang das Raster durchgehen. Ein Ergebnis nahe der Mitte ist ein Votum für Standardsoftware.
3. Änderungsrate der letzten drei Jahre zählen. Diese Zahl bestimmt die Folgekosten stärker als jeder Angebotspreis.
4. Fünf-Jahres-Summe für den Standardweg bilden. Lizenz, Wartung, Modernisierung, interne Administration — daraus ergibt sich die Schwelle für die Alternative.
5. Erst danach Angebote einholen. Wer die Schwelle kennt, kann Angebote prüfen; wer sie nicht kennt, vergleicht Anschaffungspreise und übersieht vier Fünftel der Kosten.

Häufige Fragen

Was unterscheidet Individualsoftware von Standardsoftware?

Standardsoftware ist ein fertiges Produkt, das viele Kunden in derselben Form nutzen; Entwicklung und Wartung verteilen sich auf alle Lizenznehmer. Individualsoftware wird für einen Auftraggeber gebaut und passt sich dessen Abläufen an. Der wirtschaftliche Unterschied liegt weniger im Kaufpreis als in der Frage, wer die laufende Pflege trägt.

Ist Individualsoftware teurer als Standardsoftware?

In der Anschaffung meistens ja, über den Lebenszyklus nicht zwangsläufig. Nach Zarnekow, Scheeg und Brenner (2004) entfallen bei fünf Jahren Produktionsdauer 79 Prozent der Kosten auf Betrieb und Weiterentwicklung. Standardsoftware verursacht diese Folgekosten ebenfalls — als Wartungsvertrag, Release-Wechsel und Administration. Entscheidend ist die Gesamtsumme über die Nutzungsdauer.

Woran erkennt man, dass Standardsoftware nicht mehr reicht?

An vier Anzeichen: Neben dem System entsteht eine Tabellenkalkulation, die niemand offiziell pflegt. Dieselbe Zahl wird an drei Stellen gehalten. Der Ablauf enthält Umwege, die nur existieren, weil das Produkt sie erzwingt. Und die Lizenzkosten wachsen schneller als der Nutzen. Zwei dieser Anzeichen genügen für eine Prüfung.

Ist quelloffene Software eine Alternative zu Individualsoftware?

Für einen Teil der Fälle ja: Sie liefert den austauschbaren Anteil fertig und erlaubt zugleich Anpassungen am Quellcode. Nach dem Bitkom Open Source Monitor 2025 nutzen 73 Prozent der Unternehmen ab 20 Beschäftigten in Deutschland Open-Source-Software. Wer eine dauerhaft abweichende Kopie pflegt, trägt allerdings dieselbe Weiterentwicklungslast wie bei einer Eigenentwicklung.

Wem gehören Quellcode und Daten bei Individualsoftware?

Das regelt der Vertrag, nicht die Technik. Zu prüfen sind drei Punkte: ob die Nutzungsrechte am Quellcode übertragen oder nur eingeräumt werden, ab wann das gilt — mit Abnahme oder vom ersten Monat an — und ob Build-Umgebung, Zugangsdaten und Infrastrukturkonten mitübergehen. Ohne den dritten Punkt nützt das Eigentum am Code wenig.