Puolustusteknologian arviointimenetelmä hankintatiimeille

Puolustushankintapäätökset epäonnistuvat toistuvasti ei siksi, että hankintatiimi teki huonoja valintoja, vaan siksi, että näiden valintojen pohjana ollut arviointiprosessi oli rakennettu kaupallista IT:tä varten. Teknologia, joka toimii hyvin toimittajan esittelyssä, läpäisee pintapuolisen kykytarkistuksen ja näyttää kilpailukykyiseltä ominaisuusmatriisissa, voi silti tuottaa epäonnistuneen ohjelman — koska se ei integroidu olemassa olevaan järjestelmäympäristöön, koska sen todellinen kokonaiskustannus on kaksi tai kolme kertaa tarjoushinta, kun toteutus ja hyväksyntä otetaan huomioon, tai koska sen väitetyt kyvyt heikentyvät käyttökelvottomiksi todellisten operatiivisten olosuhteiden verkko- ja anturirajoitusten alaisena.

Tiukka puolustusteknologian arviointimenetelmä käsittelee tätä epäonnistumistapaa suoraan. Se korvaa esittelypohjaiset arvioinnit jäsennellyllä, vaiheistetulla prosessilla: operatiivisten vaatimusten kartoittaminen mitattaviksi teknisiksi spesifikaatioiksi, kykyaukkojen analysointi hankkivan organisaation olemassa olevan stackin suhteen, toimittajamarkkinan katsastaminen kovia kriteerejä vastaan, teknisen arvioinnin suorittaminen ennalta määritellyillä pisteytyssäännöillä, integraatioriskin systemaattinen pisteytys ja kokonaiskustannusten laskeminen koko ohjelman elinkaaren ajalta. Tässä artikkelissa kuvataan jokainen vaihe soveltamisen edellyttämällä syvyydellä.

Miksi teknologia-arvioinnit ovat tärkeämpiä kuin esittelyt

Toimittajaesittelyt on suunniteltu suotuisiin tuloksiin. Ympäristö on hallittu, data on siistiä, kuorma on hallittavissa ja skenaario on harjoiteltu. Esittelyolosuhteet vastaavat rajoitetusti olosuhteita, joita käyttöön otettu järjestelmä kohtaa: heikentyneet verkkolinkit, perinteiset integraatiokohteet, jotka eivät tue moderneja API:ja, samanaikaiset käyttäjät korkean tempon operatiivisessa vaiheessa, anturisyötteet kohinan ja keskeytymien kanssa. Esittely vastaa yhteen kysymykseen: voiko tämä kyky olla olemassa? Se ei vastaa kysymykseen, jonka hankintapäätökset todella edellyttävät: voiko tämä kyky olla olemassa luotettavasti meidän ympäristössämme, integroituna meidän järjestelmiimme, meidän henkilöstömme käyttämänä ja ylläpidettynä meidän ohjelmahorisonttimme yli?

Arviointimenetelmä on olemassa vastatakseen tähän toiseen kysymykseen. Se tekee sen siirtämällä arviointilinssit toimittajan hallitsemasta esityksestä hankkijan määrittelemiin vaatimuksiin ja tekemällä integraatiokompleksisuudesta ja operatiivisesta todellisuudesta — ei parhaan tapauksen suorituskyvystä — arvioinnin perustan.

Kaksi epäonnistumistapaa esiintyy toistuvasti puolustushankkeissa, jotka ohittivat tiukan arvioinnin. Ensimmäinen on integraation ylikustannus: teknologia toimii esitellyllä tavalla, mutta vaatii kuukausia tai vuosia integrointityötä, jota ei ollut laajuudessa, koska arviointi ei tutkinut ehdokasjärjestelmän API-kypsyyttä, tietoformaattiyhteensopivuutta tai todennusarkkitehtuuria olemassa olevaa ympäristöä vastaan. Toinen on kyvyn inflaatio: toimittajien väitteet "reaaliaikaisesta" suorituksesta, "rajattomasta skaalautuvuudesta" tai "täydellisestä yhteentoimivuudesta" hyväksytään ilman kääntämistä mitattaviksi parametreiksi, eikä käyttöön otettu järjestelmä pysty täyttämään hankintaa ohjanneita operatiivisia vaatimuksia. Molemmat epäonnistumismallit ovat täysin ennustettavissa — ja täysin estettävissä — menetelmällä, joka edeltää sopimusta.

