Puolustusohjelmiston kokonaiskustannus: hankintaopas

Puolustusohjelma budjetoi 2,4 miljoonaa euroa tilannekuvajärjestelmälle. Kaksi vuotta käyttöönoton jälkeen kokonaiskulut ovat 6,1 miljoonaa euroa. Erotus – 3,7 miljoonaa euroa – ei koskaan kuulunut mihinkään budjettiriviin. Se kertyi integrointityöstä, koulutuskierroksista, kolmesta tietoturvan uudelleenakkreditointisyklistä, suuresta versiosiirtymästä ja omistusoikeudellisesta väliohjelmistosta, jonka toimittaja vaati mutta ei koskaan ilmoittanut alkuperäisessä tarjouksessa.

Tämä kaava on riittävän yleinen ollakseen rakenteellinen eikä satunnainen. Puolustusohjelmiston kokonaiskustannus (TCO) aliarvioidaan johdonmukaisesti ja joskus dramaattisesti hankintavaiheessa – ei siksi, että hankintahenkilöstö olisi huolimaton, vaan siksi, että hankinta-aikaan käytetty kustannusmalli on suunnitelmallisesti puutteellinen. Tämä opas tarjoaa kehyksen puolustettavan TCO-arvion rakentamiseen ennen sopimuksen myöntämistä.

Miksi puolustusohjelmiston TCO aliarvioidaan järjestelmällisesti

Kaupallisessa ohjelmistohankinnassa hankintakustannus ja TCO ovat riittävän lähellä toisiaan, että toisen käyttäminen toisen sijaisarvona on perusteltua. Integrointiympäristö on suhteellisen standardisoitu, koulutuspohja on yleinen työvoima ja ylläpitotahti noudattaa ennakoitavia kaupallisia normeja.

Puolustushankinta toimii erilaisessa ympäristössä jokaisen näistä ulottuvuuksista. Integrointikerros yhdistää luokiteltuihin verkkoihin, omistusoikeudellisiin sotilaallisiin dataformaatteihin ja vuosikymmeniä vanhoihin perintöjärjestelmiin, jotka edeltävät moderneja API-käytäntöjä. Koulutuspohja koostuu sotilaallisista operaattoreista, joilla on määritellyt rooliprofiilit ja korkea vuotuinen vaihtuvuus. Ylläpitoprosessi sisältää tietoturvan uudelleenakkreditoinnin ennen kuin korjauspäivitystä voidaan ottaa käyttöön luokitellussa järjestelmässä – prosessi, joka lisää viikkoja tai kuukausia jokaiseen päivityssykliin.

Rakenteellisesti ongelmaa pahentaa se, miten puolustusbudjetit on järjestetty. Hankintakustannus näkyy hankintabudjetissa. Integrointityö näkyy ohjelmistotoimiston insinööribudjetissa. Koulutus näkyy yksikön koulutusjakaumassa. Kestävyys näkyy monivuotisessa ylläpitorivissä, josta neuvotellaan erikseen alkuperäisestä sopimuksesta. Yhdellä ainoalla budjetinomistajalla ei ole näkyvyyttä kaikkiin neljään. Tuloksena on, että toimittajat voittavat johdonmukaisesti alhaisella hankintakustannuksella ja palauttavat sitten katteen kustannusten kautta, joita kukaan ei budjetoinut.

Viisi TCO-komponenttia ja niiden painotus

Täydellinen puolustusohjelmiston TCO-malli kattaa viisi kustannusluokkaa. Niiden suhteellinen paino vaihtelee ohjelman mukaan, mutta alla oleva jakauma heijastaa tyypillisiä 10 vuoden ohjelmia, joita on havaittu eurooppalaisessa puolustushankinnassa:

Hankintakustannus (15–25 % 10 vuoden TCO:sta)

Tämä on luku toimittajan tarjouksessa: lisenssimaksut, tilausmaksut, käyttäjäkohtaiset maksut ja kertamaksut käyttöönotolle. Pysyvissä lisensseissä tämä on pääosin ensimmäisen vuoden kustannus. Tilausmalleissa projisoi vuosimaksu eteenpäin toimittajan sopimusmukaisella hinnannousun ylärajalla – tyypillisesti 3–8 % vuodessa puolustusohjelmistolle – ja diskontoi nykyarvoon ohjelman elinkaaren aikana.

Seuraa käyttäjäkohtaista hinnoittelua, joka skaalautuu odottamattomasti. Alusta, jonka hinta on 40 000 euroa vuodessa 50 käyttäjälle, voi saavuttaa 320 000 euroa vuodessa, jos ohjelma laajenee 400 käyttäjään koalition kautta. Mallinna realistinen käyttäjäkatto, ei pilottikäyttöönoton henkilömäärää.

