Standardsoftware vs. Individualsoftware: Entscheidungsmatrix und TCO-Logik

Standardsoftware vs. Individualsoftware ist keine Grundsatzfrage für das ganze Unternehmen, sondern eine Entscheidung pro Prozess. Für die Mehrzahl der Prozesse in einem Industriebetrieb gewinnt Standardsoftware; für die wenigen, die den Betrieb vom Wettbewerb unterscheiden, ist Individualsoftware häufig die sachlich bessere Wahl. Dieser Beitrag liefert die Matrix dafür – mit TCO-Logik über fünf Jahre, Rechtefragen und steuerlicher Behandlung.

Standardsoftware vs. Individualsoftware: Was die Begriffe wirklich unterscheidet

Der Unterschied zwischen Standardsoftware und Individualsoftware liegt nicht in der Qualität, sondern darin, wer den Prozess vorgibt: bei Standardsoftware der Hersteller für viele Kunden, bei Individualsoftware der Auftraggeber für genau einen Betrieb. Alles Weitere – Kostenstruktur, Rechte, Betrieb, Abhängigkeiten – folgt aus dieser einen Vorgabe.

Standardsoftware

Ein Produkt, das ein Hersteller für einen Markt entwickelt, pflegt und lizenziert. Der Kunde übernimmt den im Produkt abgebildeten Prozess und passt sich über Konfiguration an. Beispiele: ERP, Finanzbuchhaltung, CAD, Office.

Individualsoftware

Software, die für die Anforderungen genau eines Auftraggebers entwickelt wird – durch eigene Mitarbeiter oder einen beauftragten Entwickler. Der Prozess bestimmt die Software, nicht umgekehrt. Beispiele: Rüstplanung für einen bestimmten Maschinenpark, Prüfprotokolle nach einer bestimmten Kundenvorgabe.

Customizing / Parametrierung

Anpassung von Standardsoftware über vorgesehene Einstellungen, Felder und Workflows. Bleibt innerhalb der Produktlogik und überlebt in der Regel Release-Wechsel.

Add-on / Erweiterung

Zusätzlicher Code an den Erweiterungspunkten eines Standardprodukts. Erweitert die Produktlogik und muss nach jedem Hersteller-Release geprüft werden.

Hybridarchitektur

Standardsoftware als führendes System für Stammdaten und Buchungen, eine individuelle Fachanwendung für den differenzierenden Prozess, eine definierte Schnittstelle dazwischen.

In der Praxis ist die reine Entweder-oder-Frage selten. Ein Standard-ERP mit fünf Jahren Customizing-Historie und drei Add-ons ist faktisch ein Individualsystem mit Lizenzkosten – nur ohne die Rechte und die Dokumentation einer Eigenentwicklung. Die Frage lautet deshalb nie „Standardsoftware oder Individualsoftware für das Unternehmen?“, sondern „Welcher Prozess gehört in welche Kategorie?“.

Wann Standardsoftware klar gewinnt

Standardsoftware gewinnt immer dann, wenn der Prozess nicht Ihnen gehört, sondern dem Gesetzgeber, einer Norm oder dem Markt. Dort ist Individualität kein Vorteil, sondern ein Risiko: Jede Gesetzesänderung und jedes neue Datenformat müssten Sie selbst nachziehen, während ein Hersteller dieselbe Änderung einmal für alle Kunden pflegt.

Die E-Rechnungspflicht ist ein aktuelles Beispiel. Für inländische B2B-Umsätze schreibt § 14 UStG die elektronische Rechnung in einem strukturierten Format vor, das der europäischen Norm für die elektronische Rechnungsstellung gemäß Richtlinie 2014/55/EU (EN 16931) entspricht. Die Übergangsregelung in § 27 Abs. 38 UStG erlaubt Papier oder andere elektronische Formate nur noch für Umsätze bis zum 31. Dezember 2026; Unternehmen mit einem Vorjahresumsatz bis 800.000 Euro haben bis zum 31. Dezember 2027 Zeit. Ein Format wie dieses pflegt ein Hersteller für zehntausende Kunden – wer es selbst implementiert, trägt jede Änderung allein.

