Software-Ausschreibungen bewerten: Funktions-Fit und Anpassungsaufwand

Warum die Go/No-Go-Entscheidung über Ihre Zukunft bestimmt

Warum tappen viele IT-Dienstleister in die Falle, auf jede halbwegs passende Ausschreibung zu bieten? Seien wir ehrlich: „Wir sind doch Experten, das kriegen wir schon hin“, ist ein gefährlicher Glaubenssatz. Wie der Chaos Report der Standish Group berichtet, können seit Jahren nur etwa ein Drittel aller Softwareprojekte als voller Erfolg gewertet werden. Der Rest kämpft mit massiven Problemen oder scheitert komplett.

Wie hilft eine disziplinierte Bewertung der Ausschreibungsunterlagen (Vergabeunterlagen) dabei? Sie ist kein bürokratischer Akt, sondern strategischer Selbstschutz. Wenn Sie darüber nachdenken, wird klar: Jede Stunde, die Sie in ein „totes Pferd“ investieren - sei es in der Angebotsphase oder später im Projekt - fehlt Ihnen für lukrative Aufträge. Besonders im deutschen Markt ist dies kritisch. Bitkom meldet hierzu, dass 149.000 IT-Stellen unbesetzt sind, weshalb die Verschwendung von Entwicklerressourcen für schlecht kalkulierte Projekte doppelt schmerzhaft ist. Informieren Sie sich über unser Pricing, um solche teuren Fehlentscheidungen kosteneffizient zu vermeiden.

Was sind die Grundlagen für eine fundierte Entscheidung zur Bewertung von Software-Ausschreibungen? Sie basiert nicht auf Bauchgefühl, sondern auf harten Fakten. Untersuchungen des Project Management Institute (PMI) zeigen immer wieder, dass effektives Risikomanagement essenziell für den Projekterfolg ist. Sie müssen lernen, „Nein“ zu sagen, wenn das Risiko-Nutzen-Verhältnis nicht stimmt. Das schützt nicht nur Ihre Bilanz, sondern auch die Motivation Ihres Teams.

Feature-Fit-Analyse: Standard vs. Realität

Der erste Schritt jeder Bewertung ist der Abgleich des Leistungsverzeichnisses (Lastenheft) mit Ihrer Standardlösung. Wie Forrester Research berichtet, scheitern viele Projekte bereits in dieser Phase an mangelnder Präzision. Hierbei geht es nicht nur um „Ja“ oder „Nein“, sondern um den Grad der Abdeckung. Wenn Sie die Anforderungen prüfen, ist ein häufiger Fehler die Annahme, dass ein Feature „im Prinzip“ vorhanden ist, obwohl die spezifischen Anforderungen der Behörde oder des Enterprise-Kunden eine völlig andere Ausprägung verlangen.

Wie können Sie dabei methodisch vorgehen? Erstellen Sie eine Fit-Gap-Matrix mit drei Kategorien:

• Standard (Out-of-the-Box): Die Anforderung wird zu 100 % durch die bestehende Software abgedeckt. Kein Entwicklungsaufwand.
• Konfiguration (Low-Code/No-Code): Die Anforderung kann durch Einstellungen, Workflows oder Parameteranpassungen erfüllt werden. Aufwand: Gering bis Mittel.
• Erweiterung (Custom Code): Hier muss programmiert werden. Das ist der kritische Bereich für Ihre Kalkulation.

Gartner-Analysten warnen regelmäßig davor, dass zu viele Anpassungen die Upgrade-Fähigkeit einer Software zerstören. Das ist ein entscheidender Punkt: Wenn Sie bei einer Ausschreibung feststellen, dass mehr als 20-30 % der Anforderungen in die Kategorie „Custom Code“ fallen, sollten bei Ihnen alle Alarmglocken schrillen. In diesem Fall verkaufen Sie keine Software mehr, sondern ein Individualentwicklungsprojekt zum Festpreis - eines der riskantesten Geschäftsmodelle überhaupt.

