Standardsoftware

Standardsoftware ist vorgefertigte Software, die für einen breiten Markt entwickelt und in vielen Unternehmen mit demselben Funktionsumfang eingesetzt wird. Sie ist das Gegenstück zur Individualsoftware, die für genau einen Auftraggeber und dessen Prozesse entsteht. Der Hersteller definiert, was die Software kann; der Kunde konfiguriert innerhalb dieser Grenzen.

Das klingt nach einer Einschränkung, ist aber zunächst eine Stärke. Weil sich die Entwicklungskosten auf Tausende oder Millionen Kunden verteilen, bekommt ein einzelnes Unternehmen für vergleichsweise wenig Geld eine Software, in der Jahrzehnte an Produktentwicklung, Fehlerbehebung und regulatorischem Wissen stecken. Kein Mittelständler könnte eine Finanzbuchhaltung mit der Reife von DATEV oder ein ERP mit dem Funktionsumfang von SAP selbst entwickeln, ohne ein Vielfaches zu bezahlen. Die eigentliche Frage ist deshalb nie, ob Standardsoftware gut ist, sondern für welche Prozesse sie die richtige Wahl ist und wo ihre Grenzen anfangen, teuer zu werden.

Was Standardsoftware auszeichnet

Drei Merkmale definieren Standardsoftware im Kern. Erstens: Sie wird für den Markt entwickelt, nicht für einen Kunden. Der Hersteller analysiert, welche Anforderungen viele Unternehmen teilen, und gießt den gemeinsamen Nenner in ein Produkt. Zweitens: Der Kunde erwirbt ein Nutzungsrecht, keinen Quellcode. Ob als klassische Kauflizenz oder als Abonnement im SaaS-Modell, die Software bleibt geistiges Eigentum des Herstellers, und der bestimmt die Roadmap. Drittens: Wartung, Updates und Weiterentwicklung liegen beim Hersteller. Sicherheits-Patches, Gesetzesänderungen, neue Features kommen zentral für alle Kunden. Genau dieser Punkt ist im Alltag der größte Vorteil und zugleich die größte Abhängigkeit.

Wie sich Standardsoftware von Individualsoftware unterscheidet, zeigt sich am deutlichsten an der Frage, wer sich an wen anpasst. Bei Standardsoftware passt das Unternehmen seine Prozesse an die Software an, zumindest überall dort, wo die Konfiguration nicht reicht. Bei Individualsoftware ist es umgekehrt: Die Software bildet den Prozess ab, so wie er im Unternehmen tatsächlich gelebt wird. Beides hat seinen Preis. Wer sich der Standardsoftware anpasst, gibt Eigenheiten auf, die manchmal wertlos und manchmal der eigentliche Wettbewerbsvorteil sind. Wer individuell baut, bezahlt die Freiheit mit Entwicklungs- und Wartungskosten.

Arten von Standardsoftware

Der Begriff deckt ein breites Spektrum ab, das sich grob in vier Kategorien sortieren lässt:

• Systemnahe Software und Office-Anwendungen: Betriebssysteme, Textverarbeitung, Tabellenkalkulation, E-Mail. Microsoft 365 ist hier der De-facto-Standard im deutschen Mittelstand. Individualisierungsbedarf: praktisch null.
• Betriebswirtschaftliche Anwendungen: ERP-Systeme wie SAP S/4HANA, CRM-Systeme wie Salesforce oder HubSpot, Buchhaltungs- und Lohnsoftware wie DATEV oder Lexware. Hier ist Konfiguration der Normalfall und die Grenze zum Customizing fließend.
• Branchensoftware: Standardprodukte für eine bestimmte Branche, etwa Praxisverwaltung im Gesundheitswesen, Kanzleisoftware oder Handwerkersoftware. Der Markt ist kleiner, die Passung dafür oft höher.
• Plattform-Software mit Erweiterungsmodell: Systeme wie Shopware oder TYPO3, die als Standardprodukt ausgeliefert werden, aber ausdrücklich dafür gebaut sind, per Plugin oder Extension an individuelle Anforderungen angepasst zu werden. Diese Kategorie verwischt die klassische Grenze zwischen Standard und Individual am stärksten.

Konfiguration, Customizing, Erweiterung: die Anpassungsleiter

In der Praxis ist kaum eine betriebswirtschaftliche Standardsoftware wirklich „von der Stange" im Einsatz. Fast immer wird angepasst, und die Art der Anpassung entscheidet über Kosten und Risiken. Es lohnt sich, die Stufen sauber zu trennen.

