Puolustusteollisuus kohtaa uudenlaisen tuotekehityshaasteen.

Puolustusalan tuotekehitystä ovat vuosikymmeniä muovanneet pitkät suunnittelusyklit, monimutkaiset hankintamallit, korkeat luotettavuusvaatimukset ja tarkasti hallitut toimittajaekosysteemit. Näille käytännöille on hyvät syyt, sillä puolustusjärjestelmien on toimittava vaativissa oloissa turvallisesti, kestävästi, yhteentoimivasti ja luotettavasti. Usein epäonnistuminen tulee kalliiksi ja voi vaarantaa koko tehtävän onnistumisen.

Samaan aikaan teknologinen kehitys on kiihtynyt. Monet tulevaisuuden puolustuskykyä muovaavista teknologioista kehittyvät nyt perinteisten puolustusohjelmien ulkopuolella: tekoäly, autonomiset koneet, kyberturvan kyvykkyydet, avaruusteknologiat, robotiikka, ohjelmistot ja edistyksellinen sensoriteknologia.

Kehityksen kiihtyvä nopeus luo sekä painetta että mahdollisuuksia.

Puolustusteollisuus voi ottaa oppia parhaista teknologiayhtiöistä. Ne pysyvät lähellä käyttäjiä, keskittyvät todellisiin ongelmiin, kokeilevat nopeasti, ovat avoimia ulkopuolisille ideoille ja oppivat kurinalaisesti ennen kuin mitään skaalataan.

Puolustusyhtiöillä on mahdollisuus yhdistää teknologiayhtiöiden nopeus ja tehtävätason toteutuskyky.

Nopeampi puolustuskyvyn käyttöönotto on strateginen etu

Puolustusteollisuus on siirtynyt aikaan, jossa kyky tuoda uutta teknologiaa nopeasti käyttöön on muodostunut strategiseksi eduksi niin puolustusalan yrityksille kuin niiden asiakkaille.

Kyse ei ole enää vain yksittäisten yritysten, T&K-yksiköiden tai tuotekehitystiimien sisäisestä keskustelusta, vaan se on koko puolustusekosysteemin prioriteetti. NATO ilmoitti kesäkuussa 2025, että liittolaiset olivat hyväksyneet Rapid Adoption Action Plan -toimintasuunnitelman, jonka tarkoituksena on NATOn mukaan merkittävästi nopeuttaa uusien teknologisten tuotteiden käyttöönottoa ja integraatiota puolustuksessa kaikissa sotilaallisissa toimintaympäristöissä. (nato.int)

Aiemmin nopeus oli ennen kaikkea kaupallisten teknologiamarkkinoiden piirre. Nyt siitä on tulossa osa itse puolustuskykyä.

Puolustusalan suuremmilla yrityksillä on vahvuuksia kuten syvä asiakasymmärrys, tehtäväymmärrys, järjestelmäintegraatiokyky, turvallisuusosaaminen, sertifiointikokemus, pitkäaikaiset ylläpitomallit ja kyky toimittaa skaalautuvia ratkaisuja. Nämä vahvuudet ovat edelleen välttämättömiä. Nopeasti muuttuvassa uhka- ja teknologiaympäristössä ne on kuitenkin yhdistettävä lyhyempiin oppimissykleihin, nopeampaan kokeiluun ja parempaan kykyyn hyödyntää ulkoisia innovaatiomahdollisuuksia.

NATOn laajempi innovaatioekosysteemi osoittaa samaan suuntaan. Esimerkiksi DIANA, Defence Innovation Accelerator for the North Atlantic, työskentelee liittokunnan johtavien tutkijoiden ja yrittäjien kanssa kehittääkseen teknologioita, jotka tukevat yhteistä puolustusta ja turvallisuutta. Sen kiihdyttämöt ja testikeskukset sijaitsevat yliopistoissa ja tutkimuskeskuksissa eri puolilla Eurooppaa ja Pohjois-Amerikkaa. (nato.int) 

Perinteisille puolustusalan yrityksille tämä uusi suuntaus luo merkittävän mahdollisuuden.

Ne voivat toimia siltana kahden maailman välillä. Toisella puolella on kaupallisen kehityksen vauhti, luovuus ja teknologinen syvyys, toisella puolustussektorin luottamus, kurinalaisuus, integraatiokyky ja ymmärrys operatiivisista tarpeista.