Warum ist eine detaillierte Analyse der „Muss-Kriterien“ so wichtig? Oft verbergen sich hinter unscheinbaren Sätzen wie „Das System muss sich nahtlos in die bestehende Archivlandschaft integrieren“ komplexe Schnittstellenprojekte. Laut der Standish Group sprengen solche versteckten Anforderungen häufig den Kostenrahmen.

Der Eisberg der Anpassungskosten: Warum wir uns immer verschätzen

Warum liegen wir bei der Schätzung von Anpassungsaufwänden so oft daneben? Die Antwort liegt im Eisberg-Effekt. Laut McKinsey-Daten sehen wir meist nur die reine Entwicklungszeit, während die wahren Kostentreiber wie Testing und Dokumentation unter der Oberfläche liegen. Wenn Sie eine Software-Ausschreibung bewerten, müssen Sie diesen „Anpassungs-Multiplikator“ kennen.

Doch was sind die versteckten Aufwände, die Sie beachten müssen? Schauen wir uns den Eisberg genauer an. Für jeden Tag reine Entwicklung (Coding) fallen in einem professionellen B2B- oder GovTech-Kontext weitere Kosten an:

• Anforderungsanalyse & Spezifikation (20 bis 30 %): Bevor eine Zeile Code geschrieben wird, müssen Sie genau klären, was „barrierefrei nach BITV 2.0“ bedeutet. Nach Standards des IEEE ist die Behebung von Fehlern in dieser Phase bis zu 100-mal günstiger als nach dem Release.
• Test & Qualitätssicherung (30 bis 40 %): Individualanpassungen sind fehleranfälliger als Standardcode. Sie benötigen umfangreiche Unit-Tests und Abnahmetests. Der Chaos Report identifiziert mangelndes Testing als einen der Hauptgründe für Projektverzögerungen.
• Dokumentation (15 bis 25 %): Besonders im öffentlichen Sektor sind die Dokumentationspflichten enorm. Eine Anpassung ist erst fertig, wenn sie im Benutzerhandbuch eingepflegt ist.
• Projektmanagement & Kommunikation (15 bis 20 %): Jede Abweichung vom Standard erfordert Abstimmung. Je mehr Customizing, desto höher der Kommunikationsbedarf.

Hier ist ein Rechenbeispiel für Sie: Sie schätzen ein Feature auf 5 Personentage Entwicklung. Mit dem „Eisberg-Faktor“ landen Sie real eher bei 10 bis 12 Tagen Gesamtaufwand. Wenn Sie diesen Faktor ignorieren, arbeiten Sie ab der Projektmitte umsonst.

Ein weiterer Punkt ist die „Last 10% Trap“. Experten des Bitkom weisen darauf hin, dass die letzten 10 % der Anpassungen oft 50 % des Aufwands verursachen. Sie werden sehen, dass dies oft die speziellen Sonderlocken sind, die im ersten Überfliegen harmlos aussahen.

Wie wirkt sich technische Schuld auf Ihr Budget aus? Jede Zeile Custom-Code muss über Jahre gewartet werden. Forschungen von Capers Jones zeigen, dass die langfristigen Wartungskosten oft den initialen Entwicklungspreis übersteigen. Zudem prognostiziert Gartner, dass Unternehmen bis 2025 bis zu 40 % ihres IT-Budgets nur für die Beseitigung technischer Schulden aufwenden müssen.

Wenn Sie eine Software-Ausschreibung bewerten, fragen Sie sich immer: Ist diese Anpassung ein einmaliger Aufwand oder eine lebenslange Hypothek? Im Zweifel sollten Sie den Preis für Individualanpassungen drastisch erhöhen - oder den Mut haben, „No-Go“ zu sagen.

Integrationsrisiken und EVB-IT Fallstricke

