Ausschreibung Software: Was in die Anfrage gehört

Eine Ausschreibung Software soll Anbietern nicht nur sagen, dass Sie eine Lösung suchen, sondern was genau in Ihre Anfrage oder Ausschreibung gehört. Dieser Beitrag zeigt Ihnen, welche Informationen wirklich wichtig sind, damit weniger Rückfragen entstehen, Angebote besser vergleichbar werden, Aufwandseinschätzungen realistischer ausfallen und Ihr Projekt sauber startet.

Er richtet sich an Geschäftsführer, IT-Leitung, Fachabteilungen und Projektverantwortliche in Unternehmen, öffentlichen Organisationen und Agenturen. Dabei passt er sowohl für formale Ausschreibungen als auch für pragmatische Dienstleisteranfragen. Wenn Sie Ihr Vorhaben parallel grob einordnen möchten, helfen der Kostenrechner für eine erste Spanne, der Projekt-Check aus Ihrer Beschreibung oder ein unverbindliches Erstgespräch.

Warum eine gute Software-Ausschreibung über den Projekterfolg mitentscheidet

Eine Software-Ausschreibung dient nicht nur dazu, einen Anbieter auszuwählen. Sie klärt vor allem, welches Ziel Sie verfolgen, welche Erwartungen intern bestehen und unter welchen Rahmenbedingungen das Vorhaben umgesetzt werden soll. Genau das entscheidet mit darüber, ob ein Projekt später geordnet startet oder schon in der Angebotsphase an Missverständnissen leidet.

Unklare Anfragen führen oft zu Angeboten, die sich kaum sinnvoll vergleichen lassen. Der eine Anbieter kalkuliert eine einfache Webanwendung, der nächste denkt an komplexe Schnittstellen, ein dritter plant bereits Tests, Dokumentation und spätere Erweiterbarkeit mit ein. Wenn die Ausgangslage unscharf bleibt, vergleicht man schnell unterschiedliche Annahmen statt echte Alternativen.

Wichtig ist dabei: Ihre Anfrage muss keine technische Feinspezifikation sein. Sie sollte fachlich verständlich und vollständig genug sein, damit eine erste belastbare Einschätzung möglich wird. Hilfreich ist die Unterscheidung zwischen:

• Ziel: Was soll sich verbessern?
• Lösungsidee: Wie könnte man das erreichen?
• Detailanforderung: Welche konkrete Funktion wird gebraucht?

Bei neuen Vorhaben stehen Ziele, Nutzer und Kernprozesse im Vordergrund. Bei Ablösungen sind Altdaten, bestehende Schwächen und Übergänge wichtig. Bei Erweiterungen zählen vor allem vorhandene Systeme, die Leistungen rund um Entwicklung und Betrieb sowie Abhängigkeiten. Stimmen Fachbereich, IT und Entscheidungsebene die Anfrage vor dem Versand gemeinsam ab, spart das meist viele Rückfragen, reduziert spätere technische Schulden und schafft eine bessere Grundlage für die weitere Planung.

Diese Inhalte gehören in jede Anfrage

Damit Anbieter Ihre Ausschreibung Software sinnvoll einordnen können, sollte Ihre Anfrage einige Kernpunkte klar benennen. Es geht nicht darum, schon alles bis ins Detail festzulegen. Wichtig ist, dass Ziel, Nutzung und Rahmenbedingungen verständlich werden.

Beginnen Sie mit Projektziel und Anlass. Beschreiben Sie, welches Problem gelöst werden soll, welcher Prozess heute bremst und ob eine bestehende Lösung ersetzt, erweitert oder ergänzt werden soll. Gerade bei Ablösungen helfen kurze Hinweise auf aktuelle Schwächen und gewünschte Verbesserungen. Praktische Beispiele finden Sie in Referenzprojekten und Kundenstimmen.

Ebenso wichtig sind Nutzergruppen und Nutzungssituation. Schreiben Sie, wer mit der Software arbeitet, in welchem Umfeld sie genutzt wird und auf welchen Endgeräten sie laufen soll. Mit Endgeräten sind zum Beispiel Desktop, Tablet oder Smartphone gemeint. Ob jemand im Büro, unterwegs oder an mehreren Standorten arbeitet, macht für Konzeption und Umsetzung oft einen Unterschied.

Definieren Sie den Funktionsumfang nach Prioritäten. Trennen Sie klar zwischen dem, was zwingend nötig ist, dem, was wünschenswert wäre, und dem, was später folgen kann. Wenn Punkte noch unklar sind, können Sie sie als offen kennzeichnen. In unsicheren frühen Phasen kann auch ein Software-Prototyp vor dem MVP sinnvoll sein.

Beschreiben Sie außerdem wichtige Abläufe. Dazu gehören typische Anwendungsfälle, Freigaben, Prüfungen, Suche, Auswertungen oder Benachrichtigungen. Solche Prozessbeschreibungen sind oft hilfreicher als lange Listen einzelner Funktionen.

Nennen Sie vorhandene Systeme und Schnittstellen, etwa ERP, CRM, Microsoft 365 oder andere Fachverfahren. Schnittstellen sind Verbindungen zwischen Systemen zum Datenaustausch. Ergänzen Sie, welche Daten und Dokumente bereits vorliegen, übernommen werden müssen oder neu entstehen.

Hinzu kommen Benutzerverwaltung und Zugriffe: Rollen, Rechte, Standorte sowie interne und externe Nutzer. Entra ID ist ein Microsoft-Dienst für Anmeldung und Zugriffsverwaltung. Halten Sie außerdem Ihre Anforderungen an Betrieb und Umgebung fest, also Cloud, interne Infrastruktur oder eine Mischform. Microsoft Azure ist eine Cloud-Plattform für Betrieb, Sicherheit und Skalierung.