Tulevaisuudessa pärjäävät yritykset, jotka osaavat yhdistää nopeuden ja luotettavuuden sen sijaan, että valitsisivat niiden väliltä. Ne oppivat riittävän nopeasti vastatakseen uusiin uhkiin ja skaalaavat vain ratkaisuja, jotka ovat turvallisia, kestäviä ja operatiivisesti merkityksellisiä.

Kolme harhaluuloa muutoksen tiellä

Jos mahdollisuus on selvä, miksi muutos on edelleen vaikeaa alan yrityksille ja puolustusorganisaatioille?

Esteet ovat harvoin pelkästään teknisiä. Ne ovat useimmiten rakenteellisia, kulttuurisia ja toimintatapoihin juurtuneita.

Monella puolustusalan yrityksellä on jo käytössään lupaavia teknologioita. Vaikeampaa on viedä ne ideasta kokeiluun, kokeilusta käyttöönottoon ja lopulta asiakkaan operatiiviseen käyttöön.

Kun tuotekehityksen nopeuttamisesta ja avoimuudesta puhutaan, esiin nousee usein muutama vastaväite.

1: “Nopeampi tuotekehitys tarkoittaa suurempia riskejä”

Tämä vastaväite on ymmärrettävä. Puolustusala ei ole kuluttajateknologiamarkkina. Alan yritykset eivät voi vain “liikkua nopeasti ja rikkoa asioita”, kun kyseessä ovat kansallinen turvallisuus, operatiivinen kestokyky ja ihmishenget.

Oppiminen ei silti tarkoita kurinalaisuudesta luopumista. Kokeilujen avulla riskejä voidaan pienentää jo aiemmassa vaiheessa.

Parempi periaate on kokeilla nopeasti oppiakseen ja skaalata vain se, mikä osoittautuu arvokkaaksi, turvalliseksi ja operatiivisesti toimivaksi.

Pienet kokeilut paljastavat heikot oletukset ennen kuin ne kasvavat kalliiksi ohjelmiksi. Varhainen käyttäjätestaus näyttää, vastaako ratkaisu todelliseen operatiiviseen tarpeeseen. Lyhyet oppimissyklit estävät organisaatiota sitoutumasta kalliiseen teknologiaan liian aikaisin.

Puolustusalalla nopeus ei tarkoita hätiköintiä. Kun ratkaisuja kokeillaan varhain, niiden toimivuudesta saadaan näyttöä nopeammin ja päätökset tehdään varmemmin.

2: “Uusien ideoiden täytyy tulla perinteisen toimitusketjun sisältä”

Perinteiset alan toimittajat ja puolustusorganisaatiot ovat edelleen puolustukselle välttämättömiä. Ne ymmärtävät turvallisuusvaatimukset, integraation monimutkaisuuden, pitkäaikaisen ylläpidon, yhteentoimivuuden ja säännellyt toimitusympäristöt.

Jos kehitys rajataan vain alan vakiintuneisiin sisäisiin kanaviin, puolustusorganisaatiot menettävät helposti näkyvyyden teknologioihin, jotka etenevät muualla nopeammin. Tästä on jo hälyttäviä esimerkkejä esimerkiksi droonisodankäynnissä ja muissa miehittämättömissä järjestelmissä.

Avoimuus vaatii selkeät toimintatavat, joilla ulkopuolista osaamista löydetään, arvioidaan ja testataan ennen käyttöönottoa. Näin kehitys pysyy hallinnassa, vaikka ideoita haetaan oman organisaation ulkopuolelta.

Jo rakentumassa oleva puolustusalan ekosysteemi on hybridi: perinteiset päätoimittajat, erikoistuneet toimittajat, kaksikäyttöteknologiayritykset, tutkimuslaitokset, digitaalisen tuotekehityksen yritykset, julkiset innovaatioyksiköt ja liittolaisverkostot työskentelevät aiempaa syvemmin yhdessä tehtäväperusteisten tarpeiden ympärillä.

3: “Onnistunut pilotti muuttuu automaattisesti suorituskyvyksi”

