Wer Software entwickeln lassen möchte, sollte nicht mit Programmiersprachen oder Funktionen beginnen, sondern mit der Frage, welches geschäftliche Problem gelöst werden soll. Denn noch bevor die erste Zeile Code entsteht, fallen Entscheidungen über Standard- oder Individualsoftware, Umfang, Budget, Verantwortlichkeiten und den passenden Umsetzungspartner.

Gerade für Unternehmen ohne eigenes großes Entwicklungsteam ist deshalb die Vorbereitung entscheidend. Ein gutes Softwarevorhaben beginnt mit einem klaren Problem, nachvollziehbaren Zielen und ausreichend definierten Rahmenbedingungen – ohne bereits jedes Detail der späteren Lösung festzuschreiben.

Dieser Artikel zeigt aus Auftraggebersicht, wann sich individuelle Software lohnt, was vor einer Beauftragung geklärt sein sollte, wie sich Anforderungen und Kosten einordnen lassen und worauf Unternehmen bei Anbieterwahl und Vertragsmodell achten sollten. Wie professionelle Softwareentwicklung anschließend von der Anforderung bis zum Betrieb organisiert wird, erläutert ergänzend der Beitrag „Softwareentwicklung im Unternehmen“.

• Software entwickeln lassen: Was vor der Beauftragung geklärt sein sollte
• Standardsoftware oder Individualsoftware: Wann lohnt sich welche Lösung?
• Anforderungen klären, ohne das Projekt zu überplanen
• Software entwickeln lassen: Ablauf von der Klärung bis zum Betrieb
• Was kostet es, Software entwickeln zu lassen?
• Softwareentwickler auswählen und Angebote richtig vergleichen
• Vertragsmodelle, Nutzungsrechte und Datenschutz
• Fazit
• FAQ zur Softwareentwicklung

Sechs Punkte sollten intern feststehen, bevor der erste Anbieter angesprochen wird:

1. Das Problem.
   Nicht die gewünschte Lösung, sondern das Problem dahinter. „Wir brauchen ein Tool für die Auftragserfassung" ist eine Lösung. „Aufträge werden dreimal erfasst und dabei entstehen Fehler" ist ein Problem – und lässt mehrere Lösungswege zu, von denen die Eigenentwicklung nur einer ist.
2. Das Erfolgskriterium.
   Woran soll später erkennbar sein, dass die Investition tatsächlich etwas verbessert? Das kann beispielsweise eine kürzere Bearbeitungszeit, weniger manuelle Übertragungen, eine geringere Fehlerquote oder ein vollständig neuer digitaler Prozess sein. Ohne ein überprüfbares Ziel lässt sich später zwar feststellen, dass Software geliefert wurde – aber nicht, ob sie das ursprüngliche Problem gelöst hat.
3. Die Entscheidungsbefugnis.
   Wer legt fest, was gebaut wird, wenn Fachbereich und IT unterschiedlicher Meinung sind? Ohne benannte Person mit Zeit und Mandat gerät jedes Vorhaben ins Stocken – und zwar genau dann, wenn die Umsetzung läuft und Antworten schnell gebraucht werden.

    

4. Das Budget.
   Nicht als Verhandlungstaktik zurückgehalten, sondern als Rahmen genannt. Ein Anbieter, der die Größenordnung kennt, kann einen passenden Umfang vorschlagen. Ohne diese Information entstehen Angebote, die entweder zu groß oder zu klein sind.

5. Der Zeitpunkt.
   Gibt es einen fixen Termin – Messe, Vertragsende, gesetzliche Frist? Dann bestimmt er den Umfang, nicht umgekehrt.

6. Die Kapazität.
   Ebenso wichtig ist eine ehrliche Einschätzung der eigenen Kapazität. Ein Softwarevorhaben bindet interne Zeit, auch wenn extern entwickelt wird: für Abstimmungen, Rückfragen, Tests und Abnahmen. Wer diese Zeit nicht einplant, verzögert das Projekt und gibt später dem Dienstleister die Schuld.

Wer Software entwickeln möchte, sollte zuerst prüfen, ob eine individuelle Lösung tatsächlich einen zusätzlichen Nutzen gegenüber Standardsoftware bietet. Standardsoftware ist häufig sinnvoll, wo Anforderungen weitgehend marktüblich sind – Individualentwicklung dort, wo sie einen relevanten Unterschied macht.

