Individualsoftware vs. Standardsoftware: Wann lohnt sich Maßanfertigung?

Wann Standardsoftware klar gewinnt

Es gibt eine Klasse von Prozessen, bei denen Eigenentwicklung fast immer die falsche Antwort ist: Prozesse, die gesetzlich vorgegeben sind, sich regelmäßig per Gesetz ändern und in jedem Unternehmen gleich ablaufen. Hier kaufen Sie nicht in erster Linie Funktionen, sondern die laufende Pflege durch den Hersteller. Wer eine Lohnabrechnung selbst baut, übernimmt die Verantwortung dafür, jede Änderung an Beitragssätzen und Meldeverfahren rechtzeitig nachzuziehen – jedes Jahr, unbefristet.

Das zweite Muster: austauschbare Prozesse mit reifem Anbietermarkt. Ticketing, Zeiterfassung, Dateiablage oder E-Mail sind Infrastruktur. Ein eigenes Ticketsystem bringt keinem Unternehmen einen Vorteil, kostet aber dauerhaft Wartung. Dasselbe gilt für das Kerngeschäft einer Warenwirtschaft: Buchungslogik, Lagerbewegungen und Belegkreisläufe sind in Systemen wie Microtech Büro+ oder SAP in Jahrzehnten gereift.

Wann Individualsoftware gewinnt

Spiegelbildlich gibt es Situationen, in denen jede Standardlösung nur eine Näherung bleibt. Die klarste davon: Der Prozess ist das Produkt. Der Gitterrost-Konfigurator, den wir für FeNau gebaut haben, führt in neun Schritten von Traglast und Maschenweite über Material und Maße bis zu Aus- und Abschnitten, rechnet nach einem DIN-Regelwerk, zeichnet eine maßstäbliche Plandarstellung und gibt ein PDF-Datenblatt samt Sofort-Festpreis aus. Kein Shop-Plugin leistet das, weil die Fachlogik das Geschäft ist.

Der zweithäufigste Fall ist das fehlende Bindeglied. Zwei Standardsysteme funktionieren einzeln, aber zwischen ihnen steht Handarbeit. Der Connector zwischen Shopware 6 und dem OBI-Marktplatz auf Mirakl-Basis ist genau das: Shopware bleibt führendes System und Standardprodukt, der Connector übernimmt Mapping, Warteschlangen, Wiederholungen und den Rückfluss von Bestellungen und Retouren. Gebaut wurde nicht das Shopsystem, sondern die Lücke dazwischen.

Dazu kommen drei wirtschaftliche Auslöser, die sich rechnen lassen. Erstens: Lizenzkosten steigen mit der Nutzerzahl, der Nutzen pro Nutzer aber nicht – klassisch bei Gelegenheitsnutzern in Lager, Montage oder Außendienst, die eine Vollizenz für drei Klicks am Tag brauchen. Zweitens: Mehrere Systeme sind nur über Excel verbunden. Drittens: Daten dürfen aus regulatorischen oder vertraglichen Gründen nicht beim Anbieter liegen.

Der dritte Weg: Standard im Kern, Eigenes an der Kante

In der Praxis ist die Frage „kaufen oder bauen“ meist falsch gestellt, weil sie eine Entweder-oder-Entscheidung über ein ganzes System erzwingt. Die wirtschaftlich beste Antwort lautet fast immer: beides, aber sauber getrennt. Der Kern bleibt Standard – dort, wo Reife, gesetzliche Pflege und Anbietermarkt zählen. Individuell wird die Kante: die Schnittstelle, der Konfigurator, das Portal, die Auswertung.

Dieser Zuschnitt hat einen handfesten Vorteil: Er begrenzt den Schaden, wenn eine Annahme falsch war. Eine Schnittstelle für 5.000 bis 15.000 € lässt sich neu bauen, ein selbst entwickeltes ERP nicht. Außerdem bleibt die gesetzliche Pflege beim Hersteller des Kernsystems, während Sie nur den Teil besitzen, der tatsächlich Ihnen gehören sollte.

Die Abgrenzung muss allerdings vor dem ersten Entwurf stehen, nicht während der Umsetzung. Wir legen dazu je Datenart ein führendes System fest und beschreiben gerichtete Datenflüsse. Wer diese Entscheidung offenlässt, baut zwei Wahrheiten – und keine davon ist später nachweisbar richtig.

Zehn Kriterien im direkten Vergleich