Prototyyppi voi toimia teknisesti, loppukäyttäjät voivat pitää siitä ja pilotti voi näyttää onnistuneelta, eikä se silti muutu todelliseksi suorituskyvyksi. Usein syynä on se, että budjetista vastaavaa tahoa, hankintapolkua, integraatiosuunnitelmaa tai ylläpitomallia ei ole, tai selkeä operatiivinen vastuuhenkilö puuttuu.

Tätä kuvataan usein puolustusinnovaation “kuolemanlaaksona”. RUSI kuvaa sen kuiluna pienten pilottien rahoitukseen saatavilla olevan pääoman ja tuotantovalmiin kyvykkyyden kehittämiseen tarvittavan rahoituksen välillä. (rusi.org)

Siksi puolustusinnovaatio ei voi päättyä ideointiin, pilotteihin tai kiihdyttämöohjelmiin. Käyttöönoton polku on suunniteltava alusta alkaen.

Jokaisen kokeilun pitäisi vastata kahteen kysymykseen:

• Ratkaiseeko tämä todellisen tehtäväperusteisen ongelman?
• Jos se toimii, miten siitä tulee operatiivinen kyvykkyys?

Ilman jälkimmäistä kysymystä kokeiluista tulee helposti pelkkää näytöstä ilman todellista vaikutusta.

HiQ:lla olemme toimineet 30 vuotta teknologian, liiketoiminnan muutoksen ja tehtäväkriittisten digitaalisten järjestelmien risteyskohdassa. Siksi näemme läheltä, millaisia haasteita puolustusteollisuus kohtaa.

Olemme nähneet, miten vaikeaa vakiintuneen organisaation on skaalata tuotekehitystään nopeasti, kun toimintaympäristö muuttuu sen omia prosesseja nopeammin. Pelkkä nopeus ei silti riitä. Kriittisillä toimialoilla tuotekehityksen on jatkossakin oltava turvallista, luotettavaa ja skaalautuvaa sekä kytkeydyttävä todellisiin operatiivisiin tarpeisiin.

Puolustusorganisaatioilla on osaamista ja kunnianhimoa, ja ratkaisemisen arvoisia ongelmia riittää. Ongelma on yleensä se, että asiakkaiden ja kumppaneiden kanssa syntyneet hyvät ideat jäävät käynnissä olevien ohjelmien jalkoihin.

Siksi kannattaa oppia menestyvistä teknologiayhtiöistä ja avoimesta innovaatiosta. Tavoite ei ole tehdä puolustuksesta vähemmän kurinalaista. Se tarvitsee tehokkaampia tapoja oppia, todentaa ja skaalata ratkaisuja.

Viisi askelta puolustusalan tuotekehityksen vauhdittamiseen

Kyse ei siis ole tuotekehityksen puutteesta. Pilotteja, kiihdyttämöitä, teknologiakartoituksia ja lupaavia ideoita on monilla jo runsaasti. Vaikeampaa on viedä ne asiakkaan käyttöön asti valmiiksi puolustusratkaisuiksi.

Se vaatii käytännöllisen toimintamallin, joka lähtee operatiivisista tarpeista, tuo oikeat toimijat yhteen varhain, kokeilee nopeasti ja rakentaa uskottavan polun prototyypistä ohjelmaksi.

Seuraava viisivaiheinen viitekehys on suunniteltu juuri tätä varten.

1: Aloita tehtäväperusteisista ongelmista, älä teknologiaohjelmista

Ensimmäinen askel on määritellä operatiivinen ongelma selkeästi.

Monet tuotekehityshankkeet alkavat teknologiasta: tekoälystä, autonomiasta, data-alustoista, drooneista, kybertyökaluista tai digitaalisista kaksosista. Teknologiat voivat olla vaikuttavia, mutta ne ovat arvokkaita vasta, kun ne ratkaisevat todellisen operatiivisen ongelman.

Parempi olisi kysyä:

• Mitä tehtävän lopputulosta täytyy parantaa?
• Kuka kokee ongelman suoraan?
• Mikä on nykyinen väliaikainen korjaus?
• Mikä tekee ongelmasta kiireellisen?
• Miltä merkittävä parannus näyttäisi 90 päivässä?
• Mikä olisi “riittävän hyvä” ratkaisu testattavaksi oikeilla käyttäjillä?

Nämä kysymykset auttavat siirtämään tuotekehityksen teknologialähtöisyydestä kohti todellisia operatiivisia tarpeita.

