Puolustusalan startup-yrityksen hankintaprosessi: pilottiprojektista sopimusohjelmaan

Suurin osa kaupallisesti epäonnistuvista puolustusalan teknologistartupeista ei epäonnistu siksi, että niiden tuote lakkaa toimimasta. Ne epäonnistuvat siksi, että matka onnistuneesta pilottiprojektista rahoitettuun sopimusohjelmaan (Program of Record, POR) on pidempi, byrokraattisesti monimutkaisempi ja enemmän suhteista riippuvainen kuin mikään tuotteiden tiekartta ennakoikaan. Ensimmäisen valtion sopimuksen voittamisen mekaniikka on hyvin dokumentoitu. Se, mikä saa huomattavasti vähemmän huomiota, on vaikeampi vaihe sen jälkeen: kertaluonteisen pilottimaksun muuttaminen kestäväksi budjettilinjäksi, joka voi tukea kasvuvaiheen yritystä. Tässä artikkelissa käydään läpi koko hankintaprosessi -- pilotin suunnittelusta OTA-prototyyppisopimukseen, tietoturva-akkreditointiin, ohjelmapuolestapuhujan viljelyyn, koalitionäkökohtiin ja rakenteellisiin siirtymäriskeihin, jotka päättävät ohjelmat ennen kuin ne saavuttavat operatiivisen mittakaavan.

Kuoleman laakso: miksi hyvä teknologia pysähtyy pilotin ja sopimuksen väliin

Kuoleman laakso ei ole metafora tuotteen laadusta. Se on rakenteellinen rahoituskuilu, joka syntyy teknologiademonstroinnin nopeuden ja puolustusbudjettisyklien nopeuden välisestä epäsuhdasta. Yritys voi suorittaa pilotin 90 päivässä. Hankintavirasto voi vahvistaa sen toimineen. Mutta hankintavirasto ei voi sitoa uutta rahaa vasta löytämäänsä kykyyn -- ei ennen kuin tuo kyky on selvinnyt Program Objective Memorandum (POM) -prosessista, joka kulkee 18 kuukauden syklillä ja edellyttää dokumentoituja vaatimuksia, kustannusarvioita ja riskiarvioita, joita ei ole olemassa teknologialle, jota ohjelma juuri arvioi.

Tänä aikana startupin odotetaan jatkavan tuotekehitystä, ylläpitävän koulutettua tiimiä, tukevan hallituksen arviointidokumentaatiota ja pysyvän maksukykyisenä sillä SBIR Phase II -rahoituksella, silta-sopimuksella tai jatko-OTA:lla, jonka se pystyy hankkimaan. Tämän kuilun mediaanipituus -- onnistuneen pilotin päättymisen ja ensimmäisen uuden budjettilinjan mukaisen sitoumuksen välillä ohjelmistotuotteelle, jolla ei ole aiempaa DoD-hankintahistoriaa -- on 18--36 kuukautta. Yritykset, jotka suunnittelevat 6 kuukauden kuilua ja loppuvat rahasta kuukaudella 14, eivät saa toisia mahdollisuuksia useimmissa hankintavirastoissa; puolestapuhuja siirtyy eteenpäin, ja teknologia arvioidaan uudelleen nollasta seuraavan ohjelmajohtajan toimesta.

Käytännön implikaatio on, että pilotin suunnittelun on huomioitava laakso ennen pilotin alkua. Pilotti, joka on rakennettu tuottamaan tiettyä dokumentaatiota -- kykyaukkoanalyysi, operatiivisen tehokkuuden data, integraatioarkkitehtuuri, yksikkökustannusprojektio -- jota ohjelmajohtaja tarvitsee POM-lähetyksen rakentamiseen, selviää siirtymävaiheesta korkeammilla asteilla kuin pilotti, joka on suunniteltu pelkästään osoittamaan tekninen suorituskyky. Tekninen suorituskyky on pääsymaksu. Hallinnollinen selkeys budjettiprosessille on se, mikä ylittää laakson.

OTA-sopimukset, SBIR:t ja DIU-polut -- miten ne eroavat toisistaan

Kolme sopimusinstrumenttia hallitsevat varhaisen vaiheen puolustusalan startup-yhteistyötä: Other Transaction Authority (OTA) -prototyyppisopimukset, Small Business Innovation Research (SBIR) -palkinnot ja Defense Innovation Unit (DIU) Commercial Solutions Opening (CSO) -prosessi. Ne eivät ole keskenään vaihdettavissa, ja väärän kehyksen valitseminen hankintaelinkaaren väärässä vaiheessa aiheuttaa viivästyksiä, joita on vaikea korjata.

