Puolustusohjelmistoyritykset, jotka rakentavat tilannekuva-alustoja, C2-työkaluja tai ISR-analytiikkaa, huomaavat yhä useammin, että niiden pätevimmät prospektit ovat ulkomaisia sotilasasiakkaita: liittolais- ja kumppanimaita, jotka modernisoivat joukkojaan ja ovat valmiita maksamaan kyvykkyydestä, joka ylittää sen, mitä kotimaiset puolustusteollisuudet pystyvät tarjoamaan. Kaksi oikeudellista kanavaa yhdistää yhdysvaltalaiset toimittajat näihin asiakkaisiin: Foreign Military Sales (FMS), jossa Yhdysvaltain hallitus toimii välittäjänä ja myy toimittajan puolesta, ja Direct Commercial Sales (DCS), jossa toimittaja tekee sopimuksen suoraan ulkomaisen ostajan kanssa vientiluvan nojalla. Oikean kanavan valitseminen ja sen ymmärtäminen, mitä kukin niistä edellyttää dokumentoinnin, vaatimustenmukaisuusvelvoitteiden ja pitkäaikaisten tukisitoumusten osalta, on teknisesti yhtä vaativaa kuin itse ohjelmisto. Tämä artikkeli käsittelee molempia kanavia perusteellisesti, kiinnittäen erityistä huomiota vientivalvontamaisemaan, joka ohjaa jokaista puolustusohjelmistokauppaa.
FMS vs Direct Commercial Sales: kumpi kanava sopii tuotteellesi
FMS:n ja DCS:n rakenteellinen ero määrää kaiken jatkossa: hinnoittelun joustavuuden, neuvotteluvaran, toimitusaikataulut, vastuualtistumisen ja sen, missä määrin Yhdysvaltain hallitus seisoo kaupan takana. FMS:n alaisuudessa ulkomainen hallitus lähettää Letter of Requestin (LOR) Yhdysvaltain puolustusministeriölle, DoD arvioi pyynnön ulkopolitiikan ja turvallisuuden kriteerejä vasten, ja jos se hyväksytään, DoD antaa Letter of Offer and Acceptancen (LOA) ostajamaalle. Tämän jälkeen asianomainen Yhdysvaltain asevoimien haara (maa-, meri- tai ilmavoimat) tekee sopimuksen toimittajan kanssa, ei suoraan ulkomainen asiakas. Yhdysvaltain hallitus on virallinen myyjä, ja toimittaja on alihankkija tähän järjestelyyn.
DCS poistaa hallitusvälittäjän. Toimittaja hakee vientilupaa ulkoministeriöltä (ITAR-valvotulle ohjelmistolle) tai kauppaministeriöltä (EAR-valvotulle ohjelmistolle), ja hyväksynnän jälkeen neuvottelee ja allekirjoittaa kaupallisen sopimuksen suoraan ulkomaisen puolustusministeriön tai sen nimeämän pääurakoitsijan kanssa. Tämä antaa toimittajalle paljon enemmän hallintaa hinnoitteluun, immateriaalioikeusehtoihin ja toimitusaikatauluihin. Toimittaja kuitenkin ottaa kantaakseen myös kaupan täyden oikeudellisen riskin, mukaan lukien vastuun loppukäytön rikkomuksista sekä velvollisuuden suorittaa oma sopimusta edeltävä due diligence asiakkaan oikeutuksesta ja aiotusta käytöstä.
Käytännön päätös riippuu kahdesta tekijästä: ohjelmistosi herkkyysluokituksesta ja ostajamaan suhteesta Yhdysvaltain turvallisuusyhteistyöohjelmiin. Ohjelmisto, joka on vakaasti US Munitions Listillä (USML) ja jonka siirto edellyttää kongressi-ilmoitusta tiettyjen arvokynnysten yläpuolella, kulkee lähes aina FMS:n kautta: ulkoministeriö on haluton myöntämään DCS-lupia Category XI -kohteille (sotilaselektroniikka ja -ohjelmistot), kun FMS-kanava on olemassa ja tarjoaa vahvemman hallituksen valvonnan. Uudemmat kaksikäyttöalustat, joilla on selkeä ECCN EAR:n nojalla, ovat elinkelpoisempia DCS-ehdokkaita, erityisesti kumppanimaille, joilla on Blanket Purchase Order -järjestelyt tai olemassa olevat DCS-puitteet yhdysvaltalaisten toimittajien kanssa. Ohjelmistoyritykselle, joka ei ole vielä navigoinut kummassakaan kanavassa, FMS on pienemmän riskin sisääntulopiste juuri siksi, että Yhdysvaltain asevoimien haaran tapauspäällikkö kantaa suuren osan vaatimustenmukaisuustaakasta.
Letter of Offer and Acceptance: rakenne ja ohjelmistokohtaiset lausekkeet
LOA on oikeudellinen väline, joka määrittelee, mitä myydään, mihin hintaan, millä ehdoilla ja millä ylläpitositoumuksilla. Ohjelmistotuotteen osalta LOA-rakenne eroaa merkittävästi pelkästään laitteistoa koskevasta kaupasta. Laitteistorivit kuvaavat fyysisiä lopputuotteita ja niihin liittyviä ammuksia tai varaosia. Ohjelmistorivin on kuvattava aineetonta toimitusta: tietty versio tai rakennelman perustaso, sen lisensointimalli, ulkomaiselle asiakkaalle myönnettyjen käyttöoikeuksien laajuus sekä ehdot, joilla päivityksiä ja korjauksia toimitetaan tarjousjakson aikana.
Ohjelmistokohtaiset LOA-lausekkeet, joita toimittajat usein kohtaavat luonnoksen tarkastuksessa, kattavat neljä aluetta. Ensinnäkin versiolukko: LOA määrittää tarjottavan ohjelmistoversion, ja ilman muutosta ulkomainen asiakas saa kyseisen version ja sen suoran korjauslinjan, ei tulevaa pääjulkaisua, joka voi kantaa eri ECCN:ää tai edellyttää uutta politiikkatarkastelua. Toimittajien tulisi neuvotella kielestä, joka sallii pienet päivitykset samassa versioperheessä ilman uutta LOA:ta. Toiseksi ylläpitohinnoittelun rakenne: ohjelmiston ylläpito hinnoitellaan lähes aina erikseen toistuvana rivinä, tyypillisesti vuosittain uudistettavana, eikä upotettuna hankinnan yksikkökustannukseen. Tämä on operatiivisesti oikein, mutta edellyttää toimittajalta hinnoittelunäkyvyyden ylläpitämistä viidestä kymmeneen vuoden aikajänteellä P&A-vaiheessa. Kolmanneksi lähdekoodin käyttö: Yhdysvaltain hallituksen politiikka kieltää yhdenmukaisesti lähdekoodin käytön tarjoamisen ulkomaisille asiakkaille FMS:n alaisuudessa, ellei erityistä Technology Assistance Agreementia (TAA) neuvotella ja hyväksytä. Toimittajien tulisi varmistaa, että heidän LOA-kielensä nimenomaisesti ilmaisee tämän rajoituksen sen sijaan, että se jätettäisiin epäselväksi. Neljänneksi kolmannen osapuolen lisenssivelvoitteet: jos ohjelmistosi sisältää avoimen lähdekoodin komponentteja copyleft-lisensseillä tai kaupallisia kolmannen osapuolen kirjastoja, LOA:n on otettava huomioon, miten nuo lisenssit siirtyvät ulkomaiselle asiakkaalle, joka ottaa kantaakseen samat käyttörajoitukset, jotka koskevat mitä tahansa lisenssinhaltijaa.
LOA sisältää myös tyypillisesti kertaluonteisen suunnittelutyön (NRE) rivin, jos jotain maakohtaista räätälöintiä vaaditaan: lokalisointi, käyttöliittymän mukauttaminen maakohtaisille C2-järjestelmille tai integrointi vanhaan infrastruktuuriin. Toimittajien tulisi käsitellä NRE:tä erillisenä neuvoteltuna kohteena ylläpidosta, koska NRE-kustannukset ovat kertaluonteisia ja niiden perustelu edellyttää eri dokumentaatiota kuin toistuva ylläpitohinnoittelu.
Loppukäytön valvonnan vaatimukset viedylle puolustusohjelmistolle
Yhdysvaltain hallitus ylläpitää kahta rinnakkaista loppukäytön tarkastusohjelmaa viedyille puolustustarvikkeille: Golden Scepter FMS-tapauksille ja Blue Lantern DCS-lisensoiduille kohteille. Molemmat ohjelmat suorittavat toimituksen jälkeisen todentamisen vahvistaakseen, että siirrettyjä kohteita, mukaan lukien ohjelmistot, käytetään valtuutetusti, niitä ei ole siirretty valtuuttamattomille kolmansille osapuolille ja ne ovat Yhdysvaltain hallituksen edustajien tarkastettavissa. Ohjelmistotoimittajille nämä ohjelmat luovat jatkuvia vaatimustenmukaisuusvelvoitteita, jotka ulottuvat selvästi toimituspäivän yli ja edellyttävät sisäisiä kirjanpitojärjestelmiä, joita useimmilla kaupallisilla ohjelmistoyrityksillä ei oletusarvoisesti ole.
Golden Scepterin alaisuudessa Defense Security Cooperation Agency (DSCA) koordinoi ostajamaan Yhdysvaltain suurlähetystön Security Cooperation Officen kanssa määräaikaisen loppukäytön todentamisen suorittamiseksi. Ohjelmiston osalta todentaminen tarkoittaa tyypillisesti varmistusta siitä, että ohjelmisto on asennettu vain valtuutetuille paikoille, sitä käyttävät vain tarkastettu henkilöstö LOA:ssa määritellyllä käyttötasolla, eikä valtuuttamattomia kopioita ole jaeltu. Toimittajan odotetaan tekevän yhteistyötä toimittamalla käyttöönottokirjaukset: asennuspaikkojen osoitteet, käyttäjämäärät rooleittain, käyttöönotettu versio ja korjausten toimitushistoria. Tarkastusten tiheys on riskiin suhteutettu: korkeamman herkkyyden ohjelmisto maissa, joilla on vähemmän kypsät turvallisuusyhteistyöhistoriat, saa useammin huomiota. Toimittajat, jotka eivät pysty tuottamaan riittäviä kirjauksia tarkastushetkellä, kohtaavat mahdollisia korjaavia toimenpiteitä, mukaan lukien lupien rajoitukset tuleville tapauksille.
Käytännön mutkikkuus ohjelmistotoimittajille syntyy, kun tuote käyttää telemetriaa, pilvikytkettyä lisensoinnin valvontaa tai automaattisia päivitysmekanismeja. Nämä ominaisuudet, jotka ovat vakiona kaupallisessa ohjelmistossa, voivat luoda tahattomia datavirtoja ulkomaisen asiakkaan verkon ja toimittajan infrastruktuurin välille, joita ei paljastettu LOA:ssa ja jotka voivat rikkoa ostajamaan tietoturvapolitiikkoja tai joissakin tapauksissa Yhdysvaltain rajoituksia ulkomaisten hallintojärjestelmien tuottaman datan siirtämisestä. Ennen minkäänlaisen kotiinsoittotoiminnallisuuden käyttöönottoa ulkomaiselle puolustusasiakkaalle toimittajien tulisi hankkia nimenomainen hyväksyntä DSCA:lta ja ostajamaan turvallisuusviranomaiselta sekä dokumentoida hyväksytyt datavirrat LOA:n tai Technical Assistance Agreementin täydennykseen.
Teknologiansiirron rajoitukset: mitä voit ja et voi sisällyttää FMS-pakettiin
Teknologiansiirron rajoitukset ovat teknisesti merkittävin rajoite, jonka FMS ja DCS asettavat ohjelmistotoimittajille. Termi "teknologia" ITAR:ssa ja EAR:ssa kattaa lähdekoodin lisäksi myös tekniset tiedot: suunnitteludokumentit, arkkitehtuurikaaviot, koneoppimismallien koulutusdatan, algoritmispesifikaatiot, jotka ovat riittävän yksityiskohtaisia replikoinnin mahdollistamiseksi, sekä operatiiviset parametrit, jotka luonnehtivat ohjelmiston suorituskykyaluetta. Toimittajat aliarvioivat usein sen laajuuden, mikä muodostaa valvottua teknologiaa, ja luovat tahattomasti vaatimustenmukaisuusaltistumista tarjoamalla yksityiskohtaisia teknisiä esittelyjä ulkomaisen asiakkaan teknisille tiimeille varmistamatta, että esittelymateriaalit kuuluvat hyväksytyn viennin laajuuteen.
FMS:n alaisuudessa myydylle ohjelmistolle oletusasento on, että ulkomainen asiakas saa objektikoodin (käyttöönotettava binääri tai konttikuva) ja vain käyttäjätason dokumentaation. Lähdekoodi, AI-komponenttien koulutusdatajoukot, omistusoikeudellisten koneoppimiselementtien mallipainot ja API-spesifikaatiot integrointitasolla edellyttävät kaikki erillisiä teknologian luovutushyväksyntöjä. Toimittajien, jotka haluavat tarjota näitä elementtejä, esimerkiksi mahdollistaakseen ulkomaisen asiakkaan kehittävän maakohtaisia integrointeja, on pyydettävä Release of Technology DSCA:n tapauspäällikön kautta, joka ohjaa pyynnön asianomaisen Yhdysvaltain asevoimien haaran teknologiaturvallisuuden tarkasteluprosessin läpi. Tämä tarkastelu arvioi, voisiko teknologian luovutus mahdollistaa vastaanottajan replikoida kyvykkyyden kotimaassa, siirtää sen kolmanteen maahan tai johtaa suorituskykytietoa, joka paljastaisi Yhdysvaltain tiedusteluprioriteetit.
Keskeinen oivallus: Yleisin teknologiansiirron rikkomus puolustusohjelmistojen viennissä ei ole tahallinen; se on liian yksityiskohtaisen teknisen integrointiesittelyn toimittaminen ulkomaisen asiakkaan insinööritiimille ilman virallista teknologian luovutushyväksyntää. Esittely, joka käy läpi sisäiset dataskeemat, mallin päättelyputket tai RF-signaalinkäsittelyalgoritmit riittävän yksityiskohtaisesti, jotta pätevä insinööri voisi toistaa lähestymistavan, muodostaa valvotun teknologian siirron ITAR:n nojalla, riippumatta siitä, jaettiinko lähdekoodia. Toimittajien tulisi perustaa esittelyä edeltävä tarkasteluprosessi, joka luokittelee jokaisen teknisen esityksen hyväksyttyä vientilaajuutta vasten ennen kuin se toimitetaan maassa.
Kolmannen maan siirron rajoitukset ovat siihen liittyvä huolenaihe. Jos ostajamaa ottaa ohjelmiston käyttöön monikansallisessa operaatiossa, jossa muiden kuin hyväksyttyjen maiden henkilöstöllä on pääsy siihen, mikä on yleistä koalitioympäristöissä, joissa liittolaismaat jakavat yhteisen tilannekuvan, toimittajan on varmistettava, että LOA tai DCS-lupa kattaa kyseisen paljastamisen. FMS-tapaus, joka hyväksyttiin maan A kansalliseen käyttöön, ei automaattisesti valtuuta altistumista maan B henkilöstölle, joka toimii maan A joukkojen rinnalla. DSCA:n tapauspäällikkö voi lisätä kolmannen maan siirtomääräyksen LOA:han, mutta tätä on pyydettävä ennen altistumista, ei sen jälkeen.
Maassa annettavan tuen velvoitteet ja kolmannen maan siirtosäännöt
FMS-ohjelmistotapaukset sisältävät lähes aina tukielementin, joka edellyttää toimittajan tarjoavan henkilöstöä ostajamaassa. Tämä tuki ottaa useita muotoja: alkuasennus- ja konfigurointituki, joka toimitetaan järjestelmän kenttäänsijoittamisen yhteydessä, käyttäjä- ja järjestelmänvalvojakoulutus sekä jatkuva help desk- tai kenttähuoltoedustajan (FSR) kattavuus ylläpitojaksolla. Kukin näistä edellyttää suunnittelua hyvissä ajoin ennen LOA:n allekirjoittamista, koska maassa toimivat tukihenkilöt kohtaavat omat vaatimustenmukaisuusvaatimuksensa, jotka voivat vaikuttaa rekrytointiin, matkustamiseen ja turvallisuusselvitysten aikatauluihin.
Kenttähuoltoedustajilla, jotka työskentelevät FMS-tapauksissa ulkomailla, on oltava Yhdysvaltain turvallisuusselvitykset järjestelmän luokituksen edellyttämällä tasolla. Jos ohjelmistoa ajetaan turvaluokitellussa verkossa ostajamaassa, FSR voi myös tarvita henkilöturvallisuusmäärityksen ostajamaan turvallisuusviranomaiselta, prosessin, joka voi kestää kolmesta kahteentoista kuukautta eikä sen onnistumista taata. Toimittajien tulisi tunnistaa FSR-ehdokkaat varhain ja käynnistää selvitysprosessi rinnakkain LOA-neuvottelun kanssa sen sijaan, että odotettaisiin LOA:n allekirjoittamista. Allekirjoitettu LOA, jota ei voida toteuttaa, koska toimittajalta puuttuu selvitetty maassa toimiva tukihenkilöstö, on ohjelmaepäonnistuminen, joka aiheuttaa merkittävää suhdevahinkoa sekä DSCA:n tapauspäällikön että ulkomaisen asiakkaan kanssa.
Kolmannen maan siirtosäännöt vaikuttavat myös maassa annettavaan tukeen. Jos toimittajan FSR on kaksoiskansalainen, hänellä on passi maasta, jolla on rajoituksia ostajamaan turvallisuuskehyksessä, tai hän on syntynyt maassa, jonka LOA nimeää rajoitetuksi kansallisuudeksi pääsylle järjestelmään, lisähyväksyntöjä vaaditaan ennen kuin kyseinen henkilö voi työskennellä ohjelmassa. Näitä sääntöjä ei aina dokumentoida itse LOA:han: ne johdetaan ostajamaan turvallisuusvaatimusten, Yhdysvaltain hallituksen teknologian luovutuspolitiikan tietyn ohjelmiston osalta sekä verkon luokituksen yhdistelmästä, jossa ohjelmistoa ajetaan. Toimittajien tulisi pyytää kansallisuustarkastelua DSCA:n tapauspäälliköltä osana käyttöönottoa edeltävää suunnittelua, ei viime hetken tarkastuksena.
Price and availability -pyynnöt: miten vastata sitoutumatta
Price and Availability (P&A) -pyyntö saapuu Yhdysvaltain asevoimien haaran tapauspäälliköltä, kun ulkomainen hallitus on toimittanut Letter of Requestin ohjelmistollesi. P&A-vastaus on perusta, jonka pohjalta DoD laatii LOA:n, mikä tarkoittaa, että tässä vaiheessa antamasi numerot ilmestyvät, usein sanasta sanaan, oikeudellisesti sitovaan tarjoukseen ulkomaiselle hallitukselle. Menettelyllinen ansa toimittajille, jotka eivät tunne FMS:ää, on P&A-vastauksen kohteleminen kaupallisena tarjouksena, joka on neuvottelun alainen. Se ei ole sitä. Kun LOA on annettu ulkomaiselle hallitukselle P&A-tietojesi pohjalta, olet sopimuksellisesti sidottu toimittamaan kyseisillä ehdoilla, jos asiakas hyväksyy.
Oikea lähestymistapa P&A-vastaukseen on antaa paras arviosi kustannuksista nimenomaisin olettamuksin, jotka on dokumentoitu vastaukseen: ohjelmistoversio, lisensointimalli, käyttäjämäärä, koulutuksen laajuus, ylläpitojakso ja mahdollinen maakohtaisen räätälöinnin laajuus. Jos jokin kustannuselementti riippuu vaatimuksesta, jota ei ole vielä määritelty (esimerkiksi asennuspaikkojen lukumäärä), merkitse tuo riippuvuus nimenomaisesti ja tarjoa vaihteluväli tai yksikkökohtainen hinta kokonaissumman sijaan. DSCA:n tapauspäälliköt ymmärtävät, että ohjelmistohinnoittelulla on muuttuvia komponentteja, ja sisällyttävät olettamuksesi LOA:han alaviitteinä, jotka pätevöittävät hinnoittelun. Tämä suojaa sinua, jos todellinen käyttöönottolaajuus eroaa P&A-olettamuksista.
Toimittajien tulisi myös käsitellä ohjelmiston ylläpitohinnoittelua vähintään viiden vuoden aikajänteellä P&A-vastauksessa, vaikka alkuperäinen pyyntö kattaisi vain kahden vuoden jakson. Ulkomaiset asiakkaat laajentavat rutiininomaisesti ylläpitotapauksia, ja DSCA:n tapauspäälliköt suosivat alkuperäisen LOA:n rakentamista uusimisvaihtoehdoilla sen sijaan, että käsiteltäisiin erillisiä muutostapauksia joka vuosi. Jäsennellyn ylläpitohinnoitteluaikataulun tarjoaminen, jossa on määritellyt korotusasteet ja selkeät määritelmät siitä, mitä kullakin tasolla sisältyy, tekee tuotteestasi helpomman hallita FMS-järjestelmän läpi ja vähentää hallinnollista taakkaa, joka jarruttaa toistuvaa liiketoimintaa kanavan kautta.
Suhteiden rakentaminen maassa toimivaan ohjelmatoimistoon ja Yhdysvaltain country teamiin
FMS-prosessi on muodollisesti hallitusten välinen, mutta lopputulokset, mitkä tuotteet kirjoitetaan Letters of Requestiin, mitkä toimittajat sisällytetään P&A-sykleihin ja mitkä ylläpitotapaukset rahoitetaan, muovautuvat suhteista, jotka rakennetaan hyvissä ajoin ennen kuin mikään muodollinen prosessi alkaa. Kaksi keskeistä suhdesolmua ohjelmistotoimittajalle ovat ulkomaan ohjelmatoimisto ja Yhdysvaltain Security Cooperation Office (SCO) Yhdysvaltain suurlähetystössä ostajamaassa.
Maassa toimiva ohjelmatoimisto on tekninen auktoriteetti, joka määrittelee vaatimukset, arvioi kilpailevia ratkaisuja ja ajaa sisäisesti rahoitusta FMS-tapauksen toteuttamiseksi. Puolustusohjelmiston osalta ohjelmatoimisto sijaitsee tyypillisesti puolustusministeriön J6:ssa (viestintä- ja tietojärjestelmät) tai vastaavassa direktoraatissa, tai erikoistuneessa kyvykkyysdirektoraatissa ISR:lle, logistiikalle tai C2:lle. Toimittajilla, jotka ovat osoittaneet kyvykkyytensä ohjelmatoimistolle ennen LOR:n toimittamista, esittelytapahtumien, Yhdysvaltain hallituksen Building Partner Capacity -ohjelmien rahoittamien arviointien tai kahdenvälisiin harjoituksiin osallistumisen kautta, on merkittävä etu vaatimusdokumentin muovaamisessa vastaamaan tuotteensa arkkitehtuuria. Tämä ei ole prosessin manipulointia; se on tavanomainen tapa, jolla kyvykkäät toimittajat luovat teknistä uskottavuutta ulkomaisten asiakkaiden kanssa ennen muodollista hankintaa.
SCO on Yhdysvaltain hallituksen linkki ostajamaan ja DoD:n FMS-järjestelmän välillä. SCO-upseerit ovat tyypillisesti maa-, meri- tai ilmavoimien henkilöstöä, joka on määrätty suurlähetystöön kahdesta kolmeen vuoden komennuksille. He koordinoivat Letters of Requestiä, helpottavat P&A-syklejä ja hallinnoivat suhdetta ulkomaisen ministeriön ja Washingtonissa olevan DSCA:n tapauspäällikön välillä. Tuottavan työsuhteen rakentaminen SCO:n kanssa tarkoittaa heidän pitämistään ajan tasalla tuotekartastasi, kyvykkyyspäivitysten merkitsemistä, jotka voisivat vastata uusiin asiakasvaatimuksiin, ja teknisen tuen tarjoamista arvioinneille, joita SCO helpottaa. Toimittajat, jotka kohtelevat SCO:ta hallinnollisena välittäjänä eivätkä sisällöllisenä kumppanina, menettävät mahdollisuuden muovata sitä, miten heidän tuotteensa asemoidaan maan laajemmassa turvallisuusyhteistyöportfoliossa. Ohjelmistoyritykselle, joka tavoittelee useita FMS-tapauksia useiden maiden välillä, SCO-verkosto on yhtä lailla jakelukanava kuin se on vaatimustenmukaisuusrajapinta, ja näihin suhteisiin investoiminen on yksi korkeimman tuoton aktiviteeteista, jotka ovat hankintasykliä läpikäyvän puolustusohjelmistoyrityksen käytettävissä.
Jäsennä ohjelmistosi ulkomaisille puolustusasiakkaille
Corvus Intelligencella on kokemusta ohjelmistokäyttöönottojen jäsentämisestä ulkomaisille puolustusasiakkaille. Ota meihin yhteyttä keskustellaksesi, miten FMS- ja DCS-vaatimukset vaikuttavat tuotteeseesi ja tukimalliisi.
Tämän analyysin laativat Corvus Intelligencen insinöörit, jotka rakentavat kriittisiä ISR- ja kenttäsovelluksia puolustus- ja viranomaisorganisaatioille. Lue lisää tiimistämme →