Für stark standardisierte Aufgaben wie Buchhaltung oder Lohnverrechnung sind etablierte Standardlösungen häufig wirtschaftlicher als eine vollständige Eigenentwicklung. Individuelle Software wird insbesondere dort interessant, wo bestehende Produkte zentrale Anforderungen nicht sinnvoll abdecken, spezielle Integrationen erforderlich sind oder ein digitaler Ablauf einen echten Unterschied im Geschäftsmodell schafft.
Eine Eigenentwicklung lohnt dort, wo ein Ablauf das Geschäft tatsächlich unterscheidet – eine besondere Kalkulationslogik, eine spezielle Fertigungssteuerung, eine Verbindung mehrerer Systeme, die es so nicht von der Stange gibt.

Ein sinnvoller Mittelweg kann darin bestehen, Standardsoftware gezielt zu ergänzen statt vollständig zu ersetzen. Eine individuelle Erweiterung kann wirtschaftlicher sein als eine komplette Eigenentwicklung und ermöglicht es, bestehende Systeme weiter zu nutzen.

Vor der Entscheidung lohnt der Blick auf den Prozess selbst. Häufig ist nicht die Software das Problem, sondern der Ablauf dahinter – dazu der Beitrag zum Prozessmanagement im Mittelstand.

Bevor Unternehmen Software entwickeln lassen, sollten die wichtigsten Anforderungen ausreichend klar sein – ohne bereits jedes Detail der späteren Lösung festzuschreiben.

Bei der Vorbereitung entstehen zwei gegensätzliche Risiken: Unternehmen starten entweder mit zu wenig Klarheit oder versuchen, bereits vor Projektbeginn jedes Detail abschließend festzulegen.
Zu wenig bedeutet, mit einer groben Idee zu starten und Details während der Umsetzung zu klären. Das führt zu ständigen Rückfragen, wachsendem Umfang und Streit über das, was vereinbart war.

Eine sehr detaillierte Spezifikation kann ebenfalls zum Problem werden, wenn sie früh Annahmen festschreibt, die erst durch Prototypen, Nutzerfeedback oder technische Erkenntnisse belastbar bewertet werden können.

Der praktikable Weg liegt dazwischen:

• Ziele und Nutzen beschreiben – woran erkennen wir, dass es funktioniert hat?
• Die wichtigsten Abläufe von Anfang bis Ende festhalten, in der Sprache des Fachbereichs
• Abgrenzen, was ausdrücklich nicht dazugehört
• Schnittstellen benennen – welche Systeme müssen Daten austauschen?
• Randbedingungen klären: Datenschutz, Aufbewahrung, Anzahl Nutzer, Verfügbarkeit

Besonders hilfreich ist eine klare Abgrenzung dessen, was ausdrücklich nicht zum ersten Umfang gehört. Sie verhindert, dass unterschiedliche Erwartungen erst während der Umsetzung sichtbar werden.
Wie sich Anforderungen so fassen lassen, dass sie prüfbar bleiben, behandelt der Beitrag zum Requirements Engineering. Je nach Vorhaben kann es außerdem sinnvoll sein, zentrale Abläufe vor der Umsetzung in einem klickbaren Prototyp zu prüfen – siehe Prototyping.

1. Klärung: Problem, Ziele, Rahmenbedingungen, Beteiligte
2. Konzept: Abläufe, Schnittstellen, technische Grundentscheidungen
3. Entwurf: Skizzen oder klickbarer Prototyp, mit Anwendern geprüft
4. Umsetzung: in Abschnitten, mit regelmäßig vorzeigbaren Zwischenständen
5. Test und Abnahme: durch die Fachbereiche, nicht nur durch die IT
6. Einführung: Daten übernehmen, schulen, begleiten
7. Betrieb: Wartung, Fehlerbehebung, Weiterentwicklung

Der spätere Betrieb wird bei der frühen Projektplanung leicht unterschätzt. Mit der Einführung endet der Lebenszyklus einer Software jedoch nicht. Anforderungen verändern sich, Schnittstellen müssen angepasst werden und technische Komponenten benötigen Updates oder Wartung. Werden diese Aufgaben nicht von Beginn an berücksichtigt, können nach dem Go-live ungeklärte Zuständigkeiten für Support, Fehlerbehebung und Weiterentwicklung entstehen. Deshalb sollten Betrieb und Verantwortlichkeiten bereits während der Entwicklung vorbereitet werden.

Auch grundlegende technische Entscheidungen sollten früh genug getroffen und dokumentiert werden, weil spätere Änderungen an Architektur oder Schnittstellen erheblichen Aufwand verursachen können. Wie DIPS solche fachlichen und technischen Entscheidungen strukturiert vorbereitet, zeigt die Seite zum Lösungsdesign.