Arviointikehyksen vaiheet

Puolustusteknologian arviointimenetelmässä, joka kuvataan tässä, on viisi vaihetta järjestyksessä: vaatimusten kartoitus, kykyaukkoanalyysi, toimittajamarkkinakatsaus, tekninen arviointi ja integraatioriskipisteytys. Kokonaiskustannusanalyysi kulkee rinnakkain kahden viimeisen vaiheen kanssa. Kullakin vaiheella on määritellyt syötteet, määritelty prosessi ja määritellyt tulokset, jotka syöttävät seuraavaan vaiheeseen. Yhtäkään vaihetta ei voida ohittaa heikentämättä jokaista myöhempää vaihetta.

Vaiheet eivät ole hallinnollisesti täytettävä tarkistuslista. Ne edustavat jäsenneltyä työnkulkua, joka kulkee rinnakkain kaupallisen hankintaprosessin kanssa ja vaatii tyypillisesti kahden tai neljän kuukauden ajan hyvin resursoituneelta ohjelmatyöryhmältä. Tämän ajan sisällyttäminen hankinta-aikatauluun ei ole yleiskustannus — se on mekanismi, joka estää sopimuksen myöntämistä järjestelmälle, joka ei pysty toimittamaan.

Vaatimusten kartoitus: operatiivisesta tekniseen

Vaatimusten kartoitus on vaihe, jonka useimmat hankintaprosessit käsittelevät huonoiten. Epäonnistumistapa on hyvin dokumentoitu: operatiiviset vaatimukset dokumentoidaan operatiivisella kielellä ("komentajat tarvitsevat lähes reaaliaikaisen tilannetietoisuuden yhteisestä operaatioalueesta"), ja tämä kieli välitetään toimittajille ilman kääntämistä teknisiksi spesifikaatioiksi. Toimittajat sitten tulkitsevat vaatimuksia suotuisasti — heidän järjestelmänsä on, heidän määritelmänsä mukaan, lähes reaaliaikainen — eikä arviointi pysty erottamaan ehdokkaita toisistaan.

Vaatimusten kartoitus ratkaisee tämän hajottamalla jokaisen operatiivisen vaatimuksen mitattaviin teknisiin parametreihin. "Lähes reaaliaikainen tilannetietoisuus" muuttuu seuraavaksi: raidan päivitysviive alle 800 millisekuntia verkon reunalla 40% pakettihäviön alaisena; maksimiraidan tiheys 2 000 samanaikaisesta entiteetistä ilman viiveen heikkenemistä; raita-datan vanhentumishälytyskynnys 90 sekunnissa; heikentyneen tilan toiminta ylläpitäen ydinraidan toiminnallisuuden alle 50 kbps:n linkkinopeudella.

Käännösprosessi paljastaa vaatimusten epäselvyyksiä, jotka muutoin tuottaisivat arviointivirheitä. Yleisiä epäselviä termejä puolustusteknologian vaatimuksissa ja niiden ratkaisut:

• "Reaaliaikainen" — vaatii määrittelyn tietyksi viiveen rajaksi (millisekunteja, sekunteja, minuutteja) ja olosuhteet, joissa tämän rajan on pidettävä. C2-raidanpäivityksellä ja logistiikkastatusraportilla on erilaiset reaaliaikaisuusvaatimukset suuruusluokaltaan.
• "Skaalautuva" — vaatii määrittelyn tietyksi käyttäjämääräksi, entiteettimääräksi, datamääräksi tai tapahtumakohdeksi sekä heikkenemiskäyrän (heikkeneekö suorituskyky sulavasti vai klippe-reunaisesti kapasiteetissa?).
• "Yhteentoimiva" — vaatii luetteloinnin niistä tietyistä järjestelmistä, joiden kanssa teknologian on oltava yhteentoimiva, tarvittavista tietovaihdoista sekä tuettavista viestiformaateista tai standardeista. Yhteentoimivuus perintejärjestelmien kanssa on usein vaikein integrointiongelma.
• "Turvallinen" — vaatii määrittelyn luokitustasona, sertifiointistandardina (ISO 27001, asianomainen kansallinen hyväksyntä) ja käyttöönottokontekstin kannalta olennaisina erityisinä turvavalvontavaatimuksina.

