Individualsoftware

Was ist Individualsoftware?

Individualsoftware wird für einen konkreten organisatorischen Kontext entwickelt. Das kann eine komplette Geschäftsanwendung sein, aber auch ein Kundenportal, internes Werkzeug, Integrationssystem oder eine gezielte Erweiterung bestehender Software.

„Individuell“ bedeutet nicht automatisch, dass jede technische Komponente neu programmiert wird. Moderne Entwicklung nutzt Frameworks, Bibliotheken, Cloud-Dienste und Standardkomponenten. Individuell ist vor allem die fachliche Lösung und ihre Integration.

Individualsoftware oder Standardsoftware?

Standardsoftware beziehungsweise Commercial Off-the-Shelf Software (COTS) wird für einen breiteren Markt entwickelt. Sie ist sinnvoll, wenn etablierte Prozesse mit marktüblichen Funktionen gut abgedeckt werden können.

Morisio et al. untersuchten COTS-basierte Softwareentwicklung in NASA-Projekten und zeigten, dass sich der Entwicklungsprozess unter anderem bei Requirements und Produktauswahl von klassischer Eigenentwicklung unterscheidet. Das unterstreicht: „Kaufen oder bauen?“ ist keine reine Preisfrage, sondern verändert Anforderungen, Architektur und Projektvorgehen.

Wann kann Individualsoftware sinnvoll sein?

• Ein geschäftskritischer Prozess unterscheidet sich deutlich vom Standard.
• Workarounds über Excel und E-Mail erzeugen dauerhaft hohe Koordination.
• Mehrere Systeme müssen mit eigener Prozesslogik verbunden werden.
• Eine vorhandene Standardlösung wäre nur mit unverhältnismäßig vielen Anpassungen nutzbar.
• Der individuelle Prozess ist selbst Teil der Differenzierung des Unternehmens.

Wann ist Standardsoftware wahrscheinlich besser?

Wenn ein Prozess weitgehend standardisiert ist – etwa allgemeine Buchhaltung, E-Mail oder Office-Kommunikation – ist eine eigene Entwicklung meist weder wirtschaftlich noch sinnvoll. Standardprodukte verteilen Entwicklungs- und Wartungskosten auf viele Kunden und profitieren häufig von einem größeren Ökosystem.

Gute Beratung empfiehlt deshalb nicht automatisch Individualsoftware.

Requirements Engineering vor der Entwicklung

Bei Individualsoftware ist Requirements Engineering besonders wichtig, weil Funktionsumfang und Systemgrenzen nicht bereits durch ein fertiges Produkt vorgegeben sind. Stakeholder, Ziele, Prozesse, Daten, Rollen, Schnittstellen und Qualitätsanforderungen müssen so weit geklärt werden, dass ein belastbarer erster Umfang entsteht.

Nuseibeh und Easterbrook beschreiben Requirements Engineering als Prozess, den Zweck eines Systems durch Stakeholder und ihre Bedürfnisse zu entdecken und zu konkretisieren. Genau dieser Zweck sollte vor Technologieentscheidungen im Mittelpunkt stehen.

Warum schrittweise Entwicklung sinnvoll ist

Komplexe Anforderungen verändern sich, wenn Nutzer erste reale Zwischenstände sehen. Deshalb kann eine inkrementelle Umsetzung das Risiko reduzieren. Ein klar begrenzter Kernprozess wird zuerst nutzbar gemacht; weitere Funktionen folgen nach Feedback und Priorität.

Das ist nicht dasselbe wie „ohne Planung losprogrammieren“. Architektur, Datenschutz, kritische Schnittstellen und grundlegende Systemgrenzen müssen früh genug geklärt werden.

Lebenszyklus und Total Cost of Ownership

Die Entwicklungsrechnung ist nur ein Teil der Kosten. Langfristig relevant sind:

• Hosting und Infrastruktur,
• Monitoring und Backups,
• Sicherheitsupdates,
• Framework- und Dependency-Updates,
• Support,
• Weiterentwicklung,
• Dokumentation und Wissenstransfer.

Eine gute Make-or-Buy-Entscheidung betrachtet daher den gesamten Lebenszyklus.

Praxisbeispiel

Ein Unternehmen bearbeitet komplexe Aufträge in einer Standard-ERP-Lösung, organisiert aber Freigaben, Kundenunterlagen und Statuskommunikation außerhalb des Systems. Eine individuelle Ergänzung kann genau diesen Zwischenprozess abbilden und per API mit dem ERP verbunden werden, ohne das Kernsystem zu ersetzen.

Vendor Lock-in und Quellcode gehören in die Entscheidung

Bei Individualsoftware sollte früh geklärt werden, wem Quellcode, Dokumentation und Deployment-Konfigurationen gehören und wie ein Anbieterwechsel technisch möglich wäre. Das bedeutet nicht, dass jede Lösung ohne Einarbeitung übertragbar sein muss; es reduziert aber unnötige Abhängigkeiten.

Ebenso wichtig sind dokumentierte Schnittstellen und ein reproduzierbarer Build-/Deployment-Prozess. Langfristige Wartbarkeit ist ein Teil der Produktqualität und sollte nicht erst beim ersten Entwicklerwechsel betrachtet werden.

Fazit

Individualsoftware ist kein Selbstzweck und kein Qualitätsmerkmal an sich. Sie lohnt sich, wenn der spezifische Prozess einen wirtschaftlich relevanten Unterschied macht und Standardlösungen diesen Unterschied nicht sinnvoll tragen. Dann kann eine passgenaue Anwendung dauerhaft weniger Kompromisse erzeugen – vorausgesetzt Anforderungen, Architektur und Betrieb werden professionell geplant.