Individualsoftware oder Standardsoftware

Für Finanzbuchhaltung, Lohnabrechnung, Warenwirtschaft im Handel oder klassisches Kontaktmanagement gibt es Marktlösungen, die seit Jahrzehnten gepflegt werden. Ihre Entwicklungskosten verteilen sich auf tausende Installationen. Was Sie an Lizenz zahlen, ist ein Bruchteil dessen, was dieselbe Funktionalität als Einzelanfertigung kosten würde. Wer eine Buchhaltung neu programmieren lässt, bezahlt für etwas, das es fertig gibt, und übernimmt zusätzlich die Verantwortung für dessen Pflege.

Der zweite Punkt fehlt in vielen Kalkulationen. Standardsoftware bringt regulatorische Änderungen als Update mit. Die Pflicht, E-Rechnungen im inländischen B2B-Verkehr empfangen zu können, gilt seit dem 1. Januar 2025; die Versandpflicht greift gestaffelt ab 2027 und für kleinere Unternehmen ab 2028. Ein Buchhaltungssystem muss Formate nach EN 16931 verarbeiten, also XRechnung und ZUGFeRD ab Version 2.0.1. Beim Standardanbieter steht diese Anpassung im Wartungsvertrag. Bei einer Eigenentwicklung ist sie ein Auftrag mit Aufwandsschätzung und Termin.

Dazu kommt der Arbeitsmarkt. Für ein verbreitetes System finden Sie Bewerber, die es bereits bedient haben, und Schulungen, die Sie einkaufen können. Eine Eigenentwicklung kennt außer Ihrem Team und dem Entwickler niemand. Dasselbe gilt für Fehler: In einer Marktlösung fallen sie tausenden Anwendern auf, bevor sie Ihnen auffallen. In Ihrer Eigenentwicklung finden Sie sie selbst.

Wir raten regelmäßig zum Standard. Wenn sich ein Ablauf ohne betrieblichen Nachteil an eine Marktlösung anpassen lässt, ist das der günstigere Weg, und ein Angebot von uns wäre teurer, als das Ergebnis wert ist. Individualsoftware rechnet sich dort, wo der Prozess selbst der Grund ist, warum Kunden bei Ihnen kaufen, oder wo keine Marktlösung die Fachlogik abbildet.

Die folgende Gegenüberstellung beschreibt die Regelfälle. Einzelne Hersteller weichen ab, und die Angaben zur Individualentwicklung beziehen sich auf unser Vertragsmodell. Prüfen Sie beides an Ihrem konkreten Angebot nach.

Standardsoftware ist billig, solange sie im Standard bleibt. Der Punkt, an dem sich das dreht, ist selten ein einzelner großer Posten. Es sind Anpassungen, die einzeln vertretbar wirken und sich über Jahre summieren.

Customizing wird bei jedem Update erneut bezahlt

Jede Erweiterung am Standard muss beim nächsten Release getestet und oft nachgezogen werden. Mit der Zahl der Anpassungen steigen die Upgradekosten. Ab einem gewissen Punkt entscheiden Unternehmen, auf einer alten Version zu bleiben, weil das Update zu teuer geworden ist. Damit enden auch die Sicherheitsupdates, und das Thema kommt später als größeres Problem zurück. Ein Blick in die Wartungshistorie der letzten drei Jahre zeigt, ob Ihr System diesen Weg bereits eingeschlagen hat.

Nutzerbasierte Lizenzen bestrafen Wachstum

Preise pro Nutzer und Monat sind kalkulierbar, solange die Nutzerzahl stabil bleibt. Sie werden unangenehm, wenn Monteure, Lagerkräfte oder Aushilfen einen Zugang brauchen, die im System zwei Masken bedienen. Rechnen Sie die Lizenzsumme für die Mitarbeiterzahl durch, die Sie in fünf Jahren erwarten, und lassen Sie sich die Preisanpassungsklausel im Vertrag zeigen.

Die Schattenprozesse tauchen in keinem Angebot auf

