Individualsoftware entwickeln lassen: Ablauf, Anforderungen und die Fehler, die teuer werden

Individualsoftware entwickeln zu lassen heißt, einen fachlich beschriebenen Prozess in eine eigens dafür gebaute Anwendung zu übersetzen: Sie beschreiben, was die Software leisten soll und warum, ein Entwicklungspartner legt fest, wie das technisch umgesetzt wird, und beide arbeiten in kurzen Abschnitten mit Zwischenabnahmen bis zum Betrieb. Vorliegen müssen dafür ein dokumentierter Ist-Prozess, ein messbares Ziel, eine entscheidungsbefugte Person auf Ihrer Seite und eine ehrliche Antwort auf die Frage, ob Standardsoftware das Problem nicht ebenso löst. Fehlt einer dieser vier Punkte, scheitert das Projekt nicht zwangsläufig, aber es wird teurer, als es müsste.

Wann Individualsoftware überhaupt sinnvoll ist

Eigene Software lohnt sich dort, wo der Prozess selbst ein Wettbewerbsvorteil ist oder wo kein Standardprodukt den Ablauf ohne Verrenkungen abbildet. Typische Fälle sind Kalkulationen mit hausinterner Logik, Abläufe, die mehrere Systeme verbinden müssen, oder Kundenportale, die genau zum eigenen Angebot passen sollen. Nicht sinnvoll ist sie für Funktionen, die überall gleich aussehen: Buchhaltung, Lohnabrechnung, E-Mail, Dokumentenablage.

Die Vorentscheidung verdient eine eigene Prüfung, weil sie am Anfang am billigsten ist. Die Kriterien dafür stehen in Build vs. Buy: Wann sich eigene Software lohnt. Und zwischen Standardprodukt und klassischer Entwicklung liegt eine dritte Option, die für einfache Abläufe oft ausreicht; die Abgrenzung erklärt No-Code vs. Custom-Code.

Der Ablauf: von der Prozessaufnahme bis zum Betrieb

Der Ablauf ist in seriösen Projekten weitgehend gleich, unabhängig davon, ob er Wasserfall, agil oder hybrid genannt wird. Unterschiede liegen in der Länge der Abschnitte und darin, wie früh gebaut wird.

1. Prozessaufnahme: Der heutige Ablauf wird beschrieben, mit allen Ausnahmen, Sonderfällen und den Stellen, an denen heute Excel, Zettel oder Zuruf die Lücke füllen. Wer hier abkürzt, bezahlt jede ausgelassene Ausnahme später als Änderungsauftrag.
2. Anforderungen: Aus dem Prozess entsteht die Beschreibung, was die Software können muss, was sie können sollte und was ausdrücklich nicht dazugehört. Die dritte Liste ist die wichtigste.
3. Technisches Konzept und Angebot: Der Entwicklungspartner beschreibt, wie er die Anforderungen umsetzt: Architektur, Schnittstellen, Betriebsumgebung, Annahmen. Erst jetzt lässt sich seriös ein Aufwand schätzen.
4. Prototyp oder MVP: Eine erste lauffähige Fassung mit dem Kern des Prozesses, ohne Komfortfunktionen. Sie zeigt, ob die Annahmen stimmen, bevor der Großteil des Budgets ausgegeben ist.
5. Iterative Entwicklung: Kurze Abschnitte, jeweils mit lauffähigem Ergebnis, Vorführung und Rückmeldung. Prioritäten dürfen sich ändern, der Gesamtrahmen nicht unbemerkt.
6. Abnahme: Gegen vorher festgelegte Kriterien, mit echten Daten und den Personen, die später damit arbeiten. Eine Abnahme ohne Kriterien ist eine Meinungsäußerung.
7. Betrieb: Go-Live, Überwachung, Fehlerbehebung, Weiterentwicklung. Dieser Abschnitt dauert länger als alle anderen zusammen und wird am häufigsten vergessen.

Lastenheft, Pflichtenheft und was Sie liefern müssen

Die beiden Begriffe werden ständig verwechselt, dabei ist die Trennung einfach: Das Lastenheft schreibt der Auftraggeber. Es beschreibt, was die Software leisten soll und wozu, in der Sprache des Fachbereichs, ohne technische Vorgaben. Das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf. Es beschreibt, wie er die Anforderungen umsetzt, welche Annahmen er trifft und was er ausschließt. Erst das Pflichtenheft ist die Grundlage für Vertrag und Abnahme.