Vaatimusten kartoituksen tulos on jäsennelty vaatimusasiakirja, jossa jokainen vaatimus on ilmaistu mitattavana hyväksymiskriteerinä. Tästä asiakirjasta tulee teknisen arviointivaiheen pisteytyspohja ja perusta hyväksymiskriteereille lopullisessa sopimuksessa.

Kykyaukkoanalyysi

Kykyaukkoanalyysi kartoittaa hankkivan organisaation nykyiset kyvyt vaatimusten kartoituksen tuottamaa vaatimuskokonaisuutta vastaan. Sen tarkoitus on kaksitahoinen: vahvistaa, että tunnistetut teknologiaaukot ovat todellisia (eikä niitä ole jo käsitelty olemassa olevilla järjestelmillä tavoilla, joita hankintatiimi ei ole tietoinen), ja priorisoida aukkokokonaisuus niin, että toimittajamarkkinakatsaus ja tekninen arviointi keskittyvät operatiivisesti merkittävimpiin puutteisiin.

Käytännössä kykyaukkoanalyysi paljastaa usein, että jotkut vaatimukset täyttyvät jo olemassa olevilla järjestelmillä, joita käytetään liian vähän, jotka ovat heikosti integroituja tai jotka eivät ole hankintaa ajavan tiimin näkyvissä. Tämän löytäminen ennen sopimuksen myöntämistä on huomattavasti vähemmän kallista kuin löytää se integroinnin aikana. Se myös paljastaa, missä kykyaukot ovat keskenään riippuvaisia — missä yhden aukon sulkeminen uudella teknologialla luo uuden aukon viereisessä järjestelmässä, koska integraatiota ei ennakoitu.

Tuloksena on priorisoitu aukkoluettelo: rankattu lista kykyvajeista operatiivisilla vaikutuspisteillä ja teknisillä parametreilla, jotka määrittelevät, miltä kunkin aukon "suljettu" näyttää. Toimittajamarkkinakatsaus suoritetaan sitten tätä aukkoluetteloa vastaan, ei yleistä ominaisuusmatriisia vastaan.

Toimittajamarkkinakatsaus

Toimittajamarkkinakatsaus tunnistaa ehdokasteknologiat priorisoitua kykyaukkoluetteloa vastaan. Sen tulisi heittää laaja alkuverkko — tyypillisesti 10–20 toimittajaa — ennen paperisuodatuksen soveltamista tunnistamaan ne, jotka soveltuvat yksityiskohtaiseen tekniseen arviointiin.

Paperisuodatus soveltaa kovia kriteerejä, jotka eivät vaadi yksityiskohtaista arviointia: onko toimittajalla osoitettava tietue vertailukelpoisen luokitustason tasolla? Ovatko heillä käyttöönottokontekstin edellyttämät sertifioinnit? Onko heidän ITAR-asemansa yhteensopiva ohjelman liittoumien jakamisvaatimusten kanssa? Onko heidän tuotteensa aktiivisesti ylläpidetty dokumentoidulla tukiikkunalla, joka kattaa ohjelman elinkaaren? Toimittajat, jotka epäonnistuvat jonkin kovan kriteerin suhteen, poistetaan lyhytlistalta tässä vaiheessa — ennen resursseja vaativan teknisen arvioinnin alkamista.