Wo eine Marktlösung nicht passt, entstehen Tabellen daneben. Sie werden per Mail verschickt und liegen am Ende in zwei Versionen vor, von denen niemand sagen kann, welche gilt. Diese Arbeitszeit steht in keiner Softwarekalkulation, verursacht aber Fehler, die später jemand suchen muss. Wenn Sie den Aufwand für Individualsoftware bewerten, gehört auf die Gegenseite die Zeit, die heute in diese Zwischenschritte fließt.

Keines der folgenden Anzeichen genügt für sich allein. Wenn Sie mehrere davon wiederfinden, lohnt sich eine Kalkulation über fünf Jahre, bevor Sie den nächsten Lizenzvertrag verlängern.

• Der Ablauf, um den es geht, ist ein Grund, warum Kunden bei Ihnen kaufen und nicht beim Mitbewerber.
• Sie haben mehrere Marktlösungen geprüft und bei jeder dieselbe Lücke gefunden.
• Zwischen zwei Systemen werden Daten von Hand übertragen, weil es keine Schnittstelle gibt.
• Die Lizenzkosten wachsen mit Mitarbeitern, die das System kaum benutzen.
• Ihr Hersteller hat ein Wartungsende veröffentlicht oder das Produkt abgekündigt.
• Fachlogik, die über Preise oder Zulässigkeit entscheidet, steckt im Kopf einzelner Mitarbeiter.
• Die Zahl der Tabellen, die neben dem System geführt werden, nimmt jedes Jahr zu.

Die Entscheidung fällt selten für ein ganzes Unternehmen. In den meisten Projekten bleibt eine Marktlösung das führende System für Buchhaltung und Stammdaten, und individuell entwickelt wird dort, wo der Standard aufhört. Die entscheidende Frage ist dann, wie sauber beide Seiten miteinander sprechen.

Bei mexxenergie, einem Energiedienstleister in Baden-Württemberg, haben wir eine mandantenfähige Plattform mit vier Fachmodulen gebaut: Zählerstände und Lieferstellen, Verträge, Objekt- und Dokumentenverwaltung sowie Verbrauchs- und Kostenauswertung. Die Migration lief im laufenden Betrieb, mit Abgleichszahlen vor und nach jedem Lauf. Ein Standardprodukt hätte diese Kombination aus Mandantentrennung und Abrechnungslogik nicht abgebildet.

Bei Yido Performance war der Auslöser die Gutachtenlage: Aus XML-Dateien entstehen automatisiert Shop-Produkte, dazu ein 3D-Konfigurator mit 152 Felgen, Warenwirtschaft und Onlineshop. Bei Glanz K laufen vier Systeme auf einem gemeinsamen Backend, der Shop nach WCAG 2.1 AA. In keinem dieser Projekte wurde eine Buchhaltung ersetzt. Die Standardsysteme daneben sind geblieben.

Der Preis der Mischform sind die Schnittstellen. Jede Verbindung zu einem fremden System ist eine Stelle, die bei einem Update des Herstellers brechen kann, und wir haben keinen Einfluss darauf, ob ein Anbieter sein Format oder seine API ändert. Wir können den Fehler schnell beheben und die Schnittstelle so bauen, dass sie Abweichungen meldet statt sie stillschweigend zu verschlucken. Ausschließen können wir den Ausfall nicht. Wer eine Schnittstelle in einen Prozess einbaut, der stündlich laufen muss, sollte wissen, wie der manuelle Notweg aussieht.

• Schnittstellen zwischen bestehenden Systemen
• Altsysteme ablösen
• Projekt mexxenergie

Die Abhängigkeit verschwindet nicht, sie wechselt den Adressaten. Statt vom Hersteller hängen Sie von einem Entwicklungsteam ab, das Ihr System kennt. Dass der Quellcode Ihnen ab Tag eins gehört, löst das nur teilweise. Code ohne Dokumentation und ohne jemanden, der die fachlichen Entscheidungen erklären kann, ist für ein Nachfolgeteam mühsam. Achten Sie im Vertrag auf Repository-Zugang, auf die Betriebsdokumentation und darauf, wer im Ernstfall übernehmen könnte.