In der Praxis reicht für kleinere Vorhaben oft ein strukturiertes Anforderungsdokument mit Nutzerrollen, Abläufen und Abnahmekriterien; entscheidend ist nicht die Form, sondern dass die Trennung von „was" und „wie" eingehalten wird. Damit der Partner überhaupt arbeiten kann, müssen von Ihrer Seite vorliegen:

• Eine Beschreibung des Ist-Prozesses inklusive der Ausnahmen, nicht nur des Idealfalls.
• Beispieldaten in realistischer Menge und Qualität, anonymisiert, aber nicht geschönt.
• Eine Liste der Systeme, mit denen die Software Daten austauschen muss, samt Zugängen und Ansprechpartnern.
• Die Nutzerrollen mit ihren Rechten: Wer darf was sehen, ändern, freigeben?
• Abnahmekriterien in Form von prüfbaren Aussagen, idealerweise als konkrete Testfälle.
• Eine Person, die Entscheidungen trifft und dafür Zeit hat. Nicht ein Gremium, nicht die Geschäftsführung nebenbei.

Vertragsformen: Festpreis, Aufwand oder agil

Die Vertragsform legt fest, wer welches Risiko trägt. Keine ist grundsätzlich besser, jede passt zu einem anderen Grad an Klarheit.

Festpreis setzt voraus, dass der Leistungsumfang vollständig beschrieben ist. Der Auftragnehmer trägt das Risiko, dass er sich verschätzt, und kalkuliert dafür einen Puffer ein. Jede spätere Änderung wird zum Änderungsauftrag mit eigener Bewertung. Das funktioniert bei klar abgegrenzten, gut verstandenen Aufgaben und wird zäh, sobald sich während der Entwicklung herausstellt, dass der Prozess anders läuft als beschrieben.

Abrechnung nach Aufwand überträgt das Risiko auf Sie. Sie zahlen, was gearbeitet wird, und behalten die Freiheit, Prioritäten zu verschieben. Das verlangt laufende Steuerung, transparente Aufwandsnachweise und ein Budgetlimit, bei dessen Erreichen gestoppt und neu bewertet wird.

Agile Verträge verbinden beides: ein festes Budget je Zeitabschnitt, innerhalb dessen Ihre Seite die Reihenfolge der Anforderungen bestimmt und der Partner ein lauffähiges Ergebnis liefert. Der Umfang ist variabel, das Budget nicht. Das setzt einen handlungsfähigen Product Owner voraus. Ob ein solcher Vertrag rechtlich als Werk- oder Dienstvertrag gilt und welche Gewährleistung daraus folgt, ist eine Frage für die Fachberatung, nicht für den Projektstart.

Die Fehler, die Projekte teuer machen

Die Mehrkosten in Softwareprojekten entstehen fast nie beim Programmieren. Sie entstehen davor und danach.

• Unklare Prozesse: Wenn zwei Abteilungen denselben Vorgang unterschiedlich beschreiben, baut die Software eine dritte Version. Die Klärung gehört vor den ersten Entwicklungstag, nicht in die Abnahme.
• Fehlender Product Owner: Ohne eine Person, die priorisiert und entscheidet, wartet das Team, rät oder baut das Naheliegende. Alle drei Varianten kosten Geld.
• Scope-Creep: Jede einzelne Zusatzidee ist klein. In Summe verdoppeln sie den Umfang, ohne dass jemand einen Änderungsauftrag gesehen hat. Abhilfe ist ein sichtbarer Änderungsprozess, kein Verbot.
• Keine Tests: Software ohne automatisierte Tests lässt sich nach dem Go-Live nur noch mit Angst ändern. Warum das jede spätere Erweiterung verteuert, steht in Testautomatisierung: Warum Software ohne Tests nicht skaliert.
• Kein Betriebskonzept: Wer betreibt die Anwendung, wer sichert die Daten, wer wird nachts geweckt, wer spielt Updates ein? Wird das erst nach dem Go-Live geklärt, klärt es sich beim ersten Ausfall.
• Vendor-Lock-in: Eine Anwendung, die nur der ursprüngliche Dienstleister versteht, ist keine eigene Software, sondern ein Abonnement ohne Kündigungsfrist. Austauschbarkeit ist eine Architekturentscheidung, wie Vendor-Lock-in vermeiden beschreibt.