Integrointikustannus (25–35 % 10 vuoden TCO:sta)

Integrointi on yksittäisin suurin TCO:n aliarviointilähde puolustusohjelmissa. Se kattaa työ- ja infrastruktuurikustannukset, jotka tarvitaan uuden ohjelmiston liittämiseksi olemassa olevaan operatiiviseen ympäristöön: C2-järjestelmät, sensorisyötteet, tiedustelukannat, logistiikka-alustat, identiteettihallinta ja verkkoinfrastruktuuri.

Puolustusintegrointi ei ole hyödyketyötä. Jokainen yhteyspiste sisältää mukautetun tietomuunnoksen (sotilaalliset dataformaatit eivät ole REST-ystävällisiä), tietoturvakerroksen välityksen (jokainen yhteys luokitusrajojen yli vaatii kryptografisen erottamisen) ja testauksen elävämpää tai edustavaa operatiivista dataa vasten. Toimittajan integrointidokumentaatio on kirjoitettu kaupallisille ympäristöille. Sen mukauttaminen luokiteltuun puolustusympäristöön tyypillisesti kertoo dokumentoidun vaivan 1,5–2-kertaiseksi.

Koulutuskustannus (20–30 % ensimmäisen vuoden TCO:sta; 10–15 % vuosittain sen jälkeen)

Alkukoulutus kattaa operaattorit, järjestelmänvalvojat ja tietoturvahenkilöstön. Kolmen yksikön keskikokoisessa käyttöönotossa tämä tyypillisesti kattaa 400–800 henkilötyötuntia opetusta plus opettajan ja tilojen yleiskustannukset. Hankinta-arvioista johdonmukaisesti puuttuva luku on toistuva koulutuskustannus, jota ajaa henkilöstövaihtuvuus.

Operatiiviset sotilasyksiköt vaihtavat 20–35 % henkilöstöstä vuosittain. 200 aktiivisen käyttäjän järjestelmässä tämä tarkoittaa, että 40–70 uutta operaattoria tarvitsee koulutuksen vuosittain – toistaiseksi, ohjelman koko elämän ajan. Koulutusmateriaalit vaativat myös ylläpitoa: jokainen suuri ohjelmistoversiomuutos mitätöi olemassa olevat materiaalit ja vaatii dokumentaation tarkistussyklin, jota toimittajat eivät rahoita eivätkä harvoin tue.

Ylläpito- ja tukikustannus (20–30 % 10 vuoden TCO:sta)

Puolustusohjelmiston vuotuiset ylläpitomaksut ovat tyypillisesti 15–22 % alkuperäisestä lisenssikustannuksesta vuodessa. Nämä maksut kattavat toimittajapuolen korjauspäivitysten kehittämisen ja tuen käytön. Ne eivät kata sisäistä työtä, jota tarvitaan näiden korjauspäivitysten validointiin, testaukseen ja käyttöönottoon luokitellussa ympäristössä – prosessi, joka on huomattavasti kalliimpi kuin kaupallinen vastine uudelleenakkreditointivaatimusten vuoksi.

SLA-tasot merkitsevät enemmän puolustuksessa kuin kaupallisissa yhteyksissä, koska seisokin seuraukset ovat operatiivisia. Arvioi tukivasteaikasitoumus P1-tapahtumille, toimittajan dokumentoitu tukikapasiteetti (henkilöstömäärä ja eskalointipolku) ja pitkäaikaisen tuen ikkunan pituus suhteessa ohjelman operatiiviseen elämään. Toimittaja, joka tarjoaa 5 vuoden tuen 15 vuoden ohjelmalle, luo rakenteellisen aukon, johon hankintasopimukset harvoin puuttuvat.

Kehityskustannus (10–20 % 10 vuoden TCO:sta)

Puolustusohjelmistot käyvät läpi vähintään kaksi suurta versiosiirtymää 10 vuoden elinkaarensa aikana. Jokainen siirtymä luokitellussa ympäristössä sisältää: siirtotyön, uudelleenakkreditoinnin (tietoturvatarkastus ja virallinen lupa uuden version käyttöön), uudelleenkoulutuksen ja integroinnin uudelleentestauksen. Toimittajan ammatilliset palvelut siirtotukea varten on rutiinisti aliarvioitu alkuperäisissä arvioissa, koska siirron monimutkaisuus ei ole täysin tiedossa sopimuksen myöntämishetkellä.