Konfiguration nutzt die vom Hersteller vorgesehenen Einstellmöglichkeiten: Felder aktivieren, Workflows auswählen, Rollen und Rechte definieren. Konfiguration ist updatesicher und im Lizenzpreis eingepreist. Customizing geht weiter und passt die Software mit herstellereigenen Mitteln an, etwa eigenen Feldern, Formularen oder Skripten innerhalb der Plattform. Erweiterung baut zusätzliche Funktionalität über offizielle Schnittstellen an, als Plugin, App oder externes System, das per API angebunden wird. Modifikation schließlich verändert den Kern der Software selbst. Das ist die Stufe, vor der praktisch jeder Hersteller warnt, denn ein modifizierter Kern macht jedes Update zum Projekt.

Die Faustregel lautet: so weit unten auf der Leiter bleiben wie möglich. Jede Stufe nach oben erhöht die Update-Kosten, verlängert Release-Zyklen und bindet das Unternehmen enger an den Dienstleister, der die Anpassung gebaut hat. Wer merkt, dass er dauerhaft auf den oberen Stufen unterwegs ist, hat oft in Wahrheit einen Individualsoftware-Bedarf, den er in ein Standardprodukt hineinzwingt.

Vor- und Nachteile im Überblick

Die Tabelle zeigt das Muster: Standardsoftware gewinnt fast immer bei Prozessen, die viele Unternehmen identisch haben, und verliert dort, wo ein Prozess das Geschäft differenziert. Das ist keine Schwäche des Produkts, sondern seine Konstruktionslogik. Ein Produkt für den Massenmarkt kann per Definition nicht das abbilden, was ein einzelnes Unternehmen einzigartig macht.

Realbeispiel: SAP S/4HANA und „Keep the Core Clean"

Wie ernst das Thema Anpassungsleiter ist, zeigt der größte Anbieter betriebswirtschaftlicher Standardsoftware selbst. SAP hat für S/4HANA das Prinzip „Keep the Core Clean" zur offiziellen Strategie erhoben: Kunden sollen den Kern des ERP-Systems unangetastet lassen und Erweiterungen ausschließlich über definierte Schnittstellen und die SAP Business Technology Platform bauen. Der Hintergrund ist jahrzehntelange Erfahrung mit dem Gegenteil. Viele SAP-Bestandskunden haben ihre R/3- und ECC-Systeme über die Jahre so stark modifiziert, dass Upgrades zu mehrjährigen Großprojekten wurden und die Migration auf S/4HANA heute zu den teuersten IT-Vorhaben ihrer Firmengeschichte zählt.

Die Lehre daraus gilt weit über SAP hinaus: Der Wert von Standardsoftware hängt daran, dass man im Standard bleibt. Wer massiv modifiziert, kombiniert die Nachteile beider Welten, nämlich die laufenden Kosten und die Abhängigkeit der Standardsoftware mit den Wartungslasten der Individualentwicklung, ohne deren Vorteil zu bekommen: Code, der einem gehört und exakt den eigenen Prozess abbildet.

Kosten: warum „günstiger" nicht automatisch stimmt

Standardsoftware gilt als die günstige Option, und beim Einstiegspreis stimmt das fast immer. Über die Laufzeit gerechnet wird das Bild differenzierter. In eine ehrliche Total-Cost-of-Ownership-Rechnung gehören neben Lizenzen oder Abo-Gebühren auch die Kosten der Einführung, der Schulung, der Prozessumstellung, der Schnittstellen zu Bestandssystemen und des Customizings, dazu die Preissteigerungen, die ein Hersteller mit marktbeherrschender Stellung durchsetzen kann.

Besonders bei SaaS-Produkten kippt die Rechnung gern schleichend: Der Einstieg kostet wenig, aber jeder zusätzliche Nutzer, jedes Zusatzmodul und jeder Enterprise-Tier für ein einzelnes benötigtes Feature erhöht die Jahresrechnung. Unternehmen, die für ihren Kernprozess über Jahre Workarounds, Zusatzmodule und externe Tools um eine Standardsoftware herum bauen, zahlen am Ende oft mehr als eine fokussierte Eigenentwicklung gekostet hätte. Der Vergleich muss deshalb immer über denselben Zeitraum laufen, üblicherweise fünf Jahre, und beide Kostenkurven vollständig enthalten.

Standardsoftware oder Individualsoftware: die Entscheidungslogik

Die Entscheidung ist ein Klassiker der Make-or-Buy-Entscheidung, und die tragfähigste Heuristik ist die Differenzierungsfrage: Hebt der Prozess das Unternehmen vom Wettbewerb ab, oder muss er einfach zuverlässig laufen? Hygiene-Prozesse wie Buchhaltung, Lohnabrechnung, E-Mail oder Dokumentenablage kauft man als Standard, ohne lange nachzudenken. Differenzierende Prozesse, etwa eine besondere Preislogik, ein Produktkonfigurator oder die spezifische Verzahnung von Produktion und Versand, sind Kandidaten für Individualsoftware, weil ein Standardprodukt, das jeder kaufen kann, per Definition kein Wettbewerbsvorteil ist.