Wem Code und Daten gehören

Nach deutschem Urheberrecht bleibt derjenige Urheber, der den Code geschrieben hat. Übertragen werden Nutzungsrechte, und deren Umfang muss im Vertrag stehen: ausschließlich oder einfach, zeitlich und räumlich unbeschränkt, mit dem Recht zur Bearbeitung und zur Weitergabe an Dritte. Ohne diese Klauseln dürfen Sie die Software vielleicht benutzen, aber nicht von einem anderen Dienstleister weiterentwickeln lassen.

Dazu gehören drei praktische Punkte, die häufiger fehlen als die Rechtsklausel selbst: die Herausgabe des vollständigen Quellcodes samt Build-Anleitung, die Auflistung der verwendeten Bibliotheken mit ihren Lizenzen, und Zugänge zu Hosting, Domains und Diensten in Ihrem Namen, nicht im Namen des Partners. Bei Daten gilt: Sie gehören Ihnen, und die Software muss sie in einem offenen, dokumentierten Format exportieren können. Eine Datenbank, aus der nur die Anwendung selbst lesen kann, ist eine Sackgasse. Für die konkrete Vertragsgestaltung ist eine rechtliche Prüfung angebracht.

Nach dem Go-Live: Betrieb, Wartung, Weiterentwicklung

Mit dem Go-Live beginnt die längste Phase. Software altert, auch wenn sie nicht angefasst wird: Betriebssysteme, Bibliotheken und Schnittstellen der Nachbarsysteme ändern sich, Sicherheitslücken werden bekannt, und die fachlichen Anforderungen wachsen. Wer dafür weder Budget noch Zuständigkeit einplant, sammelt Rückstand an, der irgendwann teurer ist als eine Neuentwicklung. Wie dieser Rückstand entsteht und wirkt, beschreibt Technische Schulden: Warum alte Systeme Wachstum bremsen.

Zum Betriebskonzept gehören eine getrennte Test- und Produktivumgebung, geregelte Datensicherung mit geprobter Wiederherstellung, definierte Reaktionszeiten für Fehler und eine Überwachung, die Probleme meldet, bevor Nutzer sie melden; die Grundlagen dazu stehen in Monitoring und Alerting. Ob das der Entwicklungspartner, ein Hoster oder das eigene Haus übernimmt, ist zweitrangig. Entscheidend ist, dass es vor dem Go-Live schriftlich festgelegt ist.

Wo Standardsoftware klar besser ist

Individualsoftware ist kein Qualitätsmerkmal, sondern ein Werkzeug für einen bestimmten Fall. In mehreren Situationen ist Standardsoftware die bessere Entscheidung, auch wenn sie sich nicht perfekt anfühlt:

• Der Prozess ist gesetzlich oder branchenüblich vorgegeben. Buchhaltung, Lohn, Steuer und Archivierung ändern sich mit der Rechtslage, und ein Anbieter mit vielen Kunden pflegt das schneller und günstiger als ein Einzelprojekt.
• Niemand im Haus kann oder will die Rolle des Product Owners übernehmen. Ohne diese Rolle liefert Individualentwicklung teure Näherungen an eine unklare Vorstellung.
• Der Bedarf ist noch nicht stabil. Wer den eigenen Prozess in einem Jahr voraussichtlich zweimal umbaut, sollte erst mit einem konfigurierbaren Werkzeug arbeiten und dann entscheiden, was sich als Kern erwiesen hat.
• Das Problem ist nicht die Software, sondern der Prozess. Ein unklarer Ablauf wird durch Programmierung nicht klarer, nur schneller.
• Die Anwendung soll morgen laufen. Individualsoftware braucht Zeit für Aufnahme, Konzept und Abnahme; wer das überspringt, bekommt keine schnellere Lösung, sondern eine schlechtere.

Die ehrliche Antwort auf die Frage, ob eigene Software nötig ist, ist häufiger „noch nicht" als „nein". Wer sie sich stellt, bevor der erste Entwicklungstag bezahlt wird, hat den teuersten Fehler bereits vermieden.