Cykl zamówień obronnych dla startupów: od pilotażu do programu docelowego

Większość startupów technologii obronnych, które ponoszą porażkę komercyjną, nie upada dlatego, że ich produkt przestał działać. Upadają, ponieważ dystans między udanym pilotażem a finansowanym Programem Docelowym (POR) jest dłuższy, bardziej biurokratycznie złożony i bardziej uzależniony od relacji, niż zakłada jakikolwiek harmonogram produktu. Mechanika zdobycia pierwszego kontraktu rządowego jest dobrze udokumentowana. Znacznie mniej uwagi poświęca się trudniejszemu etapowi, który następuje po niej: przekształceniu jednorazowej płatności za pilotaż w trwałą linię budżetową zdolną utrzymać firmę na etapie wzrostu. Niniejszy artykuł śledzi pełny cykl zamówień – od projektowania pilotażu przez prototyp OTA, akredytację bezpieczeństwa, kultywowanie mistrza programowego, uwarunkowania koalicyjne aż po strukturalne ryzyka przejścia, które kończą programy zanim osiągną skalę operacyjną.

Dolina śmierci: dlaczego dobra technologia zatrzymuje się między pilotażem a kontraktem

Dolina śmierci nie jest metaforą dotyczącą jakości produktu. Jest to strukturalna luka finansowa wynikająca z rozbieżności między tempem demonstracji technologii a tempem cykli budżetowych w sektorze obronnym. Firma może ukończyć pilotaż w ciągu 90 dni. Biuro programowe może potwierdzić, że zadziałał. Jednak biuro programowe nie może zaciągać nowych zobowiązań wobec zdolności, którą właśnie odkryło – nie dopóki ta zdolność nie przetrwa procesu Programowego Memorandum Celów (POM), który działa w 18-miesięcznym cyklu i wymaga udokumentowanych wymagań, szacunków kosztów i ocen ryzyka, które nie istnieją dla technologii właśnie ocenionej przez program.

W tym czasie od startupu oczekuje się kontynuacji rozwoju produktu, utrzymania wyszkolonego zespołu, wspierania dokumentacji oceny rządowej i pozostania wypłacalnym na podstawie tego, co zdoła pozyskać w ramach SBIR Fazy II, kontraktu pomostowego lub kolejnego OTA. Mediana czasu trwania tej luki – między zakończeniem udanego pilotażu a pierwszym zobowiązaniem w ramach nowej linii budżetowej programu – wynosi 18–36 miesięcy dla produktu oprogramowania bez wcześniejszej historii zamówień DoD. Firmy planujące 6-miesięczną przerwę i kończące pieniądze w 14. miesiącu zazwyczaj nie mają drugich szans w biurach programowych; mistrz odchodzi, a technologia jest od nowa oceniana przez kolejnego kierownika programu.

Praktyczną implikacją jest to, że projektowanie pilotażu musi uwzględniać dolinę zanim pilotaż się rozpocznie. Pilotaż ustrukturyzowany pod kątem generowania konkretnej dokumentacji – analizy luk zdolności, danych o skuteczności operacyjnej, architektury integracji, projekcji kosztu jednostkowego – której kierownik programu potrzebuje do opracowania wniosku POM, przeżywa okres przejściowy z wyższą skutecznością niż pilotaż zaprojektowany wyłącznie w celu demonstracji wydajności technicznej. Wydajność techniczna to wymóg podstawowy. Czytelność administracyjna dla procesu budżetowego pozwala przekroczyć dolinę.

Umowy OTA, SBIR i ścieżki DIU – czym się różnią

Trzy instrumenty kontraktowe dominują w wczesnych kontaktach startupu obronnego z rządem: umowy prototypowe w ramach Other Transaction Authority (OTA), nagrody Small Business Innovation Research (SBIR) oraz proces Commercial Solutions Opening (CSO) Defense Innovation Unit (DIU). Nie są one wymienne, a wybór niewłaściwego instrumentu w nieodpowiednim momencie cyklu zamówień powoduje opóźnienia, z których trudno się podnieść.