Wann Individualsoftware die sachlich bessere Wahl ist

Individualsoftware ist in genau vier Konstellationen die sachlich bessere Wahl – und jede davon lässt sich mit einer Prüffrage feststellen, bevor ein Angebot eingeholt wird. Trifft keine der vier zu, ist die Diskussion beendet.

Die Vorteile und Nachteile von Individualsoftware gehören dabei nüchtern auf einen Zettel: Passgenauigkeit, Rechte am Code, keine Lizenz je Nutzer und Änderungen im eigenen Takt auf der einen Seite – Vorlaufzeit, Abhängigkeit vom Entwickler und selbst organisierter Betrieb auf der anderen. Zwölf typische Prozesse, bei denen die Rechnung aufgeht, stehen in Individualsoftware: 12 typische Anwendungsfälle in Fertigung und Instandhaltung.

Die Entscheidungsmatrix: acht Kriterien mit Gewichtung

Die Entscheidungsmatrix übersetzt die vier Konstellationen in ein Punkteraster, das Fachbereich, IT und Einkauf unabhängig voneinander ausfüllen. Jedes Kriterium bekommt 1, 2 oder 3 Punkte und ein festes Gewicht: 1 spricht für Standardsoftware, 3 für Individualsoftware. Die Gewichte summieren sich auf 20, das Ergebnis liegt zwischen 20 und 60 Punkten.

Auswertungsregel: Punkte mal Gewicht, alles addieren. Bis 32 Punkte ist Standardsoftware gesetzt. Zwischen 33 und 44 Punkten lohnt die Prüfung einer Hybridarchitektur. Ab 45 Punkten holen Sie ein Individualangebot ein – parallel zu einem Angebot für die Anpassung des besten Standardprodukts. Die Schwellen sind Erfahrungswerte, keine Norm; legen Sie sie vor der Bewertung fest. Wo die drei Bewertungen um zwei Punkte auseinanderliegen, ist die Anforderung unklar und gehört ins Lastenheft.

Rechenbeispiel mit fiktiven Werten: Ein Zulieferer bewertet die Werkzeug- und Rüstverwaltung an vierzehn Pressen. Prozessindividualität 3 (12 Punkte), Änderungsfrequenz 2 (4), Zahl der Nutzer 1 (2), Integrationstiefe 3 (9), Datenhoheit 2 (4), Auditpflichten 2 (4), Budget 2 (4), Betriebskompetenz 2 (6). Summe: 45 Punkte, also knapp im Individualbereich – ein Fall, in dem Hybrid- und Individualangebot verglichen werden sollten. Derselbe Betrieb bewertet seine Zeiterfassung: 1, 1, 2, 1, 1, 2, 2, 1 ergibt 26 Punkte. Standard, ohne weitere Diskussion.

Das Kriterium Betriebskompetenz wird regelmäßig unterschätzt. Individualsoftware braucht jemanden, der Anforderungen formuliert, Releases testet und den Betrieb verantwortet – und diese Person ist schwer zu finden: Laut Bitkom Research fehlten in der deutschen Wirtschaft im Erhebungszeitraum KW 18 bis 25 des Jahres 2026 rund 79.000 IT-Fachkräfte, am häufigsten gesucht wurden mit 26 % Fachkräfte für IT-Administration und Systembetrieb.

Total Cost of Ownership über fünf Jahre: die Rechnung, die selten gemacht wird

Die meisten Vergleiche enden bei Lizenzpreis gegen Entwicklungsangebot. Die Rechnung, die zählt, läuft über 60 Monate und hat sieben Kostenblöcke – bei beiden Wegen. Wer sie nicht vollständig aufstellt, vergleicht den Sockel der einen Variante mit der Kurve der anderen.