Parhaat teknologiayritykset menestyvät pysymällä lähellä asiakkaan kipupisteitä. Puolustusteollisuus pystyy samaan pysymällä lähellä operatiivisia kipupisteitä.

2: Rakenna pieniä, monialaisia tiimejä

Toinen askel on luoda tiimejä, joilla on toiminnan vapaus.

Tuotekehitys hidastuu, kun jokaisen päätöksen on kuljettava usean osaston läpi. Pieni, itsenäisesti päättävä tiimi vähentää kitkaa.

Vahva puolustusalan tuotekehitystiimi voisi sisältää:

• Operatiivisen sponsorin
• Loppukäyttäjiä tai etulinjan edustajia
• Tuote- ja teknologia-asiantuntijoita
• Turvallisuus- ja compliance-asiantuntijoita
• Kaupallista osaamista
• Juridista tukea
• Asiaankuuluvia ulkoisia kumppaneita

Kyse ei ole valvonnan poistamisesta. Oikea asiantuntemus tuodaan mukaan riittävän varhain, jotta se ehtii vaikuttaa siihen, mitä rakennetaan.

Näin yritys voi tehdä parempia päätöksiä nopeammin ja välttää myöhemmän vaiheen yllätyksiä.

3: Käytä nopeita kokeiluja ennen laajamittaisia hankintoja

Kolmas askel on testata oletuksia nopeasti.

Sen sijaan, että edettäisiin suoraan vaatimuksesta suureen ohjelmaan, organisaatiot voivat rakentaa tuotteita ja palveluja lyhyiden oppimissyklien ympärille.

Käytännöllinen lähestymistapa voisi näyttää tältä:

• 30 päivää: Validoi ongelma ja tunnista ratkaisuhypoteesit
• 60–90 päivää: Rakenna prototyyppi tai minimikyvykkyys
• 3–6 kuukautta: Testaa realistisessa operatiivisessa ympäristössä
• Päätöspiste: Skaalaa, muokkaa, pysäytä tai lopeta

Erityisesti digitaalisessa tuotekehityksessä näemme, että syklit ovat jo lyhentyneet edellä kuvatustakin, kun tekoäly nopeuttaa etenkin sovellusprototyyppien kehittämistä. Moni yritys ei vielä edes tiedä, kuinka paljon nopeammin ohjelmistoprototyyppejä voi nykyään rakentaa.

Näin syntyy kurinalainen oppimisen kehä. Samalla pienenee riski panostaa liikaa vääränlaiseen ratkaisuun.

Pilotteja ei ole tarkoitus tuottaa loputtomasti. Olennaista on tunnistaa toimivat ratkaisut ennen kuin sitoudutaan täysimittaiseen toteutukseen.

4: Avaa mahdollisuudet avoimelle innovaatiolle

Neljäs askel on katsoa tavanomaisten organisaatiorajojen ulkopuolelle.

Monet puolustusta muovaavista teknologioista etenevät nopeasti kaupallisilla ja kaksikäyttömarkkinoilla. Puolustusorganisaatiot tarvitsevat toimintatapoja, joilla nämä ulkopuoliset teknologiayritykset löydetään, arvioidaan ja saadaan mukaan yhteistyöhön.

Tämä voi tarkoittaa esimerkiksi:

• Teknologiakartoituksia
• Innovaatiokilpailuja
• Kiihdyttämökumppanuuksia
• Yliopistoyhteistyötä
• Venture-ekosysteemin hyödyntämistä
• Liittolaisverkostojen hyödyntämistä
• Avoimen lähdekoodin yhteisöjä
• Kumppanuuksia digitaalisen suunnittelun ja kehityksen yritysten kanssa
• Yhteistyötä prime-toimittajien ja new defense-toimittajien välillä

Suomessa on jo hienoja esimerkkejä ekosysteemihankkeista, kuten Patrian eAlliance ja Digital Defence Ecosystem.

Perinteisten puolustusalan yritysten rooli on edelleen välttämätön. Ne ymmärtävät integraation, sääntelyn, luotettavuuden, sertifioinnin, turvallisuuden ja pitkäaikaisen ylläpidon. Vaikutus kasvaa entisestään, kun ne kokoavat ja yhteensovittavat eri toimijoiden osaamista sen sijaan, että toimisivat suljettuina.

5: Luo selkeä polku prototyypistä ohjelmaksi