Umowy prototypowe OTA na podstawie 10 USC 4022 to najszybsza ścieżka od finansowanego wymogu do ocenionego prototypu dla startupu nieposiadającego systemów rachunkowości rządowej. Nie podlegają one Federalnemu Regulaminowi Zamówień, co oznacza, że biuro programowe może przyznać OTA firmie, która nigdy nie posiadała kontraktu DoD, nie ma systemów rachunkowości zatwierdzonych przez Defense Contract Audit Agency (DCAA) i nie może dostarczyć certyfikowanych danych o kosztach i cenach. Kompromisem jest zakres: zamówienia OTA są z mocy prawa ograniczone do działalności prototypowej. Przejście do pełnej produkcji wymaga albo konkurencyjnego zamówienia opartego na FAR, albo zamówienia produkcyjnego bez przeprowadzania postępowania przetargowego na podstawie przepisu przejściowego statutu OTA – a to zamówienie bez przetargu nie jest automatyczne. Wymaga od biura programowego pisemnego stwierdzenia, że prototyp został przyznany w sposób konkurencyjny i że kontynuacja produkcji jest logicznym rozwinięciem. Biura programowe, które nie zaplanowały tego przejścia z wyprzedzeniem, często tracą uprawnienie do zamówienia bez przetargu i muszą ponownie przeprowadzić postępowanie, od nowa uruchamiając harmonogram.

Nagrody SBIR Fazy II zapewniają do 1,72 mln USD (aktualny limit DoD) na okres 24 miesięcy. Przepis Fazy III – pozwalający biuru programowemu przyznać kontynuację kontraktu laureatowi Fazy II bez przeprowadzania postępowania przetargowego – jest mechanizmem, który przekształca finansowanie badań SBIR w kontrakt zamówień. Faza III nie ma limitu kwotowego ani wymogu konkurencji, co czyni ją najpotężniejszym instrumentem pomostowym dostępnym dla małej firmy. Ograniczeniem jest to, że zamówienie Fazy III jest całkowicie uzależnione od chętnego biura programowego z dostępną linią finansowania – a identyfikacja tego biura przed wygaśnięciem okresu Fazy II wymaga tej samej pracy nad kultywowaniem mistrza, jakiej wymaga każda inna ścieżka zamówień. Programy ekosystemowe takie jak Brave1 na Ukrainie pokazały, że ustrukturyzowane ramy akceleracji publiczno-prywatnej mogą skrócić czas identyfikacji mistrza, dając startupom widoczny dostęp do biur programowych aktywnie poszukujących określonych typów zdolności.

Proces CSO DIU jest zoptymalizowany dla technologii komercyjnych z zastosowaniem obronnym i generuje zamówienie Commercial Solutions Opening, które może przejść do kontraktu produkcyjnego na podstawie 10 USC 4022. Mocną stroną DIU jest szybkość – zamówienia mogą być zamykane w ciągu 60–90 dni – oraz sieć kontaktów łącząca wybrane firmy z operacyjnymi użytkownikami i biurami programowymi w ramach wszystkich rodzajów sił zbrojnych. Strukturalnym ograniczeniem dla startupu jest to, że DIU jest mechanizmem przejścia, a nie stałym finansującym. Zamówienie DIU potwierdza koncepcję i zapewnia wstępną linię budżetową; nie zastępuje biura programowego rodzaju sił zbrojnych będącego właścicielem wymogu ujętego w POM.

Budowanie ocenialnego minimalnego produktu żywotnego dla oficerów zamówień

Minimalny produkt żywotny (MVP) do celów zamówień to nie ten sam artefakt co MVP dla komercyjnego uruchomienia oprogramowania. Komercyjne MVP są projektowane w celu testowania hipotezy rynkowej z płacącymi wczesnymi użytkownikami. Obronne MVP zamówień muszą spełniać wymogi innego zestawu oceniających – oficerów kontraktów, kierowników programów, testerów operacyjnych i oceniających bezpieczeństwo – z których każdy ma odrębne wymagania nieujęte w całości w żadnym pojedynczym systemie oceny.