Die folgende Tabelle vergleicht die drei Wege entlang der Kriterien, die in Entscheidungsvorlagen regelmäßig fehlen. Auffällig ist, dass keine Spalte durchgehend gewinnt: Standardsoftware führt bei Einstiegskosten, Einführungszeit und Updateaufwand, Individualsoftware bei Passgenauigkeit, Datenhoheit und Skalierung nach Nutzerzahl. Genau deshalb entscheidet die Gewichtung, nicht die Zeilenzahl.

Die Kostenrechnung, die kaum jemand aufstellt

Angebote werden fast immer über die Anschaffung verglichen: 15.000 € Einführung gegen 45.000 € Entwicklung, und die Entscheidung scheint gefallen. Diese Rechnung ist unvollständig, weil sie zwei unterschiedlich lange Zeiträume vergleicht. Sinnvoll ist ein Betrachtungszeitraum von fünf Jahren – das entspricht ungefähr der Lebensdauer einer Fachanwendung, bevor größere Umbauten anstehen.

Die folgende Rechnung ist ausdrücklich eine Modellrechnung mit frei gewählten Annahmen und kein Angebot. Sie enthält keine Preise realer Hersteller; der Lizenzsatz ist ein angenommener Mittelwert. Ziel ist nicht, ein Ergebnis zu belegen, sondern die Struktur der Rechnung sichtbar zu machen, damit Sie sie mit Ihren eigenen Zahlen wiederholen können.

Was dieselbe Rechnung bei acht Nutzern ergibt

Der Umschlagpunkt in der Modellrechnung liegt bei rund 34 Monaten nach Projektstart, also im dritten Jahr. Wer davon ausgeht, das System länger als drei Jahre zu nutzen, kommt mit der Eigenentwicklung günstiger weg – unter den genannten Annahmen und nur dann, wenn tatsächlich 25 Nutzer Lizenzen brauchen.

Ändern Sie eine einzige Annahme, kippt das Ergebnis. Bei 8 statt 25 Nutzern und entsprechend kleinerer Einführung von 8.000 € summiert sich die Standardlösung über fünf Jahre auf rund 39.800 €, die Eigenentwicklung bleibt bei 87.000 €. Der Abstand beträgt dann rund 47.000 € zugunsten des Standards, und er wird auch im zehnten Jahr nicht aufgeholt, weil die Wartung von 8.400 € jährlich über den Lizenzkosten liegt.

Daraus folgt eine unbequeme, aber nützliche Faustregel: Die Nutzerzahl ist in dieser Entscheidung oft wichtiger als die Funktionsliste. Rechnen Sie die Tabelle mit Ihren realen Lizenzpreisen, Ihrer realen Kopfzahl und einer ehrlichen Annahme zur Preissteigerung nach, bevor Sie ein Discovery beauftragen. Wenn das Ergebnis eindeutig für Standard spricht, ist die Entscheidung gefallen – und Sie haben nichts ausgegeben.

Die versteckten Kosten von Standardsoftware

Die Lizenzrechnung ist der sichtbare Teil. Teurer sind oft die Kosten, die nie in einer Kostenstelle auftauchen, weil sie in Arbeitszeit bezahlt werden. Wenn drei Mitarbeitende täglich 45 Minuten damit verbringen, Daten zwischen zwei Systemen zu übertragen, ist das ein voller Personentag pro Woche – der in keinem Softwarebudget steht.

Das zweite Muster sind Schattenprozesse. Wo das Standardprodukt eine Anforderung nicht abbildet, entsteht eine Tabelle daneben. Diese Tabelle wird zum heimlichen Kernsystem: nicht mehrbenutzerfähig, nicht auditierbar, nicht ersetzbar. Formal läuft der Prozess im Standardsystem, faktisch in einer Datei auf einem Laufwerk.

Die versteckten Kosten von Individualsoftware – und wie man sie entschärft

Auch die andere Seite hat Posten, die in Angeboten gern klein wirken. Der wichtigste ist die Wartung: Eine Fachanwendung, die zwei bis drei Jahre ungepflegt bleibt, ist nicht mehr schrittweise aktualisierbar, weil zu viele Versionssprünge gleichzeitig nachzuholen sind. Aus Pflege wird dann eine Migration, und die kostet ein Vielfaches. Wer beim Betrieb spart, verschiebt Kosten, statt sie zu vermeiden.

Der zweite Posten ist Wissensbindung. Bei einem Fertigprodukt gibt es Handbücher, Schulungen und einen Markt an Fachkräften. Bei einer Eigenentwicklung gibt es das nur, wenn es jemand herstellt. Der dritte Posten ist die Abhängigkeit von einem Dienstleister – bei einem Einzelunternehmen als Anbieter eine berechtigte Frage, die wir uns regelmäßig stellen lassen.

