Artikel4 Min. Lesezeit

Erst erkunden, dann beauftragen

Warum Mittelstands-Softwareprojekte in der Spezifikationsphase scheitern und was ein strukturiertes Discovery-Projekt daran ändert.

Ein Maschinenbauer mit rund 250 Mitarbeitern hat vier Monate an einem Lastenheft gearbeitet. Ein externes Beratungsunternehmen half dabei. Die Spezifikation war gründlich, die Ausschreibung klar. Eine Agentur bot 340.000 Euro Festpreis. Der Vertrag wurde unterschrieben.

Achtzehn Monate später lief das Projekt rund 60 Prozent über Budget. Die ERP-Anbindung funktionierte nicht. Das Lastenheft hatte ein Datenexportformat vorausgesetzt, das das Produktivsystem in dieser Form nie geliefert hat. Agentur und Auftraggeber stritten über Scope. Das Lastenheft war nicht nachlässig. Das Problem hatte keine schuldige Seite. Es hatte die falsche Vertragsform.

Das Pflichtenheft-Paradoxon

Klassische Beschaffung geht davon aus, dass Software vor Baubeginn vollständig spezifizierbar ist. Bei physischen Gütern mit bekannten Toleranzen funktioniert das. Bei Software, die echte Integrationen, undokumentierte Abläufe oder unklare Prozessverantwortung berührt, bricht diese Annahme.

Wer einen Werkvertrag über ein exploratives Vorhaben schreibt, zwingt Unsicherheit in einen Festpreis. Anbieter unterbieten, um den Auftrag zu gewinnen, und holen die Differenz später über Change Requests zurück. In Projektpostmortems und Studien wie den CHAOS-Berichten der Standish Group taucht seit Jahren dasselbe Muster auf: Vorhaben ohne strukturierte Erkundungsphase laufen häufig weit über Plan, oft im Bereich von 50 Prozent und mehr. Mit einer echten Discovery-Phase liegen typische Abweichungen deutlich niedriger, oft eher bei 10 bis 20 Prozent.

53 Prozent der Unternehmen sehen in der Steuerung von Digitalisierungsprojekten eine wesentliche Herausforderung.

Bitkom, Digitalisierung der Wirtschaft

Der Bitkom-Befund beschreibt keine Randgruppe. Die Planungslücke ist strukturell. Im Mittelstand kommt hinzu, dass ein gescheitertes Großprojekt selten einfach abgeschrieben werden kann.

Was Discovery hier konkret bedeutet

Bei Partial Labs ist ein Discovery-Prototyp kein Klickprototyp in Figma und keine Folienpräsentation. Es ist ein vertikaler Schnitt: ein repräsentativer Ablauf, durchgängig umgesetzt, mit echten Datenquellen, echter Authentifizierung und echten Geschäftsregeln. Der Output ist eine schmale, aber lauffähige Software sowie eine belastbare Schätzung für den Produktionsauftrag.

  • UX-Prototypen prüfen Oberflächenannahmen. Discovery prüft technische und organisatorische Realität.
  • Typische Dauer: drei bis sechs Wochen, zeitlich begrenzt und mit klaren Deliverables.
  • Häufige Funde: Integrationsgrenzen, die in der Dokumentation fehlen, Prozessschritte, die niemand aufgeschrieben hat, und Datenqualität, die erst bei echter Nutzung sichtbar wird.
  • Output: lauffähiger Schnitt plus Scoping-Bericht mit überarbeitetem Aufwand und benannten Risiken.

Das Vertragsmodell

Phase eins, Discovery, ist ein Festpreis mit klaren Deliverables und Abnahmekriterien. Diese Phase kann als Werkvertrag stehen, weil Ergebnis und Umfang spezifizierbar sind. Phase zwei, Produktion, folgt erst, wenn Scope und Risiken bekannt sind. Entweder als frischer Werkvertrag oder als Rahmenvertrag mit einzelnen Statements of Work.

Rahmenvertrag plus SoW ist in der Unternehmens-IT Standard. Der Rahmen regelt IP, Haftung, Vertraulichkeit und Zahlungsbedingungen. Jedes SoW definiert Deliverables, Zeitplan und Preis. Für den Mittelstand ist das kein exotisches Konstrukt, sondern die saubere Antwort auf explorative Unsicherheit.