Oficer kontraktów musi potwierdzić, że zaproponowana cena jest uczciwa i uzasadniona oraz że dostawca jest wiarygodny (tzn. posiada finansowe, techniczne i zarządcze zdolności do realizacji). Oznacza to, że MVP musi być opatrzony orientacyjnym kosztorysem (ROM), który firma może obronić pod wpływem kontroli, kodem CAGE i rejestracją w SAM.gov oraz co najmniej jednym odniesieniem do dotychczasowych realizacji – nawet z programu komercyjnego lub krajowego sojusznika – potwierdzającym, że firma zrealizowała porównywalne prace. Zrozumienie pełnego procesu od RFI do kontraktu pomaga startupom przygotować tę dokumentację zanim zostanie ona zażądana, zamiast pospiesznie ją kompletować w obliczu 72-godzinnego terminu odpowiedzi.

Kierownik programu musi potwierdzić, że technologia eliminuje udokumentowaną lukę zdolności i że ciężar integracji po stronie rządu jest możliwy do zarządzania. MVP wymagający od biura programowego modyfikacji istniejących systemów C2, przeszkolenia personelu operatorskiego lub utrzymywania dwóch równoległych potoków danych generuje koszt przejścia, który kierownik programu musi uzasadnić wyższemu zwierzchnictwu. Najbardziej czytelne dla zamówień MVP łączą się z istniejącymi standardami danych (CoT, STANAG, Link 16, NIEM) bez konieczności stosowania oprogramowania pośredniczącego, które rząd musi osobno finansować i utrzymywać. Każda zależność integracyjna, którą startup usuwa ze swojego MVP, zmniejsza koszt tarcia, jaki biuro programowe musi ponosić, wspierając dany produkt.

Harmonogramy akredytacji bezpieczeństwa i sposoby ich skracania

Akredytacja bezpieczeństwa – uzyskanie zezwolenia na eksploatację (ATO) w ramach Systemu Zarządzania Ryzykiem (RMF) DoD – jest elementem harmonogramu najczęściej niedoszacowanym w planach zamówień startupów obronnych. Kandydaci ubiegający się o ATO po raz pierwszy rutynowo planują 6 miesięcy i docierają do 18. miesiąca wciąż czekając na podpis organu autoryzującego. Opóźnienia nie wynikają z faktu, że produkt jest niezabezpieczony; wynikają z niekompletności dokumentacji zabezpieczeń, słabo zdefiniowanych granic systemu lub braku przepustowości organizacji oceniającej do zaplanowania oceny bezpieczeństwa na miesiące po złożeniu pakietu dokumentacji.

Najszybsze ATOs są budowane na odziedziczonych zabezpieczeniach z wstępnie autoryzowanej podstawy hostingowej. Jeśli produkt działa w środowisku infrastruktury jako usługi posiadającym już tymczasową autoryzację DoD Impact Level 2 lub Impact Level 4 – AWS GovCloud East, Azure Government lub odpowiednik – startup dziedziczy znaczną część zestawu zabezpieczeń NIST SP 800-53 z istniejącego pakietu autoryzacji dostawcy usług chmurowych. Ocena startupu obejmuje wówczas wyłącznie zabezpieczenia nieodziedziczone: zabezpieczenia na poziomie aplikacji, zarządzanie konfiguracją, kontrolę dostępu na poziomie oprogramowania i nakładkowe zabezpieczenia specyficzne dla poziomu klasyfikacji danych. Dobrze określony produkt natywny dla chmury może zredukować zestaw samodzielnych implementacji zabezpieczeń z pełnych 325 zabezpieczeń bazowych NIST 800-53 Rev 5 do 80–120 zabezpieczeń specyficznych dla aplikacji, proporcjonalnie skracając czas oceny.

Druga dźwignia przyspieszenia to dyscyplina dokumentacyjna od pierwszego dnia tworzenia produktu. RMF wymaga Planu Bezpieczeństwa Systemu (SSP) opisującego sposób implementacji każdego obowiązującego zabezpieczenia. Retrospektywne pisanie SSP dla produktu zbudowanego bez dokumentacji architektury bezpieczeństwa jest powolne i podatne na błędy; pisanie go na bieżąco z rozwojem produktu – z potokami DevSecOps generującymi ciągłe dowody zgodności – redukuje SSP do zadania redakcyjnego, a nie rekonstrukcji śledczej. Startupy, które wdrażają w swoich potokach CI/CD dowody zabezpieczeń w formacie OSCAL i automatyczne skanowanie zgodności, mogą przedstawić oceniającemu czytelne maszynowo pakiety dowodów, skracając fazę planowania oceny z tygodni do dni.