Budjetoi uudelleenakkreditointivaraus 40–80 % alkuperäisestä integrointivaivasta kutakin suurta versiosiirtymää kohden. Tämä on luku, joka useimmiten puuttuu ohjelmistotoimiston arvioista.

Integrointikustannusmalli: työmäärän arviointi ennen sopimuksen myöntämistä

Ennen sopimuksen myöntämistä tehty integrointikustannusarvio on väistämättä epätarkka, mutta suuruusluokka-arvio on paljon parempi kuin ei arviota lainkaan. Seuraava malli tarjoaa jäsennellyn lähtökohdan.

Anna kullekin integrointipisteelle API-monimutkaisuuspisteet 1–5 neljän tekijän perusteella: protokollan monimutkaisuus (REST/JSON saa 1; mukautetut binääriprotokollat saavat 5), todentamisvaatimukset (API-avain saa 1; molemminpuolinen TLS PKI-infrastruktuurilla saa 4–5), tietomuunnoksen monimutkaisuus (suora kenttäkartoitus saa 1; semanttinen kääntäminen tietomallien välillä saa 4–5) ja SDK:n saatavuus (toimittajan tarjoama SDK saa 1; ei dokumentaatiota saa 5).

Perustyöarvio on: (monimutkaisuuspisteet × 20 tuntia) per päätepiste, plus kiinteä lisäys 80 tuntia tietoturvatarkastukselle per integrointipiste luokitellussa ympäristössä, plus 40 tuntia hyväksyntätestaukselle per päätepiste. Järjestelmälle, jossa on 8 integrointipistettä ja keskimääräinen monimutkaisuuspiste 3, perusarvio on (3 × 20 × 8) + (80 × 8) + (40 × 8) = 480 + 640 + 320 = 1 440 tuntia ennen varakerrointa.

Käytä 1,3–1,5-kertaista varakerrointa luokitellulle infrastruktuurille, jossa työkalujen käyttö, verkon segmentointi ja hyväksymisprosessit rajoittavat tuottavuutta. Oikaistu arvio 1 872–2 160 tuntia (noin 12–14 henkilötyökuukautta) on realistinen suunnitteluluku keskiraskaalle puolustusjärjestelmäintegraatiolle.

Koulutuskustannus: toistuvan kuorman mallintaminen

Koulutuskustannuksen mallintaminen alkaa roolierottelusta. Kaikilla käyttäjillä ei ole samaa koulutusvaatimusta. Operaattorit tarvitsevat toiminnallista koulutusta omista työnkuluistaan. Järjestelmänvalvojat tarvitsevat täyden alustan koulutuksen mukaan lukien tietoturvakonfiguraation. Tietoturvahenkilöstö tarvitsee akkreditointispesifistä koulutusta järjestelmän tietoturvaominaisuuksista ja auditointimenettelyistä.

200 operaattorin, 10 ylläpitäjän ja 3 tietoturvahenkilön käyttöönotolle perus ensimmäisen vuoden koulutusbudjetti voisi näyttää tältä: 200 operaattoria 16 tunnin verran (3 200 tuntia), 10 ylläpitäjää 40 tunnin verran (400 tuntia), 3 tietoturvahenkilöä 24 tunnin verran (72 tuntia), plus opettajan ja materiaalikustannukset – yhteensä noin 3 700 henkilötyötuntia suoraa opetusta lisäkustannuksineen.

Toistuva vuosikustannus 25 % vaihtuvuudella on 50 operaattoria 16 tunnilla (800 tuntia) plus suhteellinen ylläpitäjien ja tietoturvahenkilöstön vaihtuvuus – noin 900 tuntia vuodessa. 10 vuoden ohjelman elinkaaressa toistuva koulutustyö ylittää alkuperäisen koulutusinvestoinnin vuoteen 4 mennessä. Ohjelmat, jotka budjetoivat vain alkukoulutukseen, löytävät tämän epäsuhdan kolmantena tai neljäntenä toimintavuotenaan.

Koulutusmateriaalien ylläpito on erillinen budjettirivi. Jokainen suuri ohjelmistojulkaisu – tyypillisesti 18–24 kuukauden välein – vaatii materiaalien tarkistamisen. Budjetoi 200–400 tuntia teknistä kirjoitusta ja opetussuunnittelua per suuri julkaisusykli.

Ylläpito ja tuki: SLA-tasot ja toimittajan elinkelpoisuusriski

Tuki-SLA:n arviointi puolustusohjelmistolle vaatii kolmen ulottuvuuden tarkastelua, jotka standardit kaupalliset hankintalistat jättävät huomioimatta.