Die Kosten für individuelle Software lassen sich nicht allein aus der Art der Anwendung ableiten. Entscheidend sind vor allem fachlicher Umfang, Schnittstellen, Datenmigration, Sicherheits- und Qualitätsanforderungen, Zahl der Sonderfälle sowie Aufwand für Einführung und Betrieb. Eine belastbare Schätzung wird deshalb genauer, sobald diese Rahmenbedingungen geklärt sind.

Für den Angebotsvergleich ist deshalb nicht nur der Entwicklungspreis relevant, sondern der erwartete Gesamtaufwand über Einführung und Betrieb. Ein günstigeres Erstangebot kann langfristig teurer werden, wenn beispielsweise Migration, Dokumentation, Support oder laufende Wartung nicht enthalten sind.

Eine seriöse Schätzung ist erst möglich, wenn Umfang und Schnittstellen geklärt sind. Sehr frühe Kostenschätzungen können daher zunächst nur eine grobe Größenordnung liefern. Wichtig ist, transparent festzuhalten, auf welchen Annahmen eine Schätzung basiert und welche Unsicherheiten noch bestehen.

Typische Kostentreiber:

Der dritte Punkt verdient besondere Aufmerksamkeit. Fragen Sie sich bei jedem Sonderfall, ob er im System abgebildet werden muss oder organisatorisch gelöst werden kann. Bei selten auftretenden Sonderfällen sollte geprüft werden, ob eine technische Abbildung den zusätzlichen Entwicklungs- und Wartungsaufwand tatsächlich rechtfertigt oder ob eine organisatorische Lösung wirtschaftlicher ist.

Planen Sie zusätzlich einen Puffer für Unvorhergesehenes ein sowie ein Budget für den laufenden Betrieb nach der Einführung. Beides wird bei frühen Kostenschätzungen leicht unterschätzt.

Die DIPS GmbH unterstützt Unternehmen dabei, aus einem Geschäftsproblem ein belastbares Softwarevorhaben zu entwickeln. Je nach Ausgangslage reicht die Unterstützung von Prozessanalyse und Requirements Engineering über Lösungsdesign und Aufwandseinordnung bis zur Vorbereitung, Steuerung und Begleitung der Umsetzung. So entsteht nicht nur ein Angebot für Software, sondern eine nachvollziehbare Entscheidungsgrundlage für das gesamte Vorhaben.

Angebote sind selten direkt vergleichbar, weil sie unterschiedliche Annahmen treffen. Geben Sie deshalb allen Anbietern dieselbe Grundlage – dieselben Abläufe, dieselben Schnittstellen, dieselbe Mengenangabe.

Gerade Dokumentation, Übergabe und Betrieb sollten früh geklärt werden, weil sie die spätere Abhängigkeit vom Entwicklungspartner wesentlich beeinflussen können.
Klären Sie Quellcode, Dokumentation und Übergabe schriftlich, bevor Sie beauftragen – nicht, wenn die Zusammenarbeit endet.

Vorsicht ist angebracht, wenn für ein komplexes Vorhaben bereits ohne vertiefende Rückfragen ein verbindlicher Preis genannt wird. Ein belastbares Angebot sollte erkennen lassen, auf welchen Annahmen zu Umfang, Schnittstellen, Leistungen und Risiken die Kalkulation basiert.

Kein Vertragsmodell ist grundsätzlich das beste. Ein Festpreis kann bei klar abgegrenzten Leistungen hohe Planungssicherheit schaffen. Bei noch unsicherem Umfang kann dagegen ein flexibleres Modell sinnvoller sein, sofern Budget, Priorisierung und Fortschritt transparent gesteuert werden.
Die Abrechnung nach Aufwand ist flexibel, verlangt aber Steuerung. Ohne Priorisierung und regelmäßige Kontrolle wächst der Umfang unbemerkt.
Unabhängig vom Vertragsmodell sollten Nutzungs- und Weiterentwicklungsrechte, der Zugriff auf Quellcode und Repository, Dokumentationspflichten, der Umgang mit Änderungen, Gewährleistung, Reaktionszeiten sowie die Übergabe bei Vertragsende eindeutig geregelt werden.

Werden im Projekt personenbezogene Daten verarbeitet, sollte früh geklärt werden, welche datenschutzrechtlichen Rollen und Pflichten bestehen. Verarbeitet ein Dienstleister personenbezogene Daten im Auftrag des Unternehmens, ist insbesondere zu prüfen, ob eine Auftragsverarbeitung vorliegt und entsprechend vertraglich geregelt werden muss. Eine aktuelle Orientierung bietet die österreichische Datenschutzbehörde.

Wer Software entwickeln lassen möchte, sollte nicht mit der Programmierung beginnen, sondern mit einer belastbaren Entscheidung über Problem, Ziel und passenden Lösungsweg. Erst wenn geklärt ist, ob eine individuelle Lösung tatsächlich sinnvoll ist, folgen Anforderungen, Budget, Anbieterwahl und Umsetzung.