Vendor Lock-in bleibt ein reales Thema. In Bitkom-Erhebungen nennen mehr als die Hälfte der befragten Unternehmen Abhängigkeit von Anbietern als Beschaffungsrisiko. Gegenmittel in Phase eins: klare IP-Übergabe, dokumentierte Architektur und keine proprietäre Toolchain, die den Wechsel unmöglich macht.

Reibung im Einkauf

Die Hürden vor dem Start sind meist administrativ. Sie verschwinden nicht, aber sie sind planbar.

  • NDA und Datenzugang: Discovery braucht früh echten Systemzugriff. NDA und Datenverarbeitungsregeln gehören in den Kickoff, nicht in Woche vier.
  • IT-Sicherheit: Im Mittelstand oft eine Person mit langer Warteschlange. Zwei bis drei Wochen für Erstzugriff einkalkulieren.
  • Budgetschwellen: Ein Discovery-Auftrag im niedrigen fünfstelligen Bereich liegt häufig unter Ausschreibungsgrenzen und lässt sich als Vorbereitungskosten denken.

Wann Discovery das falsche Werkzeug ist

Nicht jedes Vorhaben braucht eine Erkundungsphase. Discovery kostet Zeit und Geld und muss neue Information erzeugen.

  • Austausch eines gut dokumentierten Altsystems gegen eine bekannte Standardlösung: Scope ist bereits klar.
  • Harte regulatorische oder vertragliche Fristen, die keinen drei- bis sechswöchigen Vorlauf erlauben.
  • Internes Tooling mit einem Product Owner, der jede Integration und jede Datenquelle verifiziert kennt.
  • Rein organisatorische Blockaden: Wenn Geschäftsbereiche nicht einig sind, was das System tun soll, löst kein Sprint den Konflikt.

Aus der Praxis

Ein Logistikdienstleister mit etwa 180 Mitarbeitern wollte Order-to-Invoice-Matching zwischen WMS und ERP automatisieren. Discovery lief vier Wochen zum Festpreis von rund 18.000 Euro, mit einer Entwicklerin und einem Business Analyst. Ergebnis: Das WMS exportierte je nach Kundenkonfiguration unterschiedliche Formate. Das "Standardformat" aus dem ursprünglichen Lastenheft galt nur für etwa 40 Prozent der realen Fälle.

Ohne Discovery wäre der Produktionsauftrag von Tag eins an für die Mehrheit der Anwendungsfälle falsch spezifiziert gewesen. Mit Discovery lieferte die Produktion in 14 Wochen gegen eine ursprüngliche Schätzung von 22 Wochen. Die Budgetabweichung lag unter acht Prozent. Das Beispiel ist anonymisiert und zusammengesetzt aus typischen Mustern; die Größenordnungen sind realistisch.

Warum das gerade jetzt zählt

KI-Integrationen, etwa dokumentbasierte Extraktion oder Workflow-Automatisierung, hängen vom Verhalten realer Daten ab. Man spezifiziert ein KI-Feature nicht zuverlässig, bevor man Kandidatenmodelle an echten Eingaben gesehen hat. Das gilt für jede Software, die gewachsene, nie aufgeschriebene Prozesse abbilden muss. KI erhöht schlicht den Preis dafür, diese Lücke zu ignorieren.

  • Viele Mittelstandsunternehmen stehen unter Druck, "etwas mit KI" zu tun, ohne interne technische Definition.
  • Discovery zwingt vage Aufträge auf ein prüfbares Ziel: Läuft dieser Ablauf mit diesen Daten?
  • Je unklarer das Vorhaben, desto wertvoller ist eine zeitlich begrenzte Erkundung vor dem Hauptvertrag.

Wer die Kostenstruktur kennt, kann Discovery als eigene Budgetlinie rechtfertigen: als Preisfindung vor dem Hauptauftrag, nicht als nachträgliche Absicherung.

KONTAKT

Lassen Sie uns über Ihr System sprechen.

Dreißig Minuten mit unserem Team. Ohne Präsentation und ohne Pitch sprechen wir direkt über den Prozess, den Sie verbessern möchten.

alex@partiallabs.com