OTA-prototyyppisopimukset 10 USC 4022 -säädöksen nojalla ovat nopein reitti rahoitetusta vaatimuksesta arvioituun prototyyppiin startupille, jolla ei ole valtion kirjanpitojärjestelmiä. Ne toimivat Federal Acquisition Regulationin ulkopuolella, mikä tarkoittaa, että hankintavirasto voi myöntää OTA:n yritykselle, joka ei ole koskaan pitänyt DoD-sopimusta, jolla ei ole Defense Contract Audit Agencyn (DCAA) hyväksymiä kirjanpitojärjestelmiä, eikä pysty tuottamaan sertifioitua kustannus- tai hintatietoa. Kompromissi on laajuus: OTA-palkinnot on lain mukaan rajoitettu prototyyppitoimintaan. Siirtyminen täyteen tuotantoon edellyttää joko kilpailullista FAR-pohjaista jatkoa tai sole-source-tuotantopalkintoa OTA-säädöksen siirtymissäännöksen nojalla -- eikä tuo sole-source ole automaattinen. Se edellyttää hankintavirastolta kirjallista määritystä, että prototyyppi myönnettiin kilpailullisesti ja että tuotantojatko on looginen laajennus. Hankintavirastot, jotka eivät ole suunnitelleet tätä siirtymää etukäteen, menettävät usein sole-source-valtuutuksen ja joutuvat kilpailuttamaan uudelleen, jolloin aikataulu käynnistyy alusta.

SBIR Phase II -palkinnot tarjoavat enintään 1,72 miljoonaa dollaria (nykyinen DoD-raja) 24 kuukauden ajanjaksolle. Phase III -säännös -- joka sallii hankintaviraston myöntää sole-source-jatkosopimuksen Phase II -palkinnon saajalle ilman kilpailua -- on mekanismi, joka muuntaa SBIR-tutkimusrahoituksen hankintasopimukseksi. Phase III:lla ei ole dollarirajoitusta eikä kilpailuvaatimusta, mikä tekee siitä tehokkaimman sillanrakennusinstrumentin pienelle yritykselle. Rajoituksena on, että Phase III -palkinto riippuu täysin halukkaan hankintaviraston avoimesta rahoituslinjasta -- ja tuon hankintaviraston tunnistaminen ennen Phase II -jakson päättymistä edellyttää samaa puolestapuhujan viljelytyötä, jota jokainen muukin hankintapolku vaatii. Ukrainan Brave1:n kaltaiset ekosystemiohjelmat ovat osoittaneet, että jäsennellyt julkisen ja yksityisen sektorin kiihdystyskehykset voivat lyhentää tätä puolestapuhujan tunnistamisaikaa antamalla startupeille näkyvän pääsyn hankintavirastoihin, jotka aktiivisesti etsivät tiettyjä kykytyyppejä.

DIU:n CSO-prosessi on optimoitu kaupalliselle teknologialle, jolla on puolustussovellus, ja se tuottaa Commercial Solutions Opening -palkinnon, joka voi siirtyä tuotantosopimukseksi 10 USC 4022 -säädöksen nojalla. DIU:n vahvuus on nopeus -- palkinnot voivat sulkeutua 60--90 päivässä -- ja sen verkosto, joka yhdistää valittuja yrityksiä operatiivisiin käyttäjiin ja hankintavirastoihin kaikkien puolustushaarojen välillä. Rakenteellinen rajoitus startupille on, että DIU on siirtymismekanismi, ei kestävä rahoittaja. DIU-palkinto todistaa konseptin ja tarjoaa johdannaisbudjettirivi; se ei korvaa palvelun hankintavirastoa, joka omistaa vaatimuksen POM:ssaan.

Arvioitavan minimituotteen rakentaminen hankintavirkailijoille

Minimituote (MVP) hankintaa varten ei ole sama artefakti kuin MVP kaupallista ohjelmistolanseerausta varten. Kaupalliset MVP:t on suunniteltu testaamaan markkinahypoteesia maksavilla varhaisilla omaksujilla. Puolustushankintojen MVP:iden on tyydytettävä erilaisia arvioijia -- hankintavirkailijoita, ohjelmajohtajia, operatiivisia testaajia ja tietoturvaarvioijia -- joilla kullakin on erilaiset vaatimukset, joita mikään yksittäinen arviointikehys ei täysin kata.