Zwei Blöcke fehlen fast immer: die Release-Nacharbeit bei Standardsoftware, deren Takt der Hersteller bestimmt, und die Ausstiegskosten bei beiden Varianten. Die Grundlogik der Kurven ist kurz: Bei Standardsoftware wachsen die Kosten mit Nutzerzahl und Laufzeit, bei Individualsoftware steht ein hoher Sockel am Anfang und danach eine flache Kurve. Wo sich beide kreuzen, hängt von Nutzerzahl, Integrationstiefe und Laufzeit ab. Stundensätze, Projektgrößen und die versteckten Kostentreiber mit Marktdaten stehen in Was kostet Individualsoftware in der Industrie?; dieser Beitrag beschränkt sich auf die Rechenlogik.

Wem gehört die Software? Rechte, Quellcode und Lock-in

Wer Individualsoftware bezahlt, besitzt sie nicht automatisch. Nach § 69c UrhG hat der Rechtsinhaber das ausschließliche Recht, ein Computerprogramm zu vervielfältigen, zu übersetzen, zu bearbeiten und zu verbreiten. Wer dieser Rechtsinhaber ist und welche Rechte Sie erhalten, regelt der Vertrag – nicht die bezahlte Rechnung. Ohne ausdrückliche Klausel kann es sein, dass Sie nur ein nicht ausschließliches Nutzungsrecht haben und den Code weder ändern noch an einen anderen Dienstleister geben dürfen.

Beide Wege erzeugen Abhängigkeit, nur von unterschiedlichen Parteien. Bei Standardsoftware gehört der Lebenszyklus dem Hersteller: SAP hat im Februar 2020 angekündigt, die Mainstream-Wartung für die Kernanwendungen der SAP Business Suite 7 bis Ende 2027 zu leisten; eine optionale erweiterte Wartung bis Ende 2030 kostet einen Aufschlag von zwei Prozentpunkten auf die bestehende Wartungsbasis. Das ist keine Kritik an SAP, sondern die Mechanik jedes Standardprodukts. Bei Individualsoftware liegt die Abhängigkeit beim Entwickler – bei seinem Wissen, seiner Dokumentation und seiner Verfügbarkeit in fünf Jahren.

Kaufmännische Einordnung: Aktivierung, Abschreibung, Nutzungsdauer

Steuerlich zählt, ob Software selbst erstellt oder erworben wurde. § 5 Abs. 2 EStG bestimmt: „Für immaterielle Wirtschaftsgüter des Anlagevermögens ist ein Aktivposten nur anzusetzen, wenn sie entgeltlich erworben wurden.“ Software, die eigene Mitarbeiter entwickeln, wird in der Steuerbilanz also nicht aktiviert; die Entwicklungskosten sind Aufwand der Periode. In der Handelsbilanz besteht dagegen ein Wahlrecht: Nach § 248 Abs. 2 HGB können selbst geschaffene immaterielle Vermögensgegenstände des Anlagevermögens als Aktivposten aufgenommen werden.

Für erworbene Software gilt das BMF-Schreiben vom 22. Februar 2022 (GZ IV C 3 - S 2190/21/10002 :025), das das Schreiben vom 26. Februar 2021 ersetzt. Danach kann für Betriebs- und Anwendersoftware zur Dateneingabe und -verarbeitung eine betriebsgewöhnliche Nutzungsdauer von einem Jahr zugrunde gelegt werden. Randziffer 5 zählt ausdrücklich auch „auf den individuellen Nutzer abgestimmte Anwendungen wie ERP-Software, Software für Warenwirtschaftssysteme oder sonstige Anwendungssoftware zur Unternehmensverwaltung oder Prozesssteuerung“ dazu. Das Schreiben stellt klar, dass die kürzere Nutzungsdauer keine besondere Form der Abschreibung, keine neue Abschreibungsmethode und keine Sofortabschreibung ist und kein Wahlrecht im Sinne des § 5 Abs. 1 EStG darstellt, dass der Steuerpflichtige von der Annahme abweichen kann und dass die volle Abschreibung im Jahr der Anschaffung nicht beanstandet wird.