Markkinakatsauksen tulisi hyödyntää muita kuin ilmeisiä lähteitä. Liittoumien ohjelmatoimistoilla on usein arviointikokemusta toimittajista, jotka eivät ole vielä astuneet hankkivan organisaation markkinoille. Riippumattomien testausviranomaisten raportit — silloin kun julkisesti saatavilla — tarjoavat arviointidataa, jota toimittajien markkinointimateriaalit eivät pysty jäljentämään. Puolustusohjelmistotoimittajan arviointikehys tarjoaa yksityiskohtaisen due diligence -tarkistuslistan lyhytlistatuille toimittajille.

Tuloksena on lyhytlista 4–6 tekniseen arviointiin soveltuvasta toimittajasta, dokumentoitu suodatusloki, joka perustelee jokaisen mukaan ottamisen ja poissulkemisen. Dokumentointi ei ole hallinnollinen yleiskustannus — se on hankinta-asiakirja, joka tukee päätöstä, jos sitä riitautetaan.

Teknisen arvioinnin kriteerit

Tekninen arviointi arvioi lyhytlistattuja toimittajia viiden kriteerin perusteella, joista kukin arvioidaan määritellyllä pisteytysmenetelmällä kartoitusvaiheessa tuotetun vaatimusasiakirjan perusteella.

Toiminnallinen täydellisyys on suoraviivaisin kriteeri: suorittaako teknologia vaaditut toiminnot, vaadituilla parametritasoilla, määritellyissä olosuhteissa? Toiminnallinen arviointi tulisi suorittaa testiympäristössä, joka jäljittelee operatiivisia rajoitteita — verkon viive, kaistanleveysrajat, laitteistospesifikaatiot — ei toimittajan suosimassa esittelyympäristössä. Ennalta sovitut hyväksymiskriteerit eliminoivat jälkikäteiset riidat siitä, onko testitulos läpäisy.

Yhteentoimivuus puolustusympäristössä tarkoittaa tiettyjä asioita. Se tarkoittaa tukea viestiformaateille ja viestintästandardeille, joita käytetään viereisten järjestelmien kanssa operatiivisessa ympäristössä: Cursor on Target (CoT) tilannetietoisuusdatan vaihtoon, NATO STANAG -formaatit liittoumapintoja varten, vakiotodennusmekanismit (PKI, SAML 2.0, OAuth 2.0) federoidulle identiteetille. Teknologia, joka tukee vain omistettuja dataformaatteja, vaatii mukautettuja sovittimia, jotka lisäävät integrointikustannuksia, tuovat ylläpitotaakkaa ja luovat haurauspisteitä, joissa operatiivinen ketju voi katketa. Arvioi yhteentoimivuus niitä erityisiä järjestelmiä vastaan, joihin teknologian on yhdistyttävä, ei yleistä standardimyöntyvyystarkistuslistaa vastaan. Liittoumapainotteisille ohjelmille yhteentoimivuuden käsittely JADC2 ja eurooppalaiset toimittajat kattaa asiaan liittyvän standardimaiseman.

Tietoturva-asema kattaa kolme erillistä ulottuvuutta, jotka arviointitiimit usein sekoittavat toisiinsa. Sertifiointistatus (ISO 27001, SOC 2 Type II, asianmukainen kansallinen hyväksyntä) tarjoaa todisteet siitä, että toimittajan organisatorinen tietoturvaprosessi on jäsennelty ja itsenäisesti vahvistettu. Tuotteen tietoturva-arkkitehtuuri — salaus levossa ja siirron aikana, todennusmekanismit, auditilokitus, istunnon hallinta, verkon eristämiskyky — määrittää, voidaanko teknologia ottaa käyttöön vaaditulla luokitustasolla. Haavoittuvuustenhallinnan historia — CVE-vastausajat, korjaushistoria, SBOM-saatavuus — ennustaa tietoturvan ylläpitotaakan ohjelman elinkaaren ajan. Kaikki kolme ulottuvuutta vaativat arviointia; sertifiointistatus yksin on riittämätön.

