Die meisten Verteidigungstechnologie-Startups, die kommerziell scheitern, tun dies nicht, weil ihr Produkt aufgehört hat zu funktionieren. Sie scheitern, weil die Distanz zwischen einem erfolgreichen Pilotprojekt und einem finanzierten Program of Record (POR) länger, bürokratisch komplexer und abhängiger von Beziehungen ist, als jede Produkt-Roadmap antizipiert. Die Mechanismen des Gewinns des ersten Regierungsauftrags sind gut dokumentiert. Was weit weniger Beachtung findet, ist die schwierigere Phase, die folgt: die Umwandlung einer einmaligen Pilotprojektzahlung in eine nachhaltige Budgetlinie, die ein wachstumsstarkes Unternehmen unterstützen kann. Dieser Artikel verfolgt den vollständigen Beschaffungszyklus -- vom Pilotdesign über den OTA-Prototyp, die Sicherheitszertifizierung, die Pflege von Programm-Fürsprechern, Koalitionsüberlegungen bis hin zu den strukturellen Übergangsrisiken, die Programme beenden, bevor sie operative Skalierung erreichen.
Das Tal des Todes: warum gute Technologie zwischen Pilot und Vertrag ins Stocken gerät
Das Tal des Todes ist keine Metapher über Produktqualität. Es ist eine strukturelle Finanzierungslücke, die durch eine Diskrepanz zwischen der Geschwindigkeit der Technologiedemonstration und der Geschwindigkeit der Verteidigungshaushaltzyklen entsteht. Ein Unternehmen kann ein Pilotprojekt in 90 Tagen abschließen. Das Programmbüro kann bestätigen, dass es funktioniert hat. Aber das Programmbüro kann keine neuen Mittel für eine Fähigkeit bereitstellen, die es gerade entdeckt hat -- nicht bis diese Fähigkeit den Program Objective Memorandum (POM)-Prozess überlebt hat, der in einem 18-Monats-Zyklus läuft und dokumentierte Anforderungen, Kostenschätzungen und Risikobewertungen erfordert, die für eine Technologie, die das Programm gerade bewertet hat, nicht existieren.
Während dieses Intervalls wird von dem Startup erwartet, das Produkt weiterzuentwickeln, ein ausgebildetes Team zu unterhalten, die Bewertungsdokumentation der Regierung zu unterstützen und mit dem zahlungsfähig zu bleiben, was es an Phase-II-SBIR-, Überbrückungsvertrags- oder OTA-Folgefinanzierungen sichern kann. Die mittlere Dauer dieser Lücke -- zwischen dem Ende eines erfolgreichen Pilotprojekts und der ersten Verpflichtung im Rahmen eines neuen Programmhaushalts -- beträgt 18 bis 36 Monate für ein Softwareprodukt ohne vorherige DoD-Beschaffungsgeschichte. Unternehmen, die für eine 6-monatige Lücke planen und im Monat 14 die Liquidität verlieren, bekommen in den meisten Programmbüros keine zweiten Chancen; der Fürsprecher wechselt, und die Technologie wird vom nächsten Programmmanager von Null an neu bewertet.
Die praktische Konsequenz ist, dass das Pilotdesign das Tal berücksichtigen muss, bevor der Pilot beginnt. Ein Pilot, der so strukturiert ist, dass er die spezifische Dokumentation erzeugt -- Fähigkeitslückenanalyse, operative Effektivitätsdaten, Integrationsarchitektur, Kosten-pro-Einheit-Projektion -- die ein Programmmanager benötigt, um eine POM-Vorlage zu erstellen, übersteht die Übergangsphase mit höheren Raten als ein Pilot, der ausschließlich zur Demonstration technischer Leistung konzipiert ist. Technische Leistung ist Mindestvoraussetzung. Administrative Lesbarkeit für den Haushaltsprozess ist das, was das Tal überquert.
OTA-Vereinbarungen, SBIRs und DIU-Wege -- wie sie sich unterscheiden
Drei Vertragsinstrumente dominieren das frühe Engagement von Verteidigungsstartups: Other Transaction Authority (OTA)-Prototypvereinbarungen, Small Business Innovation Research (SBIR)-Vergaben und der Defense Innovation Unit (DIU) Commercial Solutions Opening (CSO)-Prozess. Sie sind nicht austauschbar, und die Wahl des falschen Fahrzeugs für den falschen Moment im Beschaffungslebenszyklus verursacht Verzögerungen, die schwer zu korrigieren sind.
OTA-Prototypvereinbarungen nach 10 USC 4022 sind der schnellste Weg von einer finanzierten Anforderung zu einem bewerteten Prototyp für ein Startup ohne staatliche Buchhaltungssysteme. Sie liegen außerhalb der Federal Acquisition Regulation, was bedeutet, dass ein Programmbüro eine OTA an ein Unternehmen vergeben kann, das noch nie einen DoD-Vertrag gehalten hat, keine Defense Contract Audit Agency (DCAA)-genehmigten Buchhaltungssysteme hat und keine zertifizierten Kosten- oder Preisdaten vorlegen kann. Der Kompromiss liegt im Umfang: OTA-Vergaben sind gesetzlich auf Prototypenaktivitäten beschränkt. Ein Übergang zur vollständigen Produktion erfordert entweder eine wettbewerbsbasierte FAR-Folgebeschaffung oder eine Direktvergabe nach der Übergangsprovision des OTA-Statuts -- und diese Direktvergabe ist nicht automatisch. Sie erfordert, dass das Programmbüro eine schriftliche Feststellung trifft, dass der Prototyp wettbewerbsorientiert vergeben wurde und dass die Produktionsfolgebeschaffung eine logische Erweiterung ist. Programmbüros, die diesen Übergang nicht vorab geplant haben, verlieren oft die Befugnis zur Direktvergabe und müssen neu ausschreiben, was den Zeitplan neu startet.
SBIR Phase-II-Vergaben bieten bis zu 1,72 Millionen US-Dollar (aktuelles DoD-Limit) für einen Zeitraum von 24 Monaten. Die Phase-III-Provision -- die es einem Programmbüro erlaubt, ohne Wettbewerb einen Folgevertrag an einen Phase-II-Gewinner zu vergeben -- ist der Mechanismus, der SBIR-Forschungsfinanzierung in einen Beschaffungsvertrag umwandelt. Phase III hat keine Dollarbegrenzung und keine Wettbewerbsanforderung, was es zum mächtigsten verfügbaren Überbrückungsinstrument für ein kleines Unternehmen macht. Die Einschränkung besteht darin, dass die Phase-III-Vergabe vollständig von einem willigen Programmbüro mit einer offenen Finanzierungslinie abhängt -- und die Identifizierung dieses Programmbüros vor Ablauf der Phase-II-Periode erfordert dieselbe Fürsprecherpflege, die jeder andere Beschaffungsweg verlangt. Ökosystemprogramme wie Brave1 in der Ukraine haben gezeigt, dass strukturierte öffentlich-private Beschleunigungsrahmen diesen Zeitrahmen zur Fürsprecheridentifizierung komprimieren können, indem Startups sichtbaren Zugang zu Programmbüros erhalten, die aktiv nach bestimmten Fähigkeitstypen suchen.
Der CSO-Prozess von DIU ist für kommerzielle Technologie mit einer Verteidigungsanwendung optimiert und erzeugt eine Commercial Solutions Opening-Vergabe, die unter 10 USC 4022 in einen Produktionsvertrag übergehen kann. DIUs Stärke ist Geschwindigkeit -- Vergaben können in 60 bis 90 Tagen abgeschlossen werden -- und sein Netzwerk, das ausgewählte Unternehmen mit operativen Nutzern und Programmbüros in den Teilstreitkräften verbindet. Die strukturelle Einschränkung für ein Startup besteht darin, dass DIU ein Übergangsmechanismus ist, kein nachhaltiger Finanzierer. Eine DIU-Vergabe beweist das Konzept und stellt eine einführende Budgetlinie bereit; sie ersetzt nicht ein Dienst-Programmbüro, das die Anforderung in seinem POM besitzt.
Aufbau eines bewertbaren Minimum Viable Product für Beschaffungsbeamte
Ein Minimum Viable Product (MVP) für die Beschaffung ist nicht dasselbe Artefakt wie ein MVP für einen kommerziellen Softwarestart. Kommerzielle MVPs sind darauf ausgelegt, eine Markthypothese mit zahlenden Early Adopters zu testen. Verteidigungs-MVPs müssen eine andere Gruppe von Bewertern zufriedenstellen -- Beschaffungsbeamte, Programmmanager, operative Tester und Sicherheitsgutachter -- jeder mit unterschiedlichen Anforderungen, die in keinem einzigen Bewertungsrahmen vollständig erfasst sind.
Der Beschaffungsbeamte muss bestätigen, dass der vorgeschlagene Preis fair und angemessen ist und dass der Anbieter verantwortungsvoll handelt (d.h. die finanzielle, technische und führungsmäßige Kapazität zur Ausführung hat). Das bedeutet, dass das MVP von einer Rough Order of Magnitude (ROM)-Kostenstruktur begleitet sein muss, die das Unternehmen unter Kontrolle verteidigen kann, einem CAGE-Code und einer SAM.gov-Registrierung sowie mindestens einer Referenz für frühere Leistungen -- selbst aus einem kommerziellen oder alliierten Programm -- die belegt, dass das Unternehmen vergleichbare Arbeiten geliefert hat. Das Verständnis des vollständigen RFP-bis-Vertragsablaufs hilft Startups, diese Dokumentation vorzubereiten, bevor sie angefordert wird, anstatt sie unter einer 72-Stunden-Antwortfrist zusammenzustellen.
Der Programmmanager muss bestätigen, dass die Technologie eine dokumentierte Fähigkeitslücke adressiert und dass die Integrationsbelastung für die Regierung beherrschbar ist. Ein MVP, das das Programmbüro zwingt, bestehende C2-Systeme zu modifizieren, Bedienpopulationen neu auszubilden oder zwei parallele Datenpipelines zu pflegen, fügt Übergangskosten hinzu, die der Programmmanager gegenüber höherer Stelle rechtfertigen muss. Die am besten beschaffungslesbaren MVPs verbinden sich mit bestehenden Datenstandards (CoT, STANAG, Link 16, NIEM), ohne dass eine Middleware erforderlich ist, die die Regierung separat finanzieren und pflegen muss. Jede Integrationsabhängigkeit, die ein Startup aus seinem MVP entfernt, reduziert die Reibungskosten, die das Programmbüro tragen muss, um das Produkt zu vertreten.
Zeitpläne für Sicherheitszertifizierungen und wie man sie verkürzt
Die Sicherheitszertifizierung -- die Erlangung einer Betriebsgenehmigung (ATO) im Rahmen des DoD Risk Management Framework (RMF) -- ist das am konsistentesten unterschätzte Zeitplanelement im Beschaffungsplan eines Verteidigungsstartups. Erstmalige ATO-Kandidaten budgetieren routinemäßig 6 Monate und befinden sich im Monat 18 immer noch wartend auf die Unterschrift des genehmigenden Beamten. Die Verzögerungen entstehen nicht, weil das Produkt unsicher ist; sie entstehen, weil die Kontrolldokumentation unvollständig ist, die Systemgrenze schlecht definiert ist oder die Bewertungsorganisation keine Bandbreite hat, um die Sicherheitsbewertung zu planen, bis Monate nach der Einreichung des Dokumentationspakets.
Die schnellsten ATOs werden auf geerbten Kontrollen aus einer vorautorisierter Hosting-Basis aufgebaut. Wenn das Produkt in einer Infrastructure-as-a-Service-Umgebung läuft, die bereits eine vorläufige DoD-Impact-Level-2- oder Impact-Level-4-Genehmigung hält -- AWS GovCloud East, Azure Government oder vergleichbar -- erbt das Startup einen wesentlichen Teil des NIST SP 800-53-Kontrollsatzes vom vorhandenen Autorisierungspaket des Cloud-Dienstleisters. Die Bewertung des Startups deckt dann nur die nicht geerbten Kontrollen ab: Kontrollen auf Anwendungsebene, Konfigurationsmanagement, Zugriffskontrolle auf Softwareebene und die überlagerten Kontrollen spezifisch für die Datenklassifizierungsstufe. Ein gut abgegrenztes cloud-natives Produkt kann seinen eigenständigen Kontrollimplementierungssatz von der vollständigen 325-Kontrollen-NIST 800-53 Rev 5-Basis auf 80 bis 120 anwendungsspezifische Kontrollen reduzieren und damit die Bewertungsdauer proportional verkürzen.
Der zweite Beschleunigungshebel ist Dokumentationsdisziplin vom ersten Tag der Produktentwicklung an. RMF erfordert einen System Security Plan (SSP), der beschreibt, wie jede anwendbare Kontrolle implementiert ist. Das nachträgliche Schreiben eines SSP für ein Produkt, das ohne Sicherheitsarchitekturdokumentation aufgebaut wurde, ist langsam und fehleranfällig; das Schreiben während des Produktaufbaus -- mit DevSecOps-Pipelines, die kontinuierliche Compliance-Nachweise produzieren -- reduziert den SSP auf eine redaktionelle Aufgabe statt einer forensischen Rekonstruktion. Startups, die ihre CI/CD-Pipelines mit OSCAL-formatierten Kontrollnachweisen und automatisierten Compliance-Scans instrumentieren, können einem Gutachter maschinenlesbare Nachweispakete präsentieren, die die Bewertungsplanungsphase von Wochen auf Tage komprimieren.
Den Programmbüro-Fürsprecher finden: Beziehungen über Angebote
Kein Beschaffungsweg führt zu einem Program of Record ohne einen Regierungsangestellten, der bereit ist, für die Technologie innerhalb des Programmbüros einzutreten, wenn der Anbieter nicht anwesend ist. Diese Person -- der Fürsprecher -- wird nicht durch Angebotseinreichungen oder die Teilnahme an Industrietagen allein gefunden. Fürsprecher werden durch beständiges, technisch glaubwürdiges Engagement über 12 bis 24 Monate kultiviert, das demonstriert, dass das Startup das operative Problem so gut versteht wie jeder etablierte Auftragnehmer.
Der zuverlässigste Weg zur Fürsprecheridentifizierung führt über operative Nutzer statt über Beschaffungsbüros. Ein Programmmanager, der konsequentes positives Feedback von uniformierten Endnutzern erhält, die das Produkt verwendet haben -- selbst in einem inoffiziellen Bewertungs- oder Übungskontext -- ist weitaus motivierter, für eine Budgetlinie einzutreten, als einer, der nur ein Fähigkeits-Briefing gelesen hat. Das bedeutet, dass Startups in den Zugang zu operativen Übungen, Kriegsspielen und Koalitionsveranstaltungen investieren sollten, bei denen ihre Technologie von echten Operateuren getestet werden kann, auch ohne ein formelles Vertragsfahrzeug. Die Rückkopplungsschleifen aus diesen Kontaktpunkten erzeugen die Operateur-Empfehlungen, die Programmmanager nutzen, um neue Anfangsmittelanfragen gegenüber Programm-Exekutivoffizieren zu rechtfertigen.
Wichtige Erkenntnis: Die wichtigste Funktion des Programmbüro-Fürsprechers ist der Schutz der Position des Startups während des POM-Einreichungszyklus. Program Objective Memoranda werden auf mehreren Ebenen überprüft und gekürzt -- Programmmanager, Programm-Exekutivoffizier, Dienst-Hauptquartier und OSD -- und ein Neustart-Antrag von einem unbekannten Anbieter ohne bestehende Auftragshistorie gehört zu den ersten Positionen, die während Haushaltsdruck gestrichen werden. Ein Fürsprecher, der die Fähigkeit mit einem validierten Joint Urgent Operational Need (JUON) oder einem JCIDS-Lückendokument verknüpfen kann, verwandelt eine diskretionäre Investition in eine dokumentierte Anforderung, die Haushaltskürzungen mit deutlich höherer Rate übersteht.
Koalitions- und NATO-Beschaffung: zusätzliche Schichten und Vorbereitung
Ein Verteidigungsstartup, das sein Produkt auf einem nationalen Markt bewiesen hat, sieht sich strukturell unterschiedlichen Anforderungen gegenüber, wenn es Koalitions- oder NATO-Beschaffung verfolgt. Die Technologie kann identisch sein, aber die rechtlichen, sicherheitstechnischen und Interoperabilitätsanforderungen vervielfachen sich mit jeder zusätzlichen Nation. Unternehmen, die die Koalitionsbeschaffung als einfache geografische Erweiterung ihrer bestehenden Vertragsstrategie angehen, unterschätzen konsequent die erforderliche Vorbereitung und verlieren Zeit genau in dem Moment, in dem ihr First-Mover-Vorteil am wertvollsten ist.
Exportkontrolle ist die erste zu lösende Einschränkung. US-amerikanische Software oder Hardware mit Verteidigungsanwendung unterliegt den International Traffic in Arms Regulations (ITAR) oder den Export Administration Regulations (EAR). Ein Startup, das seine Export Control Classification Number (ECCN) nicht bestimmt und etwaige erforderliche Lizenzen erhalten hat, bevor es ein britisches, deutsches oder finnisches Programmbüro verfolgt, schafft rechtliche Risiken sowohl für sich selbst als auch für den ausländischen Regierungspartner. Die Exportklassifizierungsanalyse sollte vor dem ersten Treffen mit einem ausländischen Programmbüro abgeschlossen sein, nicht nachdem ein Interessenbekundungsschreiben eingegangen ist.
Für die NATO-gemeinschaftlich finanzierte Beschaffung über die NATO Support and Procurement Agency (NSPA) muss das Produkt sowohl die Sicherheitsanforderungen des beschaffenden Landes als auch die geltenden NATO-Sicherheitsrichtlinien erfüllen. Dies führt zu einem dualen Zertifizierungsweg -- nationale ATO plus NATO-Akkreditierung -- der parallel laufen kann, aber eine Koordination zwischen zwei Sicherheitsmanagementsstrukturen erfordert, die keine Dokumentationsformate oder Bewertungspläne teilen. Startups, die in diesen Bereich eintreten, sollten prüfen, ob ihre Architektur segregierte nationale Instanzen oder eine mandantenfähige Bereitstellung mit kryptografisch durchgesetzter Datentrennung unterstützt, da die Antwort bestimmt, ob ein einzelnes Zertifizierungspaket für verschiedene Nationen angepasst werden kann oder ob separate Pakete für jede Nation erstellt werden müssen. Der NSPA-Beschaffungszeitplan für einen neuen Fähigkeitsvertrag läuft von der ersten Anforderung bis zur Vergabe 24 bis 36 Monate, was von Anfang an in die Liquiditätsplanung einkalkuliert werden muss.
Vom Machbarkeitsnachweis zur vollständigen Bereitstellung: Management des Übergangsrisikos
Übergangsrisiko -- das Risiko, dass eine erfolgreich erprobte Technologie keine operative Skalierung erreicht -- ist der Hauptgrund, warum Programmbüros zögern, sich mit einem Startup-Anbieter auf ein Program of Record festzulegen. Das Zögern ist nicht irrational. Programmbüros, die in neue Programme mit kleinen Anbietern investiert haben, haben Technologiediskontinuität erlebt, wenn dem Anbieter die Liquidität ausging, Produktpivots, die die anfängliche Fähigkeitsbewertung ungültig machten, und Integrationsfehler, die erst bei der vollständigen Bereitstellung auftraten. Die explizite Behandlung dieser Risiken in den Übergangsplanungsdokumenten ist effektiver als die Versicherung von Stabilität in Fähigkeits-Briefings.
Die Datenrechtsbehauptung ist das operativ bedeutsamste Dokument in einem Übergangsplan. Gemäß DFARS 252.227-7013 hat die Regierung Anspruch auf Zweckrechte für technische Daten, die mit gemischter Finanzierung entwickelt wurden -- aber der Umfang dieser Rechte hängt davon ab, wie das Startup seine Investitionen in unabhängige Forschung und Entwicklung (IR&D) zum Zeitpunkt der Entwicklung dokumentiert hat. Ein Startup, das keine zeitnahen Aufzeichnungen darüber gepflegt hat, welche Produktkomponenten mit firmeneigenen IR&D-Mitteln gegenüber staatlicher Finanzierung entwickelt wurden, wird es schwer haben, die eingeschränkten Rechte geltend zu machen, auf die es Anspruch hat, und gewährt der Regierung möglicherweise unbeabsichtigt umfangreichere Datenrechte als beabsichtigt. Umgekehrt wird ein Startup, das zu breite eingeschränkte Rechte für staatlich finanzierte Entwicklung geltend macht, einen Vertragsstreit auslösen, der den Übergang verzögert. Der richtige Ansatz besteht darin, ein finanziertes IR&D-Programm mit dokumentierten Ausgaben zu pflegen, Rechte aus gemischter Finanzierung eng und genau geltend zu machen und eine Lizenzstruktur auszuhandeln, die der Regierung ausreichenden Datenzugang für Wettbewerb am Ende der Vertragslaufzeit gibt, ohne das Kern-IP des Startups zu übertragen.
Die Instandhaltungsplanung erhält während der Pilotphase weniger Aufmerksamkeit als sie verdient, und die Lücke zeigt sich beim Übergang. Ein Program of Record erfordert nicht nur die Fähigkeit, sondern eine definierte Unterstützungsstruktur: eine Logistikunterstützungsanalyse (oder Äquivalent für Software), einen Software-Supportplan, eine Cybersicherheits-Instandhaltungsstrategie und -- für eingesetzte Hardware -- eine Ersatzteile- und Wartungskette. Startups, die diese Artefakte der Programmbürobewertung präsentieren, bevor sie danach gefragt werden, demonstrieren institutionelle Bereitschaft, die sie von Wettbewerbern unterscheidet, die Instandhaltung als ein Problem nach der Vergabe behandeln. Der operative Nutzer, der das Pilotprojekt unterstützt hat, wird für die folgende Unterstützungsstruktur verantwortlich gemacht. Die Verringerung dieser Verantwortungslast ist eine der effektivsten Möglichkeiten, die Fürsprecherbeziehung während der Übergangsphase zu stärken.
Den Verteidigungsbeschaffungszyklus mit einem erfahrenen Partner navigieren
Corvus Intelligence hat Verteidigungsbeschaffungszyklen über mehrere Märkte hinweg navigiert. Wenn Sie Verteidigungstechnologie entwickeln und verstehen möchten, wie etablierte Anbieter Beschaffungsengagements strukturieren, nehmen Sie für ein Briefing Kontakt auf.
Diese Analyse wurde von Corvus Intelligence-Ingenieuren erstellt, die missionskritische ISR- und Feldanwendungen für Verteidigungs- und Regierungsorganisationen entwickeln. Mehr über unser Team →