Der dritte Weg: Standard als Basis, Individual an den Rändern

Der häufigste Ausgang einer sauberen Bewertung ist weder Standard noch Individual, sondern beides mit klarer Grenze: Das ERP bleibt System of Record für Stammdaten, Aufträge und Buchungen, eine individuelle Fachanwendung übernimmt den einen differenzierenden Prozess, dazwischen liegt eine definierte Schnittstelle.

• —Im Standard bleibt alles, was gebucht, fakturiert, gemeldet oder von Prüfern erwartet wird.
• —Nach außen geht alles, was den Takt der Fertigung hat, Maschinendaten braucht oder je Kunde anders aussieht.
• —Jede Information hat genau ein führendes System; die Fachanwendung liest Stammdaten, schreibt aber keine zurück, die das ERP selbst pflegt.
• —Die Schnittstelle bekommt einen Verantwortlichen, eine Versionsnummer und einen Testfall je Datenfluss – und der Integrationsaufwand einen eigenen Block im TCO.

Die Grenze verläuft fast immer dort, wo das ERP über Excel-Listen und Nebenrechnungen ergänzt wird. Genau dort sitzt der individuelle Prozess. Wie man ihn in der Fertigung angeht, ohne das ERP anzufassen, beschreibt Prozessautomatisierung in der Fertigung: der kleinste sinnvolle erste Schritt.

In fünf Schritten zur Entscheidung

1. 01

   Prozess isolieren

   Beschreiben Sie den einen Prozess mit Auslöser, Beteiligten, Systemen, Datenobjekten und Ergebnis auf einer Seite. Was nicht darauf passt, sind zwei Prozesse.

2. 02

   Marktscreening mit Ausschlusskriterien

   Definieren Sie drei bis fünf K.-o.-Kriterien – On-Premise-Fähigkeit, SPS-Anbindung, Datenexport – und streichen Sie alles, was daran scheitert, vor der ersten Demo.

3. 03

   Zwei bis drei Standardprodukte konkret prüfen

   Testen Sie mit eigenen Daten und Ihren zehn häufigsten Fällen, nicht mit dem Demo-Datensatz des Anbieters. Notieren Sie jede Lücke und ob sie per Konfiguration, Add-on oder gar nicht schließbar ist.

4. 04

   Anpassungsaufwand beziffern lassen

   Holen Sie für die Lücken ein schriftliches Angebot für Customizing und Add-ons ein – inklusive Release-Pflege über fünf Jahre. Erst diese Zahl macht Konstellation 4 aus Tabelle 02 prüfbar.

5. 05

   Erst jetzt ein Individualangebot einholen

   Auf Basis eines Lastenhefts, das aus den Schritten 1 bis 4 entsteht. Aufbau und Kapitel stehen in Lastenheft für Industriesoftware: Aufbau, Kapitel und Vorlage.

Fazit

Standardsoftware vs. Individualsoftware wird pro Prozess entschieden, und in den meisten Prozessen gewinnt der Standard – weil Gesetzgeber, Norm oder Markt den Ablauf vorgeben. Individualsoftware gehört an die wenigen Stellen, die einen Betrieb unterscheiden, die kein Produkt abdeckt, deren Daten im Haus bleiben müssen oder deren Anpassung am Standard teurer wäre als der Neubau. Matrix, TCO-Formel und Vertragsliste machen diese Grenze sichtbar, bevor ein Anbieter sie für Sie zieht.

Der nächste Schritt ist kein Angebot, sondern eine ausgefüllte Matrix für den einen Prozess, der Ihnen am meisten Aufwand macht. Liegt das Ergebnis im Individual- oder Hybridbereich, ist eine Einschätzung von Architektur und Schnittstellen vor dem Lastenheft sinnvoll – etwa im Rahmen der individuellen Softwareentwicklung von ralwo.