Skaalautuvuus vaatii kuormitustestausta realistisissa olosuhteissa, ei toimittajan tarjoamia vertailuarvoja. Määrittele huippukuormaskenaario — maksimi samanaikaiset käyttäjät, maksimi entiteettitiheys, maksimi datanläpäisy — ja testaa sitä vastaan. Arvioi heikkenemiskäyrä: heikkeneekö järjestelmä sulavasti kuorman alaisena (viive kasvaa asteittain, toiminnot priorisoituvat) vai klippe-reunaisesti (järjestelmä reagoimaton kynnyksen yläpuolella)? Sulave heikkeneminen on puolustusjärjestelmien operatiivinen vaatimus, joiden täytyy jatkaa toimintaansa olosuhteissa, jotka vievät ne rajojensa lähelle.

Ylläpidettävyys on pitkäjaksoinen huoli, jota lyhyen aikavälin arvioinnit systemaattisesti aliarvioivat. Ylläpidettävyyden indikaattorit: teknisen dokumentaation laatu ja ajankohtaisuus, Software Bill of Materialsin saatavuus, toimittajan korjaushistoria tietoturvahaavoittuvuuksien osalta, arkkitehtuurin modulaarisuus (voivatko komponentit päivittyä itsenäisesti?) ja toimittajan tekniikan tiimin syvyys suhteessa tuotteen monimutkaisuuteen. Teknologia, joka pisteytyy hyvin toiminnallisessa täydellisyydessä mutta heikosti ylläpidettävyydessä, kerryttää teknistä velkaa, josta tulee ohjelmariskiä vuosina 5–15.

Integraatioriskipisteytys

Integraatioriskipisteytys on vaihe, joka jätetään useimmin pois puolustusteknologian arvioinnista — ja sen puuttuminen on yleisin integraation ylikustannusten syy. Teknologia, joka pisteytyy hyvin toiminnallisessa kyvyssä, voi silti kantaa korkeaa integraatioriskiä, joka muuttuu suoraan aikataulun ja kustannusten ylityksiksi sopimuksen myöntämisen jälkeen.

Integraatioriski pisteytetään viiden ulottuvuuden mukaan:

API-kypsyys kattaa toimittajan integrointiliittymien vakauden, dokumentaation laadun ja versioinnin kurinalaisuuden. Kypsä API on versioitu (muutokset signaloidaan ja hallitaan vanhentumisjaksojen yli), dokumentoitu (täydellinen viitedokumentaatio todennuksen, nopeusrajoitusten, virhekoodien ja esimerkkipyyntöjen kanssa) ja vakaa (toimittajalla on historia olla ottamatta käyttöön muutoksia ilman riittävää varoitusaikaa). Epäkypsä API — sisäinen, dokumentoimaton, altis muutoksille pienissä julkaisuissa — luo integrointityötä, joka toistuu joka kerta kun toimittaja päivittää tuotteensa.

Tietoformaattiyhteensopivuus arvioi, miten teknologian datamalli kartoittuu ympäristön olemassa olevien järjestelmien käyttämiin formaatteihin. Vakioidut sotilaalliset viestiformaatit (CoT, NIEM, STANAG 4559 kuvantamiseen, STANAG 5516 taktiselle datalle) ja vakioskeemamäärittelyt vähentävät integrointityötä. Omistetut dataformaatit, jotka vaativat mukautetun muunnoslogiikan, lisäävät integrointityötä ja luovat jatkuvia ylläpitovelvoitteita. Pisteytä ero toimittajan dataformaattien ja ympäristön olemassa olevien dataformaattien välillä integrointityön välillisenä mittarina.

Todennus- ja valtuutusstandardit määrittävät, kuinka monimutkainen federaatio olemassa olevan identiteettiympäristön kanssa on. Vakioprotokollat (SAML 2.0, OAuth 2.0, OpenID Connect, PKI-pohjainen mutual TLS) integroituvat olemassa oleviin identiteettitarjoajiin dokumentoitujen mallien kautta. Omistetut todennusmekanismit, mukautetut tokeniformaatit tai toimittajan hallitsemat identiteettipalvelut vaativat mukautettua integrointityötä ja luovat usein tietoturvatarkistuksen komplikaatioita hyväksymisprosesseissa.