Hankintavirkailijan on varmistettava, että ehdotettu hinta on oikeudenmukainen ja kohtuullinen ja että toimittaja on vastuullinen (eli sillä on taloudellinen, tekninen ja johtamiskapasiteetti suoritukseen). Tämä tarkoittaa, että MVP:tä on seurattava karkea suuruusluokan (ROM) kustannusrakenne, jota yritys pystyy puolustamaan tarkastelun alaisena, CAGE-koodi ja SAM.gov-rekisteröinti sekä vähintään yksi aiempi suoritusreferenssi -- jopa kaupallisesta tai liittolaismaiden ohjelmasta -- joka osoittaa yrityksen toimittaneen vastaavia töitä. RFP:stä sopimukseen etenevän prosessin ymmärtäminen auttaa startupeja valmistelemaan tämän dokumentaation ennen kuin sitä pyydetään, ei 72 tunnin vastaamisajan paineessa.

Ohjelmajohtajan on varmistettava, että teknologia vastaa dokumentoituun kykyaukkoon ja että integraatiotaakka hallitukselle on hallittavissa. MVP, joka edellyttää hankintavirastoa muokkaamaan olemassa olevia C2-järjestelmiä, uudelleenkouluttamaan operaattoriväestöä tai ylläpitämään kahta rinnakkaista datakäytävää, lisää siirtymiskustannusta, jonka ohjelmajohtajan on perusteltava ylemmälle viranomaiselle. Hankintakelpoisimmat MVP:t liittyvät olemassa oleviin datastandardeihin (CoT, STANAG, Link 16, NIEM) ilman väliohjelmistoa, jota hallituksen on erikseen rahoitettava ja ylläpidettävä. Jokainen integraatioriippuvuus, jonka startup poistaa MVP:stään, vähentää kitkakustannusta, jonka hankintaviraston on kannettava tuotteen puolestapuhumiseksi.

Tietoturva-akkreditoinnin aikataulut ja niiden lyhentäminen

Tietoturva-akkreditointi -- käyttöluvan (Authority to Operate, ATO) hankkiminen DoD:n riskienhallintakehyksen (RMF) mukaisesti -- on johdonmukaisimmin aliarvioitu aikatauluelementti puolustusalan startupin hankintasuunnitelmassa. Ensikertalaiset ATO-hakijat budjetoivat rutiininomaisesti 6 kuukautta ja saapuvat kuukaudelle 18 odottaen edelleen valtuuttavan virkamiehen allekirjoitusta. Viivästykset eivät johdu siitä, että tuote olisi turvaton; ne johtuvat siitä, että hallintatoimenpidedokumentaatio on puutteellinen, järjestelmän rajaus on huonosti määritelty tai arviointiorganisaatiolla ei ole kapasiteettia aikatauluttaa tietoturva-arviointia ennen kuukausia dokumentaatiopaketin toimittamisen jälkeen.

Nopeimmat ATO:t rakentuvat esivaltuutetun isännöintiperustasta perityille hallintatoimenpiteille. Jos tuote toimii infrastruktuuri-palveluna (IaaS) -ympäristössä, jolla on jo DoD Impact Level 2 tai Impact Level 4 -väliaikainen lupa -- AWS GovCloud East, Azure Government tai vastaava -- startup perii merkittävän osan NIST SP 800-53 -hallintatoimenpidejoukosta pilvipalveluntarjoajan olemassa olevasta lupakäytöstä. Startupin arviointi kattaa tällöin vain ne hallintatoimenpiteet, joita ei peritä: sovelluskerroksen hallintatoimenpiteet, konfiguraatiohallinta, pääsynhallinta ohjelmistotasolla ja tietoluokitustasoon liittyvät overlay-hallintatoimenpiteet. Hyvin rajattu pilvinatiivi tuote voi vähentää itsenäisten hallintatoimenpiteiden toteutusjoukkonsa koko 325 hallintatoimenpiteen NIST 800-53 Rev 5 -perustasosta 80--120 sovelluskohtaiseen hallintatoimenpiteeseen, lyhentäen arviointikestoa suhteellisesti.