Ensimmäinen on korjaustahti suhteessa uudelleenakkreditoinnin yleiskustannuksiin. Toimittaja, joka julkaisee tietoturvakorjauksia kuukausittain, luo kuukausittaisen uudelleenakkreditointitaakan luokitelluille käyttöönotoille. Neljännesvuosittainen korjaustahti – hätäkorjauksilla kriittisille CVE:ille – on operatiivisesti yhteensopivampi luokiteltujen käyttöönottoon liittyvien rajoitteiden kanssa. Arvioi toimittajan historiallinen korjausjulkaisutaajuus organisaatiosi akkreditointikapasiteettia vasten.

Toinen on toimittajan elinkelpoisuusriski. Eurooppalaisilla markkinoilla oleviin puolustusohjelmistotoimittajiin kuuluu merkittävä osuus pieniä ja keskikokoisia yrityksiä, joilla on rajallinen taloudellinen syvyys. Toimittaja, jolla on 40 työntekijää ja joka tarjoaa kriittistä alustaa, edustaa keskittymisriskiä: avainhenkilöriippuvuus, yritysostoriski ja mahdollinen tuotteen hylkääminen. Arvioi toimittajan taloudellinen terveys, omistusrakenne ja pitkäaikaiset tukisitoumukset sopimuksessa. Lähdekoodin escrow on vakioturvamekanismi – toimittaja tallettaa lähdekoodin ja rakennusohjeet neutraalin escrow-agentin luokse, ja luovutus käynnistyy määriteltyjen jatkuvuustapahtumien perusteella.

Kolmas ulottuvuus on avoimen lähdekoodin komponenttialtistus. Useimmat puolustusohjelmistot sisältävät avoimen lähdekoodin kirjastoja, joiden ylläpito on yhteisörahoitteista. Merkittävät avoimen lähdekoodin komponentit, joiden yhteisötuki on vähenemässä, luovat tulevaisuuden kustannuksen: joko toimittaja ottaa sisäisen ylläpitokustannuksen (joka lopulta virtaa tukimaksuihin) tai komponentista tulee tietoturvariski. Pyydä ohjelmiston materiaaliluettelo (SBOM) ja tarkastele keskeisten avoimen lähdekoodin riippuvuuksien kuntoa osana toimittajan due diligence -prosessia.

Yksityiskohtaisemman kehyksen toimittajakykyjen arviointiin ennen sopimuksen myöntämistä löydät artikkelista puolustusohjelmiston toimittajan arviointi: hankintahenkilöstön tekninen due diligence -opas.

Rakentaminen vs. ostaminen vs. COTS: milloin mukautettu kehitys voittaa TCO:ssa

Vakio-hankintaoletus on, että COTS (commercial off-the-shelf) -ohjelmisto on halvempaa kuin mukautettu kehitys, koska se jakaa T&K-kustannuksen monien asiakkaiden kesken. Tämä oletus pitää kaupallisissa ympäristöissä ja murtuu tietyissä puolustuskonteksteissa.

Mukautettu kehitys on TCO-kilpailukykyinen COTS:n kanssa, kun kolme ehtoa täyttyy samanaikaisesti. Ensinnäkin COTS-tuotteen tietomalli on arkkitehtonisesti yhteensopimaton tietuejärjestelmän kanssa, vaatien väliohjelmistokerroksen, joka on itsessään merkittävä ohjelmistoprojekti. Väliohjelmistokerros lisää integrointikustannusta, ylläpitokustannusta ja yhden vikapisteen – eikä se näy COTS-toimittajan hinnoittelussa. Toiseksi COTS-tuotteen omistusoikeudellinen integrointikerros luo toimittajalukituksen, joka yhdistyy ajan myötä: tulevat versiosiirtymät ovat toimittajan siirtotyökalujen panttivankeja, ja vaihtoehtoiset toimittajat kohtaavat saman väliohjelmisto-ongelman alusta. Kolmanneksi toiminnallinen laajuus on kapea ja vakaa. Mukautettu työkalu, joka tekee yhden asian hyvin – esimerkiksi raiteiden fuusio tietyn tyyppiselle sensorille – voidaan rakentaa, testata ja ylläpitää pienellä tiimillä alhaisemmin 10 vuoden kustannuksin kuin laaja COTS-alusta, jossa on 80 % käyttämätöntä toiminnallisuutta.

Risteyspistolaskelma: jos COTS-integrointityö ensimmäisenä vuonna ylittää 150 % lisenssikustannuksesta ja vuotuinen ylläpitomaksu on yli 20 % lisenssistä ja ohjelman elinikä ylittää 8 vuotta, mallinna mukautettu kehitys kilpailevana vaihtoehtona ennen sopimuksen myöntämistä. Vertailun on sisällettävä täydet mukautetun kehityksen kustannukset (ei vain alkurakentaminen – jatkuva ylläpito, tietoturvakorjaukset ja kehitys) projisoituina saman horisontin yli.

