PoC on halvin tapa olla väärässä – miksi idea kannattaa todentaa ennen kuin siihen investoi
Konseptin todentaminen eli proof of concept (PoC) kertoo, voiko idea toimia, ennen kuin siihen kaadetaan suuria summia. Termiä käytetään kuitenkin nykyään niin löyhästi, että moni PoC todistaa lopulta hyvin vähän. Käymme läpi, mitä konseptin todentaminen oikeasti on, miten se eroaa prototyypistä ja pilotista ja miten sen voi rakentaa siten, että se johtaa parempiin päätöksiin.
Martti Asikainen & Umair Ali Khan | 12.10.2026 | Kuva: Adobe Stock Photos
Kuvitellaan, että yritys hankki tekoälytyökalun käsittelemään asiakkaidensa ostotilauksia. Ensimmäisten asiakkaiden kohdalla kaikki näytti hyvältä. Työkalu toimi kuin junan vessa. Se poimi tilauksen tiedot, haki hinnat asiakkaan hinnastosta ja loi valmiin tilausluonnoksen.
Sitten tuli uusi asiakas. Ja toinenkin. Jokaisella asiakkaalla on oma tilauspohjansa ja hinnastonsa. Tekoälyjärjestelmän sovittaminen niihin vei yritykseltä yllättävän paljon aikaa, eivätkä virheet tuntuneet loppuvan. Lopulta työntekijät huomasivat jotain vielä kiusallisempaa: tekoälyn luonnoksen tarkistaminen vei työntekijöiltä lähes yhtä kauan, ellei jopa kauemmin kuin tilauksen tekeminen käsin.
Tämä tarina ei ole totta, mutta vastaavanlaisia tapauksia on sattunut useita viime vuosina. Lupaava idea siirtyy suoraan diaesityksestä toteutukseen, ja sen heikoin kohta paljastuu vasta siinä vaiheessa, kun korjaaminen maksaa maltaita. Ideat ovat lähtökohtaisesti halpoja, mutta niiden muuttaminen toimiviksi tuotteiksi ei ole.
Näiden kahden välissä on kuitenkin vaatimaton työkalu, joka olisi voinut säästää koko investoinnin: konseptin todentaminen eli PoC. Se ei kysy, voiko idean toteuttaa, vaan pikemminkin kannattaako sitä toteuttaa lainkaan.
Testattu ei ole sama kuin todennettu
Tällaisessa tilanteessa on helppo syyttää tiimiä epäpätevyydestä. Tiimi kuitenkin testasi ideansa, mutta olosuhteissa, jotka eivät vastanneet todellisuutta. Vastaavat epäkohdat jäävät usein huomaamatta, koska organisaatiot palkitsevat näkyvää edistystä. Kehitysbudjetti myönnetään, vaikka kukaan ei ole osoittanut, että hankkeen kriittiset oletukset ovat paikkaansa pitäviä.
Hyvä prosessi toimii toisin: se nostaa oletukset esiin ja vaatii niiden testaamista ennen suurempia sitoumuksia. Konseptin todentaminen (engl. proof of concept, PoC) on juuri tällainen testi. Sen merkitys on kuitenkin hämärtynyt viime vuosina. Esimerkiksi Woods ym. (2024) tarkastelivat mielenterveystutkimuksia, joissa termiä oli käytetty. Peräti 21 tutkimuksessa 22:sta PoC tarkoitti jotain aivan muuta kuin teknologian valmiustasojen (engl. Technology Readiness Level, TRL) mukaista konseptin todentamista.
Toisin sanoen, nimilappu lupasi enemmän kuin sisältö todisti. Mitä PoC sitten on? Yksinkertaisimmillaan se on rajattu koe, joka selvittää, toimiiko ratkaisun perusajatus teknisesti tai tieteellisesti. Nimestään huolimatta sen tehtävä ei ole todistaa ideaa oikeaksi, vaan ennen kaikkea selvittää, pitääkö se paikkansa.
Vastaus voi yhtä hyvin olla kielteinen kuin myönteinenkin. Siinä mielessä painopiste onkin sanassa rajattu. Ajattele kokkia, joka maistaa kastiketta ennen kuin tarjoilee sitä neljällekymmenelle vieraalleen. Hän ei arvioi menua, kattausta eikä varsinkaan illan tunnelmaa. Hän tarkistaa sen yhden tärkeän seikan, joka voisi epäonnistuessaan pilata koko illan, jolloin kaikki muu menettää merkityksensä.
Neljä vaihetta, joita ei pidä sekoittaa
Varhaisen vaiheen kehityksessä käytetään rinnakkain neljää käsitettä, jotka menevät helposti sekaisin. Erot selviävät parhaiten yhden esimerkin avulla. Kuvitellaan yritys, joka harkitsee tekoälyavustajaa asiakastukeensa. Konseptin todentaminen vastaa yhteen toteutettavuuskysymykseen. Pystyykö avustaja vastaamaan tyypillisiin kysymyksiin yrityksen hyväksymien tukidokumenttien pohjalta? Entä tunnistaako se, milloin vastausta ei löydy?
Prototyyppi taas havainnollistaa, miltä ratkaisu voisi näyttää ja miten sitä käytettäisiin. Se voi olla yksinkertainen käyttöliittymä, johon työntekijä kirjoittaa kysymyksen ja näkee vastauksen lähteineen. Jos testaamiseen tarvitaan käyttöliittymä, prototyyppi voi olla myös osa PoC:ta.
Pilotissa ratkaisua kokeillaan rajatusti oikeassa työssä. Pieni tukitiimi ottaa avustajan käyttöön ja tarkistaa sen vastaukset ennen kuin ne lähtevät asiakkaille. Pilotti kertoo, säästääkö avustaja aikaa ja sopiiko se työnkulkuihin. Se paljastaa myös, synnyttääkö avustaja uutta tarkistustyötä.
Toteutettavuusselvitys puolestaan tarkastelee kokonaisuutta. Riittävätkö aikasäästöt kattamaan kehitys- ja ylläpitokustannukset? Voidaanko asiakastietoja käsitellä asianmukaisesti? Onko yrityksellä resursseja ylläpitää järjestelmää? Vaiheet tukevat toisiaan, mutta ne eivät aina etene tässä järjestyksessä. Toteutettavuusselvitys voidaan tehdä esimerkiksi jo ennen PoC:ta tai sen rinnalla.
Konseptin todentamisen paikan näkee selvimmin NASAn kehittämästä teknologian valmiustasojen asteikosta. Asteikossa on yhdeksän tasoa. Ensimmäisellä tasolla on havaittu tieteellinen perusperiaate ja yhdeksännellä käytössä todennettu järjestelmä. Konseptin todentaminen sijoittuu tasolle kolme. Siellä ratkaisun kriittiset toiminnot osoitetaan toimiviksi analyysin ja kokeiden avulla (Manning 2023; NASA 2023).
Onnistunut PoC on siis noussut tikkailla kolmannelle askelmalle. Se on hyvä alku, mutta ei vielä maali.
Testaa sitä, mikä voi kaataa koko hankkeen
PoC:n arvo on yksinkertaista laskutoimitusta. Jos 10 000 euron koe estää 500 000 euron virheinvestoinnin, niin se on maksanut itsensä takaisin viisikymmenkertaisesti. Robert G. Cooper muotoili saman logiikan jo vuosikymmeniä sitten Stage-Gate-mallissaan (1994). Mallissa innovaatio etenee vaiheittain, ja jokaisen vaiheen jälkeen on portti. Portilla näyttö ratkaisee, jatketaanko vai lopetetaanko (Cooper 1994; 2008). PoC tuottaa juuri tällaista näyttöä, joka avaa portin, kunhan se tehdään oikeassa kohdassa.
Kenties vaikeinta kaikesta on valita, mitä testataan. Kuvitellaan tiimi, joka kehittää puettavaa terveysmittaria. Avoimia kysymyksiä on kymmeniä, ja ne koskevat esimerkiksi akunkestoa, käyttömukavuutta, tiedonsiirtoa, valmistuskustannuksia, sääntelyä ja kysyntää. Jos tiimi yrittää vastata jokaiseen kysymykseen yhdellä kertaa, niin pienestä kokeesta tulee täysimittainen kehittämishanke.
Hyvä PoC keskittyy yhteen oletukseen, joka voi kaataa koko hankkeen. Terveysmittarin kohdalla se tarkoittaa kysymystä siitä, pystyykö mittari ylipäätään havaitsemaan signaalin luotettavasti. Siksi ensimmäinen kysymys ei koskaan ole se, mitä rakennamme, vaan se, mitä meidän pitää saada selville. Tästä seuraa pienin mahdollinen koe, joka ei kaipaa viimeisteltyä käyttöliittymää tai tuotantotason infrastruktuuria.
Tärkeintä on päättää onnistumisen kriteerit etukäteen. Ostotilausesimerkissä kriteeri voisi olla esimerkiksi 95 prosentin tarkkuus tilaustietojen poiminnassa sovituissa testiolosuhteissa. Tyypillisesti maalitolpilla on tapana siirtyä tulosten mukana, jos rajaa ei sovita ennakkoon. Lisäksi kannattaa sopia muutamasta käytännön asiasta. Esimerkiksi on hyvä päättää etukäteen, millä aineistolla testataan ja miten tuloksia arvioidaan. Kokeelle kannattaa varata selkeä aika- ja rahabudjetti. Myös se on sovittava, kuka päättää seuraavasta askeleesta.
Testiaineiston pitää vastata todellisiin käyttöolosuhteisiin. Lisäksi sen on myös oltava eri aineistoa kuin se, jolla ratkaisua on kehitetty tai hienosäädetty. Lopuksi kirjataan, mitä testattiin ja mitä havaittiin. Samalla kirjataan, mikä jäi epäselväksi ja mitä seuraavaksi kannattaa tehdä. Asiakastuen avustajan kohdalla tämä voisi tarkoittaa esimerkiksi seuraavaa. Avustajalle esitetään vähintään sata todellista kysymystä ja vastauksia arvioidaan ajantasaista tukiaineistoa vasten. Mukana on rutiinikysymyksiä, hankalia tapauksia ja tilanteita, jotka pitäisi ohjata ihmiselle. Näitä kysymyksiä ei käytetä kehotteiden hiomiseen.
Tuen asiantuntijat arvioivat vastaukset ennalta sovittujen kriteerien mukaan. Onnistumisen rajaksi voitaisiin asettaa, että vähintään 90 prosenttia vastauksista on hyväksyttäviä. Testissä ei saisi myöskään ilmetä yhtään vakavaa virhetietoa ja jokainen ihmiselle kuuluva tapaus pitäisi ohjata oikein. Mikäli kriteerit täyttyvät, hanketta kannattaa viedä eteenpäin. Tulos ei silti todista, etteikö avustaja voisi koskaan tehdä vakavaa virhettä.
Nimilappu ei ole näyttö
Tähän saakka kaikki kuulostaa järkevältä, mutta tässä kohdassa tarina mutkistuu, koska käytettävän termin suosio on johtanut eräänlaiseen PoC-inflaatioon. Tänä päivänä PoC:ksi kutsutaan diaesitystä, hiottua prototyyppiä, pientä pilottia ja joskus jopa lupaavaa asiakaskeskustelua. Ongelma on siinä, että jokaiseen käyttökertoon sisältyy hiljainen lupaus siitä, että jotain on todennut etukäteen.
Tyypillisesti lupaus kulkee organisaatiossa ylöspäin. Kun ohjausryhmä kuulee PoC:n onnistuneen, se olettaa perustellusti, että vaikein kysymys on ratkaistu. Useinkaan tämä ei pidä paikkaansa. Kokemuksemme mukaan ongelmallisimmat PoC:t eivät ole niitä, jotka epäonnistuivat, vaan niitä, jotka testasivat helpon osuuden ja jättivät riskialttiin oletuksen täysin koskematta.
Myös tuore ohjelmistotekniikan tutkimus toteaa, että PoC:eja tehdään paljon, mutta niiden määritelmät ja menetelmät vaihtelevat runsaasti. Tutkijat peräänkuuluttavat järjestelmällisempää suunnittelua ja päätöksentekoa (Antognolli & Petrillo 2026).
Tässäkään ei ole kyse yksittäisten ihmisten huonosta harkinnasta, vaan organisaatioiden kannustimista. Vaikuttava esittely on helpompi myydä kuin koe, joka voi epäonnistua ja maksaa enemmän kuin esittely. Moni organisaatio myös rahoittaa mieluummin esittelyjä. Lisäksi tähän liittyy myös toinen sudenkuoppa. Teknisesti onnistunut PoC ei kerro mitään kysynnästä, kannattavuudesta, skaalautuvuudesta tai viranomaisvaatimuksista. Toisin sanoen, teknologia voi toimia täysin moitteettomasti ja olla silti huono ja kannattamaton bisnes.
Voimmeko? Mutta pitäisikö meidän?
PoC:n voi ajatella saranana kahden kysymyksen välissä. Ennen kuin se toteutetaan, on hyvä kysyä, voiko idea toimia. Sen jälkeen on tärkeää kysyä, kannattaako hommaa jatkaa, nyt kun tiedämme enemmän. Konseptin todentamisen tärkein tulos ei siis ole demo, malli tai prototyyppi, vaan parempi päätös, jonka tieto mahdollistaa.
Siksi PoC voi onnistua, vaikka teknologia epäonnistuisi. Mikäli koe osoittaa, ettei ratkaisu yllä tarvittavalle tasolle, se on tehnyt juuri sen, mitä siltä pyydettiin ja odotettiin. Vastaus voi olla kyllä, ei vielä tai ei missään nimessä, ja jokainen niistä on arvokas. Sen sijaan epämääräinen ’näyttää lupaavalta’ on täysin arvoton vastaus, jonka perusteella on mahdotonta päättää yhtään mistään.
Kun seuraavan kerran kuulet organisaatiossasi onnistuneesta PoC:sta, suhtaudu siihen väitteenä, jota tarkastellaan, eikä tuloksena, jota juhlitaan. Yleensä kolme kysymystä riittää selvittämään totuuden:
- Mitä oletusta todella testattiin?
- Mikä määriteltiin onnistumiseksi ennen testiä?
- Mitä päätöstä tulosten on tarkoitus tukea?
Mikäli saamasi vastaukset ovat selkeitä, niin silloin PoC on ansainnut nimensä, mutta jos ne jäävät epämääräisiksi, niin kyse oli todennäköisesti vain hyvin tehdystä esittelystä. Tästä syystä haluammekin painottaa, että epäonnistuminen ei suinkaan ole sitä, että huomaa idean toimimattomaksi. Se on sitä, että käytetään suuria summia uskossa, että idea toimii. Mitä aikaisemmin uskomus testataan, sitä halvemmaksi väärässä oleminen tulee.
Testaa oma ideasi
Onko organisaatiollasi tekoälyidea, mutta et ole varma, kestääkö sen keskeinen oletus? Huolellisesti rajattu PoC on usein järkevä ensimmäinen askel. Sen avulla voit selvittää asian omalla datallasi, omien vaatimustesi pohjalta ja omissa olosuhteissasi. Finnish AI Region (FAIR) tarjoaa pk- ja midcap-yrityksille sekä julkisen sektorin organisaatioille maksuttomia PoC- ja prototyyppipalveluita juuri tähän tarkoitukseen.
Tavoitteena on selvittää, toimivatko tekoäly ja muut uudet teknologiat organisaation omassa ympäristössä, ennen kuin niihin sidotaan suurempia resursseja. Lisätietoja löydät palvelusivultamme. Teitpä kokeesi FAIRin kanssa tai ihan itseksesi, niin sen arvo syntyy siitä, mitä opit ja miten käytät oppimaasi.
Myönteinen tulos voi oikeuttaa tuotteen tai palvelun jatkokehityksen. Kielteinen tulos puolestaan voi ohjata parempaan ratkaisuun tai säästää teidät turhilta investoinneilta. Kummassakin tapauksessa seuraavan askeleen pitää perustua näyttöön ja selkeään käsitykseen siitä, mitä on vielä testattava.
Kirjoittajat
Martti Asikainen
Communications Lead, Trainer
Finnish AI Region
martti.asikainen@haaga-helia.fi
Umair Ali Khan
Senior Researcher, Consultant
Finnish AI Region
umairali.khan@haaga-helia.fi
Lähteet
Antognolli, B. F., & Petrillo, F. (2026). Proof of Concept as a first-class architectural decision instrument. arXiv:2604.05835. Preprint. arXiv.
Cooper, R. G. (1994). Third-generation new product processes. Journal of Product Innovation Management, 11(1), 3–14. Wiley & Sons.
Cooper, R. G. (2008). Perspective: The Stage-Gate® idea-to-launch process. Update, what’s new, and NexGen systems. Journal of Product Innovation Management, 25(3), 213–232. Wiley & Sons.
Manning, C. G. (2023). Technology Readiness Levels. NASA.
National Aeronautics and Space Administration. (2023). NASA systems engineering processes and requirements: Technology Readiness Levels (NASA Procedural Requirements 7123.1D). NASA.
Woods, C. E., Lukersmith, S., & Salvador-Carulla, L. (2024). Mapping review of ’proof-of-concept’ in mental health implementation research using the TRL framework: a need for a better focus and conceptual clarification. BMJ Open, 14(8), e080078.
