Ob ein Softwareprojekt trägt, entscheidet sich oft vor der ersten Codezeile: bei der Wahl der Option, beim Umfang, bei Schnittstellen und Betrieb. Das sollten Sie klären, bevor Sie Software entwickeln lassen.
Erst prüfen: Welche Option passt zu Ihrem Vorhaben?
Die vier üblichen Wege im Überblick:
| Option | Passt, wenn … | Risiko | Laufende Abhängigkeit |
|---|
| Standardsoftware | der Prozess branchenüblich ist und sich an das Produkt anpassen darf | aufwendige Anpassungen, wenn der Ablauf doch abweicht | Hersteller, Lizenzmodell, Update-Zyklus |
| Low-Code-Plattform | Fachbereiche einfache Formulare und Workflows selbst bauen sollen | Grenzen bei Schnittstellen, Rechten und Datenmengen; Wildwuchs ohne Regeln | Plattformanbieter, Anwendungen sind an die Plattform gebunden |
| Eigenes Entwicklungsteam | Software dauerhaft Kern Ihres Geschäfts ist und mehrere Entwickler auslastet | Aufbau dauert, Wissen hängt an wenigen Personen | eigene Mitarbeitende, Recruiting |
| Individualsoftware vom Dienstleister | ein abgegrenzter Prozess oder eine Schnittstelle fehlt und kein Produkt passt | unklare Anforderungen, Abhängigkeit ohne Dokumentation und Rechte | Dienstleister, solange Code und Doku nicht übergeben sind |
Für Buchhaltung oder Lohnabrechnung ist Standardsoftware fast immer die bessere Wahl. Den ausführlichen Vergleich finden Sie im Ratgeber Excel und Access ablösen.
Was Sie vor dem ersten Gespräch klären sollten
Ein formales Lastenheft brauchen Sie für das Erstgespräch nicht. Hilfreich sind Antworten auf fünf Fragen:
- Welcher Ablauf soll sich ändern, und wo kostet er heute Zeit oder verursacht Fehler?
- Wer nutzt die Software, in welchen Rollen und ungefähr wie viele Personen?
- Aus welchen Systemen kommen Daten, und wohin müssen sie weiter?
- Woran messen Sie nach sechs Monaten, ob sich das Projekt gelohnt hat, zum Beispiel Durchlaufzeit oder Rückfragen?
- Wer im Fachbereich darf entscheiden, wenn Anforderungen sich widersprechen?
Wenn Sie Ihre Anforderungen schriftlich ausarbeiten wollen, hilft unser Leitfaden zum Lastenheft für Software- und KI-Projekte.
Den ersten Umfang klein schneiden
Ein typischer Fehler ist ein erster Release, der alle Abteilungen gleichzeitig bedienen soll. Besser ist ein Ablauf, der von Anfang bis Ende funktioniert, mit echten Daten und mindestens einer echten Schnittstelle. Bei einer Freigabe von Prüfprotokollen wären das Erfassung, Freigabe und Ablage mit Übergabe an das ERP-System; Auswertungen und Sonderfälle folgen in den nächsten Iterationen. So sehen Sie früh, ob die Lösung im Alltag trägt.
Typische Fallstricke
- Versteckte Sonderfälle: Bestehende Abläufe enthalten Regeln, die nirgends dokumentiert sind, in Altsystemen, Tabellen oder Köpfen. Wir gehen sie mit den Anwendern Fall für Fall durch, bevor wir das Datenmodell festlegen.
- Schnittstellen zuletzt: Wer die Anbindung erst am Ende testet, findet die Probleme am Ende. Wir testen schon im ersten Inkrement gegen die Gegenstelle, wo möglich gegen deren Testsystem.
- Datenmigration unterschätzt: Dubletten, Freitextfelder und veraltete Einträge machen oft mehr Arbeit als die neue Oberfläche.
- Betrieb vergessen: Updates, Backups, Monitoring und Zuständigkeiten gehören in die Planung, nicht in die Woche nach dem Go-Live.
Bestehende Software übernehmen oder neu bauen?
Haben Sie bereits eine Anwendung, die schwer wartbar ist, lohnt vor der Entscheidung ein Blick von außen. Unser Software-Architektur-Review bewertet Code, Architektur und Betrieb und zeigt, was sich stabilisieren lässt. Welche Modernisierungsstrategien es gibt, beschreibt der Artikel Software modernisieren oder neu entwickeln.
Nutzungsrechte im Vertrag regeln
Das Urheberrecht an Software ist nach § 29 UrhG nicht übertragbar; eingeräumt werden können Nutzungsrechte nach § 31 UrhG. Die Regel, dass bei angestellten Entwicklern der Arbeitgeber alle vermögensrechtlichen Befugnisse am Programm ausübt, sofern nichts anderes vereinbart ist (§ 69b UrhG), gilt für externe Dienstleister nicht. Sind die Nutzungsarten im Vertrag nicht ausdrücklich bezeichnet, richtet sich ihr Umfang nach dem Vertragszweck (§ 31 Abs. 5 UrhG), und darüber lässt sich später streiten. Achten Sie deshalb auf drei Punkte: ausschließliche Nutzungsrechte am individuell entwickelten Code, Herausgabe von Quellcode samt Build- und Infrastrukturdefinitionen sowie eine Liste der verwendeten Open-Source-Komponenten mit ihren Lizenzen.
Allgemeine Information, keine Rechtsberatung. Stand September 2026.