Hilfreich sind auch Hinweise zu technischer Dokumentation und geplanten Softwaretests im Projekt, selbst wenn diese zu Beginn nur grob beschrieben werden.

So formulieren Sie Anforderungen klar und vergleichbar

Formulieren Sie Anforderungen möglichst aus Sicht der Praxis. Eine einfache Struktur hilft: Wer möchte was tun – und welches Ergebnis wird erwartet? So wird aus einer vagen Idee eine nachvollziehbare Anforderung, die Anbieter fachlich einordnen können.

Unklare Begriffe wie „modern“, „intuitiv“ oder „flexibel“ sind in Anfragen problematisch, wenn sie nicht erläutert werden. Besser ist, Sie machen Ihre Erwartung konkret, zum Beispiel durch typische Arbeitsschritte, gewünschte Reaktionszeiten im Alltag oder klare Beispiele dafür, was Nutzer ohne Umwege erledigen sollen.

Wichtig ist außerdem die Trennung von Muss- und Kann-Anforderungen. Nur so bleibt erkennbar, was zwingend zum Projektstart gehört und was erst später sinnvoll sein kann. Andernfalls entstehen leicht Angebote, die an unterschiedlichen Prioritäten vorbeigehen.

Ebenso hilfreich: Markieren Sie offene Punkte ausdrücklich als offen. Das ist besser, als Lücken zu verstecken oder unausgesprochene Annahmen dem Anbieter zu überlassen. Sichtbar werden sollten auch Ihre eigenen Annahmen, etwa zu:

• Zahl der Nutzer
• erwarteter Datenmenge
• benötigten Rollen und Rechten
• internen und externen Zugängen

Ein Lastenheft beschreibt die Anforderungen aus Auftraggebersicht. Die konkrete Umsetzung kann anschließend gemeinsam präzisiert werden. Wenn Ihr Vorhaben noch mit vielen Unsicherheiten verbunden ist, kann vor dem eigentlichen Projekt ein Prototyp sinnvoll sein. Grundsätzlich gilt: Verständliche Sprache ist meist wertvoller als technische Fachsprache, besonders wenn Entscheider und Fachbereiche mitlesen.

Wie Anbieter Ihre Ausschreibung lesen und bewerten

Anbieter lesen eine Ausschreibung nicht nur danach, was gebaut werden soll. Sie prüfen vor allem, ob Zielbild, Umfang, Risiken und Abhängigkeiten erkennbar sind. Je klarer diese Punkte beschrieben sind, desto besser lässt sich einschätzen, welche Lösung sinnvoll sein kann und wo noch Klärungsbedarf besteht.

Rückfragen entstehen meist dort, wo zentrale Punkte nur angerissen sind, zum Beispiel bei Prozessen, Rollen oder Schnittstellen. Wenn etwa steht, dass Daten „mit anderen Systemen ausgetauscht“ werden sollen, aber unklar bleibt, mit welchen Systemen, in welchem Umfang und wie häufig, wird aus einer scheinbar kleinen Anforderung schnell ein offener Komplex.

Gute Angebote enthalten deshalb oft nicht nur Leistungen, sondern auch:

• Annahmen
• Abgrenzungen
• offene Punkte
• erkennbare Risiken

Das hilft beiden Seiten, vom gleichen Leistungsbild auszugehen.

Ein weiterer Bewertungspunkt ist die Nachhaltigkeit der Entwicklung. Entscheidend ist nicht nur der erste Funktionsumfang, sondern auch, wie gut sich die Software warten, testen und weiterentwickeln lässt. Clean Code Development ist eine Vorgehensweise, die auf gut verständlichen, wartbaren und langfristig veränderbaren Code zielt.

Ähnlich klingende Vorhaben können sehr unterschiedlich aufwendig sein: Ein CRM mit wenigen Rollen ist anders zu bewerten als eine kommunale Webplattform mit Fachdaten und Freigaben oder eine Erweiterung mit Anbindung an Azure DevOps. Azure DevOps ist eine Plattform für Planung, Versionsverwaltung, automatisierte Tests und Auslieferung.

Typische Lücken in Ausschreibungen und wie Sie sie vermeiden

Viele Anfragen scheitern nicht an zu wenig Text, sondern an fehlenden Schwerpunkten. Wenn nicht klar ist, ob vor allem Tempo, bessere Prozessqualität, saubere Integration, Reporting oder die Ablösung einer bestehenden Lösung im Vordergrund steht, setzen Anbieter unterschiedliche Prioritäten an.

Häufig werden auch Altsysteme unterschätzt. Bestehende Daten, Ausnahmen, manuelle Umwege und gewachsene Prozesse sollten Sie nicht nur knapp erwähnen, sondern so beschreiben, dass ihr Einfluss auf das Vorhaben erkennbar wird.

Oft offen bleiben außerdem Betriebsfragen:

• Wer betreibt die Lösung später?
• Wer pflegt Inhalte?
• Wer verwaltet Benutzer und Rechte?

Ein weiterer häufiger Punkt ist die zu frühe Festlegung auf Technik. Beschreiben Sie zuerst die fachlichen Ziele. Technische Begriffe sollten Sie nur dort nutzen, wo sie für Rahmenbedingungen wirklich relevant sind.

Vergessen werden außerdem Dokumentation, Tests und spätere Änderbarkeit. Technische Dokumentation ist die Unterlage, die Aufbau, Entscheidungen und Betrieb nachvollziehbar macht. Softwaretests sind geplante Prüfungen, die Fehler früh sichtbar machen. Technische Schulden sind Folgen kurzfristiger Entscheidungen, die spätere Anpassungen erschweren.