Warum scheitert die Integration oft? Neben dem reinen Code ist die Einbindung in die bestehende Landschaft des Kunden der zweite große Risikofaktor. In deutschen Behörden und Großunternehmen treffen Sie oft auf historisch gewachsene Heterogenität. Laut den offiziellen Richtlinien für die EVB-IT Systemverträge ist häufig eine Gesamtabnahme vorgesehen. Das bedeutet für Sie: Auch wenn Ihre Software perfekt läuft und die Schnittstelle zum 20 Jahre alten Archivsystem des Kunden hakt, bekommen Sie kein Geld.

Wie können Sie dieses Risiko minimieren? Bewerten Sie Schnittstellen-Anforderungen extrem konservativ. Wenn Sie die technische Basis analysieren, sollten Sie folgende Punkte prüfen:

• Gibt es eine saubere API-Dokumentation?
• Ist das Drittsystem überhaupt noch wartbar?

Das ist ein entscheidender Punkt: Wenn im Leistungsverzeichnis steht „Anbindung an Fachverfahren XY“, müssen Sie zwingend klären, wer für die Gegenseite verantwortlich ist. Ohne diese Klarheit ist das Risiko unkalkulierbar.

Was ist beim Haftungsrisiko zu beachten? Bei Individualentwicklungen im Rahmen von Werkverträgen haften Sie für den Erfolg. Rechtsexperten des Bitkom berichten, dass die Unterscheidung zwischen Werk- und Dienstvertrag essenziell ist, und raten dazu, genau zu prüfen, ob ein EVB-IT Erstellungsvertrag zugrunde liegt. Bei Werkverträgen mit hohem Anpassungsanteil kann eine einzige gescheiterte Abnahme die Existenz kleinerer IT-Dienstleister gefährden.

Das 5-Schritte-Framework zur Bewertung von Software-Ausschreibungen

Was ist der sicherste Weg zur erfolgreichen Angebotserstellung? Um aus dem Bauchgefühl eine belastbare Strategie zu machen, empfehlen wir ein strukturiertes Vorgehen. Nach Angaben von Forrester Research erhöht eine objektive Vorqualifizierung die Effizienz im Vertrieb erheblich. Nutzen Sie dieses Framework, um jede Ausschreibung objektiv zu durchleuchten, bevor Sie Ressourcen investieren.

Schritt 1: Der K.O.-Check (Die harten Fakten)

Warum ist dieser erste Schritt so entscheidend? Bevor Sie das Lastenheft lesen, prüfen Sie die formalen Rahmenbedingungen. Vergabeplattformen sind voll von Ausschreibungen, die Sie gar nicht gewinnen können. Prüfen Sie:

• Eignungskriterien: Haben Sie die geforderten Referenzen in vergleichbarer Größe? (Oft werden 3 Referenzen der letzten 3 Jahre gefordert).
• Zertifizierungen: Werden ISO 27001 oder BSI C5 zwingend verlangt?
• Vertragsbedingungen: Sind die Pönalen (Vertragsstrafen) bei Verzug akzeptabel?

Wenn hier ein „Nein“ steht: Sofortiger Abbruch. Keine Diskussion.

Schritt 2: Die Fit-Gap-Analyse (Der technische Kern)

Wie können Sie den Aufwand realistisch einschätzen? Gehen Sie das Leistungsverzeichnis Position für Position durch. Hier ist eine einfache Ampel-Logik, die Sie nutzen können:

• Grün: Standard-Feature (0 Tage Aufwand)
• Gelb: Konfiguration / Leichtes Customizing (< 2 Tage Aufwand)
• Rot: Individualentwicklung / Komplexes Customizing (> 2 Tage Aufwand)

Zählen Sie die roten Positionen. Erfahrungswerte von McKinsey und anderen Beratungen zeigen: Wenn mehr als 15 bis 20 % der Anforderungen „Rot“ sind, verlässt das Projekt den Bereich der Standardsoftware-Einführung und wird zum Risikoprojekt.

Schritt 3: Die Risiko-Bewertung (Das „Was wäre wenn“)