Ohjelmille, joissa COTS on oikea valinta mutta hankintaehdot vaativat huolellista rakentamista, puolustushankinnan opas tarjouspyynnöstä sopimukseen kattaa sopimusrakenteet, jotka suojaavat sopimuksen jälkeiseltä kustannusten nousulta.

Mallin kokoaminen: käytännön esimerkki

Harkitaan taktista tiedustelun fuusioalustaa, joka hankitaan prikaatitason esikunnalle. Toimittajan tarjous on 1,8 miljoonaa euroa 5 vuoden lisenssistä 150 käyttäjälle. Täydellinen TCO-malli 10 vuoden ohjelmaelinajalle:

Hankinta (10 vuotta): Vuosien 1–5 lisenssi 1,8 milj. €, uusintavuodet 6–10 arvioitu 2,2 milj. € (3 % vuotuinen korotus). Yhteensä: 4,0 milj. €.

Integrointi: 10 integrointipistettä keskimääräisellä monimutkaisuuspisteellä 3,5 ja luokitellun infrastruktuurin varakerroin 1,4. Arvioitu 2 100 työtuntia 120 €/tunti kuormitetulla hinnalla. Plus infrastruktuuri (väliohjelmistopalvelin, tietoturvalaitteisto): 180 000 €. Yhteensä: 432 000 €.

Koulutus (10 vuotta): Alkukoulutus 3 700 henkilötyötuntia 85 €/tunti = 315 000 €. Vuotuinen toistuva koulutus 80 000 €/vuosi × 9 vuotta = 720 000 €. Materiaalien ylläpito 3 suurta julkaisusykliä 35 000 € kukin = 105 000 €. Yhteensä: 1,14 milj. €.

Ylläpito ja tuki (10 vuotta): Vuotuiset tukimaksut 18 % alkuperäisestä lisenssistä (324 000 €/vuosi) × 10 = 3,24 milj. €. Sisäinen korjausten hallintakustannus 60 000 €/vuosi = 600 000 €. Yhteensä: 3,84 milj. €.

Kehitys (2 suurta päivitystä): Siirtotyö 2 × 1 000 tuntia 120 €/tunti = 240 000 €. Uudelleenakkreditointi 2 × 600 tuntia 120 €/tunti = 144 000 €. Yhteensä: 384 000 €.

10 vuoden TCO: noin 9,8 miljoonaa euroa suhteessa päähankintatarjoukseen 1,8 miljoonaa euroa. Hankintakustannus edustaa 18 % kokonaisohjelmakustannuksesta. 82 % lopusta ei koskaan ollut toimittajan tarjouksessa.

Hankinnan rakentaminen TCO:n hallitsemiseksi

TCO-malli on hyödyllinen ennen sopimuksen myöntämistä. Sopimuksen myöntämisen jälkeen kustannusten hallinta riippuu sopimusrakenteesta. Useat mekanismit vähentävät huomattavasti sopimuksen jälkeistä kustannusnousuriskiä.

Tilausten korotuksen hintakatot estävät vuotuisten maksunousujen yhdistävän vaikutuksen pitkissä ohjelmaelinkaarissa. Integroinnin ammatillisten palveluiden hinnat tulisi kiinnittää sopimuksen myöntämishetkellä, ei jättää tulevaan neuvotteluun, kun toimittajalla on vipuvarsi. Koulutusmateriaalien omistajuuden tulisi siirtyä hankintaorganisaatiolle – toimittajan omistamat koulutusmateriaalit ovat toistuva kustannuskeskus. Siirtotukivelvoitteet tulee määritellä: mitä toimittaja tarjoaa, millä hinnalla, kutakin suurta versiosiirtymää varten. Ja pitkäaikaisten tukiikkunasitoumusten tulee olla selkeitä – toimittaja, joka sitoutuu 10 vuoden tukeen sopimuksen myöntämishetkellä, on olennaisesti erilainen kuin toimittaja, joka sitoutuu 5 vuoteen uusinnalla toimittajan harkinnan mukaan.

TCO-mallinnus ei ole takuu kustannusten ylitysten välttämisestä. Ohjelmat muuttuvat, vaatimukset kehittyvät ja toimittajat ostetaan. Mutta täydellisellä kustannuskuvalla tehty hankintapäätös – eikä hankintakustannuksen sijaisarviolla – lähtee rakenteellisesta tietoisuudesta eikä rakenteellisesta sokeudesta.