Toinen kiihdytysvipuvarsi on dokumentaatiokuri tuotekehityksen ensimmäisestä päivästä alkaen. RMF edellyttää järjestelmän tietoturvasuunnitelmaa (SSP), joka kuvaa, miten jokainen sovellettava hallintatoimenpide on toteutettu. SSP:n kirjoittaminen jälkikäteen tuotteelle, joka on rakennettu ilman tietoturva-arkkitehtuuridokumentaatiota, on hidasta ja virhealtista; sen kirjoittaminen samalla kun tuotetta rakennetaan -- DevSecOps-käytänteillä, jotka tuottavat jatkuvaa vaatimustenmukaisuusnäyttöä -- pelkistää SSP:n toimitukselliseksi tehtäväksi forensisen rekonstruktion sijaan. Startupeja, jotka instrumentoivat CI/CD-käytäntönsä OSCAL-muotoisella hallintatoimenpidedatalla ja automaattisella vaatimustenmukaisuusskannauksella, voivat esittää arvioijalle koneluettavat näyttöpaketit, jotka lyhentävät arviointisuunnitteluvaiheen viikoista päiviksi.

Hankintaviraston puolestapuhujan löytäminen: suhteet ennen tarjouksia

Mikään hankintapolku ei tuota sopimusohjelmaa ilman valtion työntekijää, joka on valmis puolustamaan teknologiaa hankintaviraston sisällä silloin, kun toimittaja ei ole paikalla. Tuo henkilö -- puolestapuhuja -- ei löydy pelkästään tarjouslähetysten tai teollisuuspäiviin osallistumisen kautta. Puolestapuhujia viljellään pysyvällä, teknisesti uskottavalla vuorovaikutuksella 12--24 kuukauden ajan, joka osoittaa, että startup ymmärtää operatiivisen ongelman yhtä hyvin kuin mikä tahansa vakiintunut päähankkija.

Luotettavin reitti puolestapuhujan tunnistamiseen kulkee operatiivisten käyttäjien kautta, ei hankintavirastojen kautta. Ohjelmajohtaja, joka saa johdonmukaisesti positiivista palautetta sotilaallisista loppukäyttäjistä, jotka ovat käyttäneet tuotetta -- jopa epävirallisessa arviointikontekstissa tai harjoituksissa -- on huomattavasti motivoituneempi puolustamaan budjettiriviä kuin sellainen, joka on vain lukenut kykytiivistelmän. Tämä tarkoittaa, että startupien tulisi investoida pääsyyn operatiivisiin harjoituksiin, sotapeleihin ja koalitiotapahtumiin, joissa niiden teknologiaa voidaan testata todellisilla operaattoreilla, jopa ilman virallista sopimuskehystä. Näiden kosketuspisteiden palautesilmukat tuottavat operaattoreiden tukisuositukset, joita ohjelmajohtajat käyttävät uusien alkuvaiheen pyyntöjen perustelemiseen ohjelmajohtajille.

Koalitio- ja NATO-hankinta: lisäkerrokset ja valmistelu

Puolustusalan startup, joka on todistanut tuotteensa yhdessä kansallisessa markkinassa, kohtaa rakenteellisesti erillisen joukon vaatimuksia tavoitellessaan koalitio- tai NATO-hankintaa. Teknologia saattaa olla identtinen, mutta juridiset, tietoturva- ja yhteentoimivuusvaatimukset moninkertaistuvat jokaisen lisämaan myötä. Yritykset, jotka lähestyvät koalitiohankintaa olemassa olevan sopimustrategian yksinkertaisena maantieteellisenä laajentamisena, aliarvioivat johdonmukaisesti tarvittavan valmistelun ja menettävät aikaa juuri sillä hetkellä, kun niiden first-mover-etu on arvokkainta.

Vientilainsäädäntö on ensimmäinen ratkaistava rajoite. Yhdysvalloissa kehitetty ohjelmisto tai laitteisto, jolla on puolustussovellus, on International Traffic in Arms Regulations (ITAR)- tai Export Administration Regulations (EAR) -valvonnan alainen. Startup, joka ei ole selvittänyt tuotteensa Export Control Classification Number (ECCN) -numeroa ja hankkinut tarvittavia lupia ennen brittien, saksalaisten tai suomalaisten hankintavirastojen lähestymistä, luo oikeudellisen riskin sekä itselleen että ulkomaisen hallituksen vastapuolelle. Vientiluokitteluanalyysi tulisi suorittaa ennen ensimmäistä tapaamista ulkomaisen hankintaviraston kanssa, ei kiinnostuskirjeen vastaanottamisen jälkeen.