Wie funktioniert eine präzise Risiko-Bewertung? Bewerten Sie die identifizierten „roten“ Anforderungen auf ihr Risiko. Berichte der Standish Group zeigen immer wieder, dass unterschätzte Komplexität der Hauptgrund für das Scheitern von IT-Projekten ist. Nicht jeder Entwicklungstag ist gleich riskant. Ein neues Reporting-Dashboard zu programmieren ist risikoarm. Eine tiefe Integration in ein unbekanntes SAP-Modul ist hochriskant. Nutzen Sie Faktoren:

• Faktor 1.0: Bekannte Technologie, klare Anforderung
• Faktor 1.5: Neue Technologie oder unklare Anforderung
• Faktor 2.5: Neue Technologie und unklare Anforderung (Fremdsysteme)

Multiplizieren Sie Ihre Aufwandsschätzung mit diesen Faktoren. Das ist Ihr „Risiko-Puffer“.

Schritt 4: Der Ressourcen-Check (Die Machbarkeit)

Selbst wenn das Projekt profitabel wäre: Haben Sie die Leute? Wenn Sie Ihre Ressourcen planen, bedenken Sie: Laut Bitkom ist Entwicklerzeit angesichts des Fachkräftemangels Ihr knappstes Gut. Blockiert dieses Projekt Ihre besten Senior-Entwickler für Monate? Was ist mit den Opportunitätskosten? Könnten diese Entwickler in der gleichen Zeit ein neues Produkt-Feature bauen, das Sie an 100 Kunden verkaufen können, statt eine Individualanpassung für einen einzigen Kunden?

Schritt 5: Die kaufmännische Bewertung (Die Marge)

Wann sollten Sie ein Projekt ablehnen? Rechnen Sie ehrlich. Nehmen Sie die risikoadjustierten Aufwände aus Schritt 3. Addieren Sie Projektmanagement, Testing und Dokumentation (den „Eisberg“). Stellen Sie dem den erwarteten Umsatz gegenüber. Laut Harvard Business Review ist die strikte Berücksichtigung von Opportunitätskosten essenziell für langfristiges Wachstum. Ist die Marge noch zweistellig? Wenn nicht: Haben Sie einen strategischen Grund (z.B. Markteintritt, Leuchtturm-Referenz), das Projekt trotzdem zu machen? Wenn nein: No-Go.

Dieses Framework schützt Sie vor der „Sunk Cost Fallacy“. Es ist besser, nach zwei Tagen Analyse „Nein“ zu sagen, als nach zwei Jahren Projektlaufzeit draufzuzahlen. Tools wie BidFix können Sie hierbei unterstützen, indem sie Ausschreibungsunterlagen KI-gestützt scannen und kritische Passagen sowie Aufwandstreiber automatisch hervorheben.

Wartungsmodelle und TCO: Denken Sie über den Tag 1 hinaus

Warum ist das Wartungsmodell so wichtig? Hier ist der Grund, warum es bei der Entscheidung oft übersehen wird. Laut dem CIO Bund vereinbaren öffentliche Auftraggeber oft einen Festpreis für die Erstellung und eine Pauschale für die Pflege (EVB-IT Pflege S). Wie wirkt sich das auf Ihre Verpflichtungen aus? Die EVB-IT Pflegebedingungen sind streng: Sie müssen die Funktionsfähigkeit der Software über Jahre garantieren - inklusive aller individuellen Anpassungen.

Was sind die langfristigen Folgen? Wenn Sie für eine Ausschreibung tief in den Core-Code eingreifen müssen, schaffen Sie sich einen „Fork“. Software-Experten warnen, dass Sie diesen separat warten müssen, was Ihre internen Kosten massiv in die Höhe treibt. Lassen Sie uns das klarstellen: Kalkulieren Sie diese langfristigen Kosten unbedingt ein. Ein gewonnener Auftrag, der Ihre Produkt-Roadmap durch Wartungsaufwand lähmt, lohnt sich am Ende nicht.