Toimittajalukitusindikaattorit sisältävät: omistetut tallennusformaatit, jotka vaikeuttavat datan purkamista, riippuvuus toimittajan hallitsemasta pilviinfrastruktuurista ydintehtävissä, integrointikerrokset, joita vain toimittaja voi ylläpitää, ja lisenssimallit, jotka rajoittavat hankkivan organisaation kykyä muokata tai korvata komponentteja. Korkeat lukituspisteet ennustavat kohonneet poistumiskustannukset ja vähentyneen ohjelman joustavuuden elinkaaren ajan.

Sisäinen integrointikapasiteetti on rehellinen arvio hankkivan organisaation kyvystä rakentaa ja ylläpitää vaadittuja integraatioita. Teknisesti suoraviivainen integraatio, jota organisaatiolla ei ole taitoa toteuttaa, on korkean riskin integraatio. Arvioi ero integrointivaatimusten ja organisaation nykyisen kapasiteetin välillä ja sisällytä tämän aukon sulkemisen kustannukset — rekrytoinnin, koulutuksen tai ulkoistamisen kautta — TCO-laskelmaan.

Kokonaiskustannus

TCO-analyysi kulkee rinnakkain teknisen arvioinnin ja integraatioriskipisteytyksen kanssa hyödyntäen molempien tuloksia. Puolustusteknologialle TCO ulottuu huomattavasti pidemmälle kuin lisenssikustannus, joka tyypillisesti hallitsee kaupallisia IT-hankintapäätöksiä.

Lisenssikustannus on lähtökohta. Puolustusteknologialle ymmärrä lisensointimalli yksityiskohtaisesti: onko se käyttäjäkohtainen, käyttöönottopohjainen, datamääräpohjainen vai yrityskohtainen? Mitä tapahtuu optiokuorilla? Onko toimittajalla historiaa merkittävistä lisenssihinnannousuista sopimusuusinnan yhteydessä?

Integrointityö on usein suurin TCO-komponentti monimutkaisille puolustushankkeille ja systemaattisimmin aliarvioitu. Rakenna integrointityön arvio integraatioriskipisteistä: korkea API-kypsyysriski ja ei-standardit dataformaatit ennustavat korkeaa integrointityötä. Sisällytä alkuperäinen integraatiokehitys, testaus, hyväksymistuki ja toistuva sovittimen ylläpito toimittajan tuotteen kehittyessä.

Hyväksymiskustannukset ovat ominaisia puolustuskäyttöönotoille. Hyväksyntä vaaditulla luokitustasolla edellyttää tunkeutumistestauksen, konfiguraatioauditoinnin, dokumentaation kehittämisen hyväksymispakettia varten ja asianomaisen hyväksymisviranomaisen tarkistuksen. Nämä kustannukset ovat todellisia, usein huomattavia ja eivät juuri koskaan ilmesty toimittajien TCO-arvioissa. Järjestelmille, jotka käyvät läpi pääversiopäivityksiä, uudelleenhyväksyminen voi olla tarpeen — kustannus, joka yhdistyy ohjelman elinkaaren ajan.

Koulutuskustannukset puolustushankkeissa on otettava huomioon henkilöstön rotaation osalta. Sotilasyksiköt kiertävät henkilöstöä joka 12–24 kuukausi. Teknologia, joka vaatii kaksi viikkoa koulutusta tehokkaaseen käyttöön, on koulutettava jatkuvasti uudelleen — kustannus, joka yhdistyy ohjelman elinkaaren ajan ja vaikuttaa operatiiviseen valmiuteen siirtymäkausina. Teknologiat, joilla on pienempi koulutustaakka ja tehokas kontekstuaalinen ohje, vähentävät tätä toistuvaa kustannusta.