NATO:n yhteisrahoitteiselle hankinnalle NATO Support and Procurement Agencyn (NSPA) kautta tuotteen on täytettävä sekä hankkijamaan tietoturvavaatimukset että sovellettavat NATO:n tietoturvapolitiikat. Tämä johtaa kaksoisakkreditointipolkuun -- kansallinen ATO sekä NATO-akkreditointi -- jotka voivat edetä rinnakkain, mutta edellyttävät koordinointia kahden tietoturvan hallintarakenteen välillä, jotka eivät jaa dokumentaatioformaatteja tai arviointiaikatauluja. Tähän tilaan siirtyvien startupien tulisi selvittää, tukeeko niiden arkkitehtuuri erillisiä kansallisia instansseja vai moniasiakas-käyttöönottoa kryptografisesti pakotetulla tietojen erottelulla, koska vastaus määrittää, voidaanko yksi akkreditointipaketti mukauttaa maiden välillä vai on erilliset paketit rakennettava kullekin. NSPA:n sopimusaikataulu uuden alkuvaiheen kykysopimusten osalta on 24--36 kuukautta alkuperäisestä vaatimuksesta palkintoon, mikä on otettava huomioon kassavirran suunnittelussa alusta alkaen.

Konseptinäytöksestä täyteen käyttöönottoon: siirtymäriskin hallinta

Siirtymäriski -- riski siitä, että onnistuneesti pilotoitu teknologia ei saavuta operatiivista mittakaavaa -- on ensisijainen syy, miksi hankintavirastot epäröivät sitoutua sopimusohjelmaan startup-toimittajan kanssa. Epäröinti ei ole irrationaalista. Hankintavirastot, jotka ovat investoineet uusiin alkuohjelmiin pienillä toimittajilla, ovat kokeneet teknologian katkeamisen, kun toimittaja on loppunut rahasta, tuotesuunnat ovat mitätöineet alkuperäisen kykyarvioinnin, ja integraatioviat ovat ilmaantuneet vasta täyden mittakaavan käyttöönoton aikana. Näiden riskien nimenomainen käsitteleminen siirtymäsuunnitteludokumenteissa on tehokkaampaa kuin vakauden väittäminen kykytiivistelmissä.

Tietooikeusväite on operatiivisesti merkittävin asiakirja siirtymäsuunnitelmassa. DFARS 252.227-7013 -säädöksen nojalla hallituksella on oikeus valtion tarkoituksen oikeuksiin tekniseen dataan, joka on kehitetty sekarahoituksella -- mutta näiden oikeuksien laajuus riippuu siitä, miten startup dokumentoi riippumattoman tutkimus- ja kehitystoimintansa (IR&D) investoinnin kehittämishetkellä. Startup, joka ei ole ylläpitänyt samanaikaisia asiakirjoja siitä, mitkä tuotekomponentit on kehitetty yrityksen IR&D-rahoituksella verrattuna valtion rahoitukseen, havaitsee vaikeaksi väittää oikeuttaan rajoitettuihin oikeuksiin, joihin sillä on oikeus, ja saattaa vahingossa myöntää hallitukselle laajemmat tietooikeudet kuin tarkoitettu. Päinvastoin, startup, joka väittää liian laajoja rajoitettuja oikeuksia valtion rahoittamaan kehitykseen, luo sopimusriidan, joka viivästyttää siirtymää. Oikea lähestymistapa on ylläpitää rahoitettua IR&D-ohjelmaa dokumentoiduilla menoilla, väittää sekarahoitusoikeuksia suppeasti ja tarkasti, ja neuvotella lisenssirakenne, joka antaa hallitukselle riittävän datapääsyn kilpailuttamista varten sopimuksen päättyessä siirtämättä startupin ydinimmateriaalioikeuksia.

Ylläpitosuunnittelu saa pilotin aikana vähemmän huomiota kuin se ansaitsee, ja kuilu näkyy siirtymässä. Sopimusohjelma edellyttää kyvyn lisäksi määriteltyä tukistruktuuria: logistinen tukianalyysi (tai ohjelmistolle vastaava), ohjelmiston tukisuunnitelma, kyberturvallisuuden ylläpitostrategia ja -- käyttöönotetulle laitteistolle -- varaosaverkosto ja huoltoketju. Startupeja, jotka esittävät nämä artefaktit hankintaviraston katselmuksessa ennen kuin niitä pyydetään, osoittavat institutionaalista valmiutta, joka erottaa ne kilpailijoista, jotka käsittelevät ylläpitoa sopimuksen jälkeisenä ongelmana. Operatiivinen käyttäjä, joka tuki pilottia, pidetään vastuussa tukirakenteesta, joka seuraa. Tuon vastuutaakan vähentäminen on yksi tehokkaimmista tavoista vahvistaa puolestapuhujasuhdetta siirtymävaiheen aikana.