Znajdowanie mistrza biura programowego: relacje zamiast propozycji

Żadna ścieżka zamówień nie prowadzi do Programu Docelowego bez pracownika rządowego gotowego rzecznikować za technologią wewnątrz biura programowego pod nieobecność dostawcy. Ta osoba – mistrz – nie jest znajdowana wyłącznie przez składanie ofert czy uczestnictwo w dniach branżowych. Mistrzów kultywuje się poprzez nieustanne, merytorycznie wiarygodne zaangażowanie przez 12–24 miesięcy, które demonstruje, że startup rozumie problem operacyjny równie dobrze jak jakikolwiek wykonawca-inkumbent.

Najbardziej niezawodna ścieżka do identyfikacji mistrza wiedzie przez operacyjnych użytkowników, a nie przez biura zamówień. Kierownik programu, który regularnie otrzymuje pozytywne opinie od umundurowanych użytkowników końcowych korzystających z produktu – nawet w kontekście nieoficjalnej oceny lub ćwiczeń – jest znacznie bardziej zmotywowany do rzecznikowania za linią budżetową niż ten, który zapoznał się jedynie z briefingiem zdolności. Oznacza to, że startupy powinny inwestować w dostęp do ćwiczeń operacyjnych, gier wojennych i wydarzeń koalicyjnych, gdzie ich technologia może być testowana przez rzeczywistych operatorów, nawet bez formalnego instrumentu kontraktowego. Pętle informacji zwrotnych z tych punktów kontaktu generują rekomendacje operatorów, których kierownicy programów używają do uzasadniania wniosków o nowe uruchomienia wobec dyrektorów wykonawczych programów.

Zamówienia koalicyjne i NATO: dodatkowe warstwy i przygotowanie

Startup obronny, który udowodnił swój produkt na jednym rynku krajowym, staje w obliczu strukturalnie odmiennego zestawu wymogów przy ubieganiu się o zamówienia koalicyjne lub NATO. Technologia może być identyczna, lecz wymogi prawne, bezpieczeństwa i interoperacyjności mnożą się wraz z każdym kolejnym narodem. Firmy podchodzące do zamówień koalicyjnych jak do prostej geograficznej ekspansji istniejącej strategii kontraktowej konsekwentnie nie doceniają wymaganych przygotowań i tracą czas dokładnie w momencie, gdy ich przewaga pionierska jest najbardziej wartościowa.

Kontrola eksportu jest pierwszym ograniczeniem do rozwiązania. Oprogramowanie lub sprzęt o amerykańskim pochodzeniu z zastosowaniem obronnym podlega przepisom International Traffic in Arms Regulations (ITAR) lub Export Administration Regulations (EAR). Startup, który przed ubieganiem się o kontakt z biurem programowym w Wielkiej Brytanii, Niemczech lub Finlandii nie określił numeru klasyfikacji kontroli eksportu (ECCN) swojego produktu i nie uzyskał wymaganych licencji, tworzy narażenie prawne zarówno dla siebie, jak i dla zagranicznego kontrahenta rządowego. Analiza klasyfikacji eksportowej powinna być przeprowadzona przed pierwszym spotkaniem z zagranicznym biurem programowym, a nie po otrzymaniu listu intencyjnego.