Viides askel on suunnitella käyttöönoton reitti alusta alkaen. Jokaisen kokeilun pitäisi vastata paitsi kysymykseen ”toimiiko tämä?” myös kysymykseen ”miten tästä tulee osa todellista suorituskykyä?”

Tämä tarkoittaa seuraavien asioiden selkeyttämistä:

• Kuka omistaa ongelman?
• Kuka omistaa budjetin?
• Mitä hankinta- tai kaupallista reittiä voitaisiin käyttää?
• Mitkä turvallisuusvaatimukset koskevat ratkaisua?
• Mitä integraatioriippuvuuksia on?
• Mitä koulutus- tai doktriinimuutoksia tarvitaan?
• Millainen ylläpitomalli vaaditaan?
• Mitä näyttöä tarvitaan skaalaamisen perustelemiseksi?

Prototyyppi ilman siirtymäpolkua ei todennäköisesti luo pysyvää vaikutusta.

Operatiivisen ongelman omistajuus

Jos pitäisi nostaa yksi asia, johon puolustusalan yritysten kannattaa aluksi keskittyä, se on selkeä ongelman omistajuus.

Ilman ongelman omistajuutta muu viitekehys alkaa horjua. Innovaatiojohtamisen näkökulmasta hankkeiden hitaus tai epämääräisyys johtuu usein juuri siitä, ettei ongelmalle ole nimetty selkeää, toimivaltaista omistajaa.

Organisaatio voi perustaa innovaatiotiimejä, toteuttaa pilotteja, kartoittaa teknologioita ja rakentaa prototyyppejä. Jos kukaan ei kuitenkaan todella omista operatiivista ongelmaa, kukaan ei tee tarvittavia kompromisseja, varmista resursseja, todenna vaikutusta tai vie ratkaisua kohti käyttöönottoa.

Ongelman omistajuus on enemmän kuin kiinnostusta. Sillä tarkoitetaan nimettyä henkilöä tai tiimiä, joka vastaa tehtävän lopputuloksesta ja on valmis viemään kehitystä eteenpäin löydöksestä käyttöönottoon.

Vahva ongelman omistaja pystyy vastaamaan:

• Miksi tällä ongelmalla on merkitystä juuri nyt?
• Keihin se vaikuttaa?
• Mitä tapahtuu, jos sitä ei ratkaista?
• Mitä rajoitteita ratkaisun on kunnioitettava?
• Millainen parannus oikeuttaisi skaalaamisen?
• Keiden on oltava mukana, jotta käyttöönotto olisi mahdollista?

Kun ongelman omistajuus on selkeä, on paljon helpompaa muodostaa oikea tiimi, houkutella oikeat kumppanit, suunnitella merkityksellisiä kokeiluja ja rakentaa siirtymäpolku.

Teknologiayritysten nopeus ja tehtävätason toteutuskyky

Puolustusteollisuudella on merkittävä mahdollisuus nopeuttaa innovaatiota oppimalla teknologiayhtiöiltä ja avoimista innovaatioekosysteemeistä.

Kaupallisen teknologian kulttuuria ei kuitenkaan kannata tuoda puolustukseen sellaisenaan. Siitä kannattaa soveltaa hyödyllisiä osia: käyttäjäläheisyyttä, nopeaa oppimista, pieniä toimivaltaisia tiimejä, ulkopuolista yhteistyötä ja iteratiivista kokeilua.

Käytännöllinen malli tähän on:

1. Aloita tehtäväperusteisista ongelmista, älä teknologiaohjelmista
2. Rakenna pieniä, monialaisia tiimejä
3. Käytä nopeita kokeiluja ennen laajamittaisia hankintoja
4. Avaa mahdollisuudet avoimelle innovaatiolle
5. Luo selkeä polku prototyypistä ohjelmaksi

Tärkein ensimmäinen askel on luoda selkeä ongelman omistajuus. Kun joku omistaa operatiivisen ongelman, innovaatio kiinnittyy todelliseen tarpeeseen eikä jää abstraktiksi mahdollisuudeksi.

Näin puolustusteollisuus voi edetä nopeammin ja suojella samalla sitä, mikä on tärkeintä: luottamusta, turvallisuutta, luotettavuutta ja tehtävän onnistumista.

Eeppi Nieminen

Senior Advisor, Defence & Security