Dazwischen liegt die Grauzone, in der die meisten realen Entscheidungen fallen. Das pragmatische Muster für diese Fälle: das Standardprodukt für den Standardanteil behalten und den differenzierenden Teil als eigenes Modul daneben bauen, verbunden über eine saubere Schnittstelle. So bleibt das ERP wartbar und updatefähig, während die eigene Logik in Code lebt, der dem Unternehmen gehört. Voraussetzung ist, dass die Standardsoftware brauchbare APIs mitbringt, was bei der Auswahl deshalb ein hartes Kriterium sein sollte, nicht ein nachrangiges.

Häufige Missverständnisse

Drei Fehleinschätzungen tauchen in Auswahlprojekten immer wieder auf. Die erste: „Standardsoftware ist risikolos." Einführungsprojekte für ERP- oder CRM-Standardsoftware scheitern regelmäßig an denselben Punkten wie Individualprojekte, nämlich an unklaren Anforderungen, fehlender Prozessklarheit und überzogenem Scope. Ein Lastenheft braucht die Auswahl von Standardsoftware genauso wie eine Eigenentwicklung. Die zweite: „Wir passen die Software später schon an." Wer schon in der Auswahlphase weiß, dass er massiv anpassen muss, vergleicht in Wahrheit nicht Standard gegen Standard, sondern zwei verdeckte Individualprojekte, und sollte die Kosten auch so kalkulieren. Die dritte: „Cloud heißt Standard." SaaS ist ein Betriebs- und Lizenzmodell, keine Aussage über den Anpassungsgrad. Es gibt hochkonfigurierbare SaaS-Plattformen und starre On-Premises-Produkte.

Ausblick

Zwei Entwicklungen verschieben die Grenze zwischen Standard und Individual gerade spürbar. Erstens werden Standardprodukte immer stärker als Plattformen mit offiziellen Erweiterungsökosystemen gebaut, wodurch der Hybrid aus Standardkern plus individueller Erweiterung zum Normalfall wird statt zur Ausnahme. Zweitens senken KI-gestützte Entwicklungswerkzeuge die Kosten von Individualentwicklung, was die Break-even-Rechnung langsam zugunsten des Eigenbaus verschiebt, zumindest für klar umrissene Module. An der Grundlogik ändert beides nichts: Standard für das, was alle brauchen, Individual für das, was einen unterscheidet. Eine ausführliche Definition des Gegenbegriffs liefert der Glossar-Eintrag zur Individualsoftware; die begriffliche Einordnung findet sich auch bei Wikipedia unter Standardsoftware.

FAQ zur Standardsoftware

Was ist der Unterschied zwischen Standardsoftware und Individualsoftware?

Standardsoftware wird für den breiten Markt entwickelt und von vielen Unternehmen identisch genutzt; der Kunde erwirbt ein Nutzungsrecht und passt seine Prozesse an die Software an. Individualsoftware entsteht für einen einzelnen Auftraggeber, bildet dessen Prozesse exakt ab, und der Code gehört dem Auftraggeber.

Welche Beispiele für Standardsoftware gibt es?

Typische Beispiele sind Microsoft 365 für Office und E-Mail, SAP S/4HANA als ERP-System, Salesforce oder HubSpot im CRM, DATEV für Buchhaltung und Lohn sowie Shopware als E-Commerce-Plattform. Auch Branchenlösungen wie Praxis- oder Kanzleisoftware zählen dazu.

Wann lohnt sich Standardsoftware, wann Individualsoftware?

Standardsoftware lohnt sich für Prozesse, die viele Unternehmen gleich abwickeln, etwa Buchhaltung, Lohn oder E-Mail. Individualsoftware lohnt sich für Prozesse, die das Geschäft vom Wettbewerb unterscheiden. In der Grauzone dazwischen ist die Kombination oft am wirtschaftlichsten: Standardkern behalten, differenzierende Logik als eigenes Modul per Schnittstelle anbinden.

Ist Standardsoftware immer günstiger?

Beim Einstieg fast immer, über die Laufzeit nicht zwingend. Lizenz- oder Abo-Kosten, Customizing, Schnittstellen, Schulung und Prozessumstellung summieren sich, und SaaS-Kosten skalieren mit Nutzern und Modulen. Ein seriöser Vergleich rechnet die Gesamtkosten beider Optionen über denselben Zeitraum, üblicherweise fünf Jahre.

Was bedeutet Customizing bei Standardsoftware?

Customizing bezeichnet Anpassungen einer Standardsoftware mit den Mitteln des Herstellers, etwa eigene Felder, Formulare oder Workflows, die über die reine Konfiguration hinausgehen. Je tiefer die Anpassung geht, desto teurer werden Updates. Modifikationen am Software-Kern gelten als Anti-Pattern und sollten vermieden werden.