Auch gesetzliche Änderungen werden zu Ihrer Position im Budget. Was bei Standardsoftware im Wartungsvertrag steckt, ist hier ein Auftrag. Das gibt Ihnen die Kontrolle über den Termin und nimmt Ihnen die Bequemlichkeit. Für den laufenden Betrieb kalkulieren wir 12 bis 18 Prozent der Projektsumme pro Jahr; darin stecken Betreuung, Sicherheitsaktualisierungen und die technische Pflege der eingesetzten Frameworks.

Ein Punkt lässt sich nicht wegverhandeln: Ob eine Eigenentwicklung tatsächlich messbar produktiver macht, hängt an der Qualität des Feinkonzepts und an der Bereitschaft der Fachabteilung, ihre Abläufe offenzulegen. Wir können den Aufwand schätzen und den Betrieb zusagen. Eine belastbare Aussage darüber, wie viele Arbeitsstunden Sie später einsparen, macht seriös niemand vor der Analysephase.

Stellen Sie beide Wege über denselben Zeitraum gegenüber, üblicherweise fünf Jahre. Belastbar wird der Vergleich erst, wenn auf beiden Seiten auch die Posten stehen, die in keinem Angebot auftauchen.

Was auf die Seite der Marktlösung gehört

• Lizenz- oder Abogebühren über fünf Jahre, inklusive vertraglicher Preisanpassung
• Einführungsprojekt mit Konfiguration, Datenübernahme und Schulung
• Wartungsanteil und Kosten für Add-on-Module anderer Hersteller
• Customizing und dessen Nachpflege bei jedem Release
• Die geplanten Versionswechsel, nicht nur der laufende Betrieb
• Interne Arbeitszeit für manuelle Zwischenschritte und doppelte Datenpflege

Was auf die Seite der Individualentwicklung gehört

• Entwicklung nach Umfang, einmalig
• Datenmigration und Testphase
• Schulung und die Einarbeitungszeit der Anwender
• Hosting in Deutschland oder der EU
• Betriebsbetreuung, bei uns 12 bis 18 Prozent der Projektsumme pro Jahr
• Aufwand für gesetzliche Änderungen, die hier jedes Mal beauftragt werden müssen

Für die zeitliche Planung arbeiten wir mit fünf Phasen. Die Analyse steht bewusst am Anfang, weil sie die einzige Stelle ist, an der sich der Umfang noch günstig korrigieren lässt.

1. Analyse und Feinkonzept, 1 bis 3 Wochen
2. Entwicklung in Zwei-Wochen-Takten, 6 bis 20 Wochen
3. Datenmigration und Tests, 2 bis 4 Wochen
4. Go-live und Schulung, 1 bis 2 Wochen
5. Betreuung, laufend

Zur Größenordnung: Ein klar umrissenes Fachsystem, das einen abgegrenzten Bereich abdeckt, liegt in einem anderen Rahmen als eine Plattform, die mehrere Bestandssysteme anbindet und über Jahre wächst.

Diese Bänder beschreiben Erfahrungswerte für den Umfang und sind kein Angebot. Was ein konkretes Vorhaben kostet, steht nach der Analysephase fest; bis dahin lässt sich seriös nur über Spannen sprechen.

Ab welcher Unternehmensgröße lohnt sich Individualsoftware?

Die Mitarbeiterzahl ist der schwächere Indikator. Entscheidend ist, wie viel Arbeitszeit heute in Abläufe fließt, die kein System abbildet, und ob dieser Ablauf für Ihr Geschäft besonders ist. Ein Betrieb mit 60 Mitarbeitern und einem komplizierten Kalkulationsverfahren hat den klareren Fall als ein Unternehmen mit 300 Mitarbeitern, dessen Prozesse dem Branchenstandard entsprechen.

Können wir unsere Standardsoftware anpassen lassen, statt neu zu entwickeln?