Diese Risiken lassen sich vertraglich und technisch weitgehend entschärfen, und zwar vor Projektbeginn und nicht bei der Abnahme. Entscheidend ist, dass Sie am Ende nicht nur eine laufende Anwendung besitzen, sondern alles, was nötig ist, um sie von jemand anderem weiterentwickeln zu lassen: Quellcode, Zugänge, Infrastrukturbeschreibung und eine Dokumentation, die jemand ohne Projektwissen lesen kann. Prüfen Sie diese Punkte im Angebot, bevor Sie über den Preis verhandeln.

Wie Sie das Risiko halbieren, bevor das Budget steht

Die größte Unsicherheit in einem Softwareprojekt liegt nicht in der Programmierung, sondern in der Annahme, dass alle Beteiligten denselben Prozess meinen. Diese Annahme lässt sich früh und günstig prüfen. Wir stellen im Discovery den Ist-Prozess auf, erheben den Schnittstellenkatalog und legen je Datenart ein führendes System fest – das dauert ein bis drei Wochen und ist die Grundlage für einen Festpreis.

Danach kommt der Durchstich vor dem Vollausbau: ein lauffähiger, schmaler Pfad gegen die echte Testumgebung des Fremdsystems, der die riskanteste Annahme beantwortet. Wenn die Fremd-API ein Pflichtfeld verlangt, das in Ihren Daten nicht existiert, wollen Sie das in Woche zwei wissen und nicht in Monat vier.

Der dritte Hebel ist die Auslieferung in Etappen mit sichtbaren Zwischenständen. Jede Etappe hat einen Preis, ein Ergebnis und einen Abbruchpunkt. Das ist die praktische Umsetzung dessen, was in der Theorie gern Risikomanagement heißt: Sie können nach jeder Etappe aufhören und behalten, was bis dahin fertig ist.

Rechtliches, das mitgeplant werden muss

Drei rechtliche Anforderungen wirken direkt auf Architektur und Budget und gehören deshalb in die Planung, nicht in die Abnahme. Die erste ist die Auftragsverarbeitung: Sobald ein Dienstleister personenbezogene Daten in Ihrem Auftrag verarbeitet, ist nach Art. 28 DSGVO ein Auftragsverarbeitungsvertrag erforderlich. Das gilt für die Eigenentwicklung wie für jedes Standardprodukt als Cloud-Dienst und für jeden Hoster in der Kette.

Die zweite ist die Meldefrist: Art. 33 DSGVO verlangt, eine Verletzung des Schutzes personenbezogener Daten binnen 72 Stunden an die Aufsichtsbehörde zu melden. Diese Frist ist nur einhaltbar, wenn ein Vorfall überhaupt auffällt. Zugriffs- und Fehlerprotokollierung, Alarmierung und ein nachvollziehbares Job-Log sind deshalb Architekturbestandteile und keine spätere Ausbaustufe. Bei Standardsoftware hängt diese Fähigkeit davon ab, welche Protokolle der Anbieter Ihnen überhaupt zugänglich macht.

Die dritte betrifft buchhaltungsrelevante Daten: Die GoBD verlangen Unveränderbarkeit, Nachvollziehbarkeit und eine Verfahrensdokumentation. Für eine Eigenentwicklung bedeutet das konkret, dass eine Korrektur als neuer Datensatz mit Bezug auf den alten entsteht und nicht als stille Änderung am Original – und dass die Verfahrensdokumentation Teil des Projekts ist. Bei Standardsoftware liefert der Hersteller diese Eigenschaften in der Regel mit; das ist einer der stärksten Gründe, Buchhaltung zu kaufen.

Wenn Ihre Anwendung KI-Funktionen enthält, kommt die Verordnung (EU) 2024/1689 hinzu. Die Verbote unzulässiger Praktiken und die Pflichten zur KI-Kompetenz gelten seit dem 2. Februar 2025, weitere Pflichten greifen ab dem 2. August 2026. Ob und wie stark Sie betroffen sind, hängt vom Einsatzzweck ab und ist eine Rechtsfrage – planerisch relevant ist, dass Zweckbestimmung, Protokollierung und Transparenz gegenüber Nutzern früh festgelegt werden.

Fünf Fragen, die die Entscheidung tragen

Wenn Sie nur eine Seite aus diesem Artikel mitnehmen, dann diese. Die fünf Fragen sind so geschnitten, dass jede Antwort eine Konsequenz hat, die man aufschreiben kann. Beantworten Sie sie mit den Menschen, die den Prozess täglich ausführen, nicht nur mit der Geschäftsführung – Abweichungen zwischen beiden Antworten sind das wichtigste Ergebnis der Übung.