Besonders wichtig ist, den ersten Umfang bewusst zu begrenzen und Angebote auf derselben Grundlage zu vergleichen. Neben dem Entwicklungspreis gehören dabei auch Schnittstellen, Datenmigration, Qualitätssicherung, Einführung, Betrieb und spätere Weiterentwicklung in die Betrachtung.

Auch die Zusammenarbeit mit dem Entwicklungspartner sollte langfristig gedacht werden. Transparente Entscheidungswege, nachvollziehbare Dokumentation, geregelte Nutzungsrechte und ein geordneter Wissenstransfer reduzieren Abhängigkeiten und erleichtern spätere Veränderungen.

Ein gutes Softwareprojekt braucht mehr als eine technische Umsetzung. Bei DIPS fließen Geschäftsprozesse, Anforderungen, Nutzerbedürfnisse und technische Rahmenbedingungen in eine gemeinsame Entscheidungsgrundlage ein. Dadurch wird früh klar, welche Lösung sinnvoll ist, welcher Umfang realistisch bleibt und wie die Umsetzung strukturiert vorbereitet werden kann.

Individuelle Software lohnt sich vor allem dann, wenn Standardlösungen zentrale Anforderungen nicht ausreichend abdecken, besondere Prozesse gezielt unterstützt werden müssen oder mehrere Systeme miteinander verbunden werden sollen.

Standardsoftware ist meist sinnvoll, wenn Anforderungen weitgehend üblichen Marktstandards entsprechen und eine passende Lösung verfügbar ist. Individualsoftware bietet Vorteile, wenn geschäftskritische Abläufe, besondere Integrationen oder spezifische Anforderungen nicht sinnvoll mit Standardprodukten abgedeckt werden können. Häufig ist auch eine Kombination aus Standardsoftware und individueller Erweiterung sinnvoll.

Vor Projektstart sollten Ziele, zentrale Abläufe, Schnittstellen, Rahmenbedingungen und der erste Funktionsumfang ausreichend klar sein. Nicht jedes Detail muss bereits endgültig feststehen. Wichtig ist vor allem, offene Annahmen sichtbar zu machen und klar abzugrenzen, was zunächst nicht umgesetzt wird. Details können anschließend iterativ konkretisiert werden.

Die Kosten hängen vor allem von Funktionsumfang, Schnittstellen, Datenmigration, Sicherheits- und Qualitätsanforderungen, Sonderfällen sowie Einführung und Betrieb ab. Eine belastbare Schätzung ist deshalb erst möglich, wenn die wichtigsten Anforderungen und Rahmenbedingungen geklärt sind. Für den Vergleich sollten Unternehmen nicht nur Entwicklungskosten, sondern auch Betrieb und Weiterentwicklung berücksichtigen.

Ein geeigneter Softwareentwicklungspartner sollte das geschäftliche Problem verstehen, Annahmen transparent machen und nachvollziehbar erklären, wie das Vorhaben umgesetzt wird. Wichtig sind außerdem ein klar bekanntes Projektteam, passende Referenzen, klare Qualitäts- und Kommunikationsprozesse sowie Regelungen zu Dokumentation, Quellcode, Übergabe, Betrieb und möglichem Partnerwechsel.

Das passende Vertragsmodell hängt davon ab, wie klar der Projektumfang bereits feststeht. Ein Festpreis eignet sich eher für gut abgrenzbare Leistungen. Bei noch veränderlichen Anforderungen kann eine Abrechnung nach Aufwand oder ein festgelegter Budget- und Zeitrahmen mit priorisiertem Umfang sinnvoller sein. Entscheidend sind transparente Steuerung und klare Änderungsregeln.

Vor der Beauftragung sollte geregelt werden, welche Nutzungs- und Weiterentwicklungsrechte das Unternehmen erhält und wie der Zugriff auf Quellcode, Repository und technische Dokumentation erfolgt. Zusätzlich sollte geklärt werden, ob ein anderer Entwicklungspartner die Software später übernehmen darf. Die konkrete rechtliche Ausgestaltung sollte im Einzelfall fachlich geprüft werden.

Auch bei externer Entwicklung benötigt ein Softwareprojekt interne Kapazitäten. Fachbereiche und Verantwortliche müssen Anforderungen klären, Rückfragen beantworten, Entscheidungen treffen, Zwischenstände prüfen sowie Tests und Abnahmen durchführen. Wie hoch der Aufwand ist, hängt vom Projekt ab. Entscheidend ist, diese Zeit bereits bei der Projektplanung verbindlich einzuplanen.