Oft ja, und das ist häufig der günstigere Weg. Die Frage ist, wie tief die Anpassung reicht. Alles, was innerhalb der vorgesehenen Erweiterungspunkte bleibt, überlebt Updates in der Regel. Alles, was in den Kern eingreift, wird bei jedem Release zur Nacharbeit. Lassen Sie sich vom Anbieter schriftlich geben, in welche Kategorie Ihre gewünschte Anpassung fällt.

Wem gehört der Quellcode bei einer Individualentwicklung?

Bei uns dem Kunden, ab Tag eins, samt Repository-Zugang. Das ist am Markt keine Selbstverständlichkeit. Es gibt Verträge, in denen der Dienstleister die Rechte behält und nur ein Nutzungsrecht einräumt. Der Unterschied wird erst relevant, wenn Sie den Anbieter wechseln wollen, und dann ist er entscheidend.

Was passiert, wenn unser Entwicklungspartner ausfällt?

Dieses Risiko besteht, und es lässt sich begrenzen, aber nicht ausschließen. Was hilft: Code und Datenbank liegen bei Ihnen, die Betriebsdokumentation beschreibt Deployment und Abhängigkeiten, und die eingesetzten Technologien sind verbreitet genug, dass andere Teams damit arbeiten können. Fragen Sie jeden Anbieter, wie ein Übergabepaket bei ihm aussieht.

Wie lange dauert es, bis wir produktiv arbeiten können?

Nach unserem Phasenmodell zwischen 10 und 29 Wochen. Die Spanne ist groß, weil der Entwicklungsteil zwischen 6 und 20 Wochen liegt. Verlässlicher wird die Aussage nach der Analysephase. Eine Marktlösung ist in einfachen Fällen schneller im Einsatz; bei ERP-Einführungen mit Datenübernahme und Schulung verschiebt sich der Vorsprung deutlich.

Rechnet sich Individualsoftware allein über eingesparte Lizenzkosten?

Bei stabiler Nutzerzahl eher nicht. Die Rechnung geht meistens dann auf, wenn zusätzlich manuelle Arbeit entfällt, Lizenzkosten mit der Mitarbeiterzahl wachsen oder ein Wartungsende ohnehin eine Investition erzwingt. Wer nur Lizenzen gegen Entwicklungskosten rechnet, kommt in den meisten Fällen zum Ergebnis, dass der Standard günstiger ist.

Was ist mit Datenschutz und Hosting?

Bei SaaS-Produkten bestimmt der Hersteller Serverstandort und Unterauftragsverarbeiter; beides steht im Auftragsverarbeitungsvertrag und ändert sich gelegentlich. Bei einer Eigenentwicklung wählen Sie das Hosting, bei uns in Deutschland oder der EU, und behalten den direkten Zugriff auf die Datenbank. Die Pflichten aus der DSGVO bleiben in beiden Fällen bei Ihnen als Verantwortlichem.

Können wir klein anfangen?

Ja, und das ist häufig sinnvoll. Ein erster Ausschnitt, der einen einzelnen Ablauf vollständig abdeckt, zeigt nach wenigen Wochen, ob die Zusammenarbeit trägt und ob die fachlichen Annahmen stimmen. Der Nachteil: Ein zu klein geschnittener Anfang kann Architekturentscheidungen erzwingen, die später teuer nachzubessern sind. Diese Abwägung gehört in die Analysephase.

Wenn Sie unsicher sind, auf welcher Seite Ihr Fall liegt, schicken Sie uns die Beschreibung des Ablaufs, der heute nicht passt, und die Zahl der betroffenen Mitarbeiter. Wir sagen Ihnen, ob wir eine Marktlösung für den besseren Weg halten. Das kommt häufiger vor, als es sich für ein Softwarehaus gehört.

• Individualsoftware im Überblick
• Ablauf und Kosten
• Festpreis oder Abrechnung nach Aufwand
• E-Rechnungspflicht
• Prozesse digitalisieren