W przypadku zamówień ze wspólnego funduszu NATO realizowanych za pośrednictwem Agencji Wsparcia i Zamówień NATO (NSPA), produkt musi spełniać zarówno wymogi bezpieczeństwa kraju zamawiającego, jak i obowiązujące polityki bezpieczeństwa NATO. Wprowadza to podwójną ścieżkę akredytacji – krajowe ATO oraz akredytacja NATO – które mogą toczyć się równolegle, lecz wymagają koordynacji między dwoma strukturami zarządzania bezpieczeństwem, które nie współdzielą formatów dokumentacji ani harmonogramów ocen. Startupy wchodzące w tę przestrzeń powinny określić, czy ich architektura obsługuje wyodrębnione instancje krajowe, czy też wdrożenie wielodostępne z kryptograficznie wymuszaną separacją danych – ponieważ odpowiedź determinuje, czy jeden pakiet akredytacyjny może być adaptowany dla różnych narodów, czy też oddzielne pakiety muszą być opracowane dla każdego z nich. Harmonogram kontraktowania NSPA dla nowej umowy o zdolność wynosi 24–36 miesięcy od wstępnego wymogu do zamówienia, co musi być uwzględnione w planowaniu przepływów pieniężnych od samego początku.

Od dowodu koncepcji do pełnego wdrożenia: zarządzanie ryzykiem przejścia

Ryzyko przejścia – ryzyko, że z powodzeniem pilotowana technologia nie osiągnie skali operacyjnej – jest głównym powodem, dla którego biura programowe wahają się przed zobowiązaniem się do Programu Docelowego z startupem-dostawcą. Wahanie to nie jest irracjonalne. Biura programowe, które inwestowały w programy nowych uruchomień z małymi dostawcami, doświadczyły nieciągłości technologicznej spowodowanej brakiem płynności finansowej dostawcy, zwrotów produktu unieważniających wstępną ocenę zdolności oraz awarii integracyjnych ujawnionych dopiero podczas wdrożenia na pełną skalę. Wyraźne odniesienie się do tych ryzyk w dokumentach planowania przejścia jest skuteczniejsze niż potwierdzanie stabilności w briefingach zdolności.

Deklaracja praw do danych jest najważniejszym operacyjnie dokumentem w planie przejścia. Zgodnie z DFARS 252.227-7013, rządowi przysługują prawa do celów rządowych w danych technicznych opracowanych ze środków mieszanych – lecz zakres tych praw zależy od sposobu, w jaki startup dokumentował swoje inwestycje w niezależne badania i rozwój (IR&D) w chwili tworzenia. Startup, który nie prowadził bieżących zapisów dotyczących tego, które komponenty produktu zostały opracowane ze środków własnych IR&D firmy, a które ze środków rządowych, będzie miał trudności z dochodzeniem należnych mu ograniczonych praw i może mimowolnie przyznać rządowi szersze prawa do danych niż zamierzał. Odwrotnie – startup, który zbyt szeroko dochodzi ograniczonych praw do produktów opracowanych ze środków rządowych, wywoła spór kontraktowy opóźniający przejście. Właściwe podejście polega na prowadzeniu finansowanego programu IR&D z udokumentowanymi wydatkami, wąskim i dokładnym dochodzeniu praw do finansowania mieszanego oraz negocjowaniu struktury licencji zapewniającej rządowi wystarczający dostęp do danych na potrzeby ponownej konkurencji po zakończeniu okresu kontraktu, bez przenoszenia podstawowego IP startupu.

Planowanie trwałości otrzymuje mniej uwagi niż zasługuje podczas fazy pilotażu, a luka ta ujawnia się przy przejściu. Program Docelowy wymaga nie tylko zdolności, lecz zdefiniowanej struktury wsparcia: analizy wsparcia logistycznego (lub jej odpowiednika dla oprogramowania), planu wsparcia oprogramowania, strategii trwałości cyberbezpieczeństwa oraz – dla wdrożonego sprzętu – łańcucha części zamiennych i obsługi technicznej. Startupy, które prezentują te artefakty na przeglądzie biura programowego przed ich zażądaniem, demonstrują gotowość instytucjonalną odróżniającą je od konkurentów traktujących trwałość jako problem poakwizycyjny. Operacyjny użytkownik, który wspierał pilotaż, będzie pociągnięty do odpowiedzialności za strukturę wsparcia, która po nim następuje. Zmniejszenie tego ciężaru odpowiedzialności jest jednym z najskuteczniejszych sposobów wzmocnienia relacji z mistrzem podczas fazy przejścia.