Ylläpito- ja tukikustannukset sisältävät toimittajan tukitasokhinnoittelun ohjelman elinkaaren ajan, sisäiset resurssit toimittajasuhteen hallintaan ja korjausten soveltamiseen sekä kaikki ammattilaispalvelujen kustannukset, joita tarvitaan järjestelmän kehitykseen. Pitkäjaksoisille ohjelmille mallinna tukikustannusten kehitys — toimittaja, jonka tukikustannukset kaksinkertaistuvat pääversiosiirtymissä, esittää erilaisen elinkaaren kustanusprofiilin kuin se, jolla on ennakoitava tukihinnoittelu.

Päivityspolkukustannukset kattavat tekniset ja hyväksymiskustannukset, jotka liittyvät pääversiosiirtymiin ohjelman elinkaaren ajan. Teknologia, jolla on kahden vuoden pääjulkaisusykli, vaatii 7–8 pääpäivitystä 15 vuoden ohjelmassa. Jos jokainen päivitys vaatii osittaisen uudelleenintegroinnin ja osittaisen uudelleenhyväksymisen, kumulatiivinen päivityspolkukustannus on merkittävä TCO-komponentti, jonka ajantasaiset kustannusmallit kokonaan ohittavat.

Esitä TCO-laskelma alueena (optimistinen, perus, pessimistinen) yksittäisen luvun sijaan, ja dokumentoi kunkin skenaarion taustalla olevat oletukset. TCO-vertailut toimittajien välillä ovat hyödyllisempiä kuin absoluuttiset luvut — suhteellinen TCO-profiili paljastaa, millä toimittajalla on alhaisempi elinkaaren kustannusriski, vaikka absoluuttiset luvut sisältävät epävarmuutta.

Arvioinnin syntetisointi hankintapäätökseksi

Koko arvioinnin tulos on kolmiulotteinen päätysviitekehys: toiminnalliset kykypisteet teknisestä arvioinnista, integraatioriskipisteet ulottuvuuksittain ja TCO-profiilit ohjelman elinkaaren ajan. Yksikään ulottuvuus ei ole yksinään riittävä. Teknologia, jolla on erinomainen toiminnallinen pisteytys mutta estävä integraatioriski ja korkea TCO, on huonompi valinta kuin teknologia, jolla on riittävä toiminnallinen pisteytys, matala integraatioriski ja ennakoitava elinkaaren kustannus — erityisesti resurssirajoitetussa ohjelmaympäristössä.

Synteesi paljastaa myös kompromissit, jotka tiedottavat neuvottelustrategiaa ennen sopimuksen myöntämistä. Toimittaja, jolla on korkea integraatioriski mutta kilpailukykyinen toiminnallinen pisteytys, voi olla oikea valinta, jos sopimus edellyttää toimittajan toimittavan integrointityövoiman ja työkalut sopimuksen laajuuden osana. Toimittaja, jolla on vahvat ylläpidettävyysindikaattorit, voi perustella korkeamman lisenssikustannuksen, jos vaihtoehdon integrointi- ja ylläpitotaakka ylittää kustannuseron ohjelman elinkaaren ajan.

Tässä kuvattu menetelmä tuottaa hankinta-asiakirjan — dokumentoidut vaatimukset, suodatuskriteerit, arviointipisteet, integraatioriskipisteet, TCO-analyysi — joka on puolustettavissa auditille, läpinäkyvä päätöksentekijöille ja siirrettävissä henkilöstön vaihtumisen yli. Hankintaympäristössä, jossa arvioinnin suorittanut henkilöstö voi vaihtua ennen kuin järjestelmä saavuttaa täyden operatiivisen valmiuden, kyseinen asiakirja on institutionaalinen muisti siitä, miksi päätös tehtiin ja mitä järjestelmältä odotettiin.

Yksityiskohtaisen toimittajan due diligence -kehyksen osalta, joka syöttää teknisen arviointivaiheen, katso Puolustusohjelmistotoimittajan arviointi: hankintaohjaajan tekninen due diligence -opas. Laajemman hankintaprosessin arkkitehtuurin osalta tarjouspyynnöstä sopimuksen myöntämiseen, katso Täydellinen opas puolustushankintaan.