Muutama päivä sitten heitin puoliksi vitsillä, että olisi kiinnostavaa nähdä jonkun kansanedustajan kysyvän, miksi julkiset IT-hankkeet maksavat välillä kymmeniä miljoonia, kun samaan aikaan yksittäiset ihmiset rakentavat nettiin ilmaiseksi toimivia prototyyppejä, työkaluja ja testiympäristöjä. Prototyyppi ei ole tuotantojärjestelmä, mutta ero on silti kiinnostava.

Sitten vastaan tuli uutinen Kelan miljoonien eurojen IT-hankinnasta, joka oli päätynyt markkinaoikeuteen – siis julkisten hankintojen riitoja käsittelevään erityistuomioistuimeen. Ajoitus oli niin hyvä, että nauroin ensin. Mutta kysymys ei jättänyt rauhaan: miksi jokin, joka ulospäin näyttää teknisesti melko tavalliselta ohjelmistolta, voi muuttua vuosien projektiksi ja maksaa miljoonia?

Helppo vastaus olisi, että julkinen sektori vain tuhlaa rahaa. Todellisuus on kiinnostavampi.

Miksi ammattilainen saa päivässä valmiiksi sen, mihin organisaatio tarvitsee vuosia?

Kun yksittäinen kehittäjä rakentaa prototyypin, hän ratkaisee yleensä itse ongelmaa. Hän voi vaihtaa tekniikkaa kesken päivän, heittää puolet koodista roskiin, käyttää valmista, vapaasti käytettävää koodia tai todeta illalla, että alkuperäinen ajatus olikin huono.

Suuri organisaatio ei toimi näin. Sen täytyy tietää, kuka vastaa järjestelmästä, mitä tapahtuu jos se hajoaa, miten arkaluonteista tietoa käsitellään, kuka ylläpitää sitä viiden vuoden päästä ja miten se saadaan keskustelemaan niiden järjestelmien kanssa, jotka olivat olemassa jo ennen kuin joku nykyisistä kehittäjistä oli työelämässä.

Siinä vaiheessa ei enää osteta pelkkää ohjelmistoa. Ostetaan vastuuta. Ja vastuu on kallista.

Riskienhallinta synnyttää vaatimuksia – ja lopulta vaatimukset ovat oma riskinsä

Kun organisaatio yrittää suojautua epäonnistumiselta, se alkaa kirjoittaa vaatimuksia. Toimittajalla pitää olla tietynlaista kokemusta, tietyn kokoisia referenssejä, oikeanlaisia asiantuntijoita ja kokemusta juuri niistä järjestelmistä, joiden kanssa työ tehdään.

Ajatus on ymmärrettävä: jos käytetään miljoonia yhteisiä rahoja, hankintaa ei voi ratkaista sillä, että joku ilmoittaa Discordissa – eli netin keskustelualustalla – olevansa aika hyvä Reactissa, yleisessä käyttöliittymäkirjastossa.

Mutta jossain kohdassa suojaamisesta tulee oma ongelmansa. Tivi uutisoi Kelan noin seitsemän miljoonan euron IT-hankinnasta, joka päätyi markkinaoikeuteen. Uutinen nosti esiin kysymyksen vaatimusten suhteellisuudesta – siitä, että vaatimusten pitäisi olla oikeassa suhteessa hankinnan kohteeseen. Tuore KHO:n ennakkopäätös KHO:2026:44 puolestaan linjaa, että referenssivaatimus, joka ei ole oikeassa suhteessa hankinnan kohteeseen, voi olla suhteellisuusperiaatteen vastainen ja rajoittaa kilpailua. Päätös koski sote-rekrytointia eli sosiaali- ja terveysalan henkilöstöhankintaa, ei IT-hanketta, mutta periaate on yleinen ja sen soveltuminen IT-hankintoihin jää tapauskohtaisesti arvioitavaksi. Toisaalta tapauksessa Helsingin kaupunki on puolustanut referenssivaatimusta nimenomaan sillä perusteella, että referenssi voi olla ainoa tapa arvioida todellista kyvykkyyttä etukäteen. Toimittajia edustava Teknologiateollisuus on puolestaan vaatinut luopumaan “henkilöstön ylimitoitetuista kokemus-, osaamis- ja kielitaitovaatimuksista”.

Jos vaatimus alkaa rajata toimijoita enemmän kuin työn onnistuminen vaatii, sillä ei enää mitata vain sitä, kuka osaa tehdä työn. Sillä mitataan sitä, kuka sopii hankintajärjestelmän valmiiseen muottiin.

Paperilla pätevä, käytännössä kyvykäs? Referenssi ei mittaa kaikkea

Tässä on se ero, joka minua kiinnostaa. Joku voi olla erittäin hyvä ratkaisemaan ongelman, mutta silti muodollisesti vääränlainen toimija ratkaisemaan sen. Ja toisin päin: joku voi täyttää kaikki paperilla olevat ehdot olematta välttämättä paras mahdollinen ongelmanratkaisija.

Kyvykkyys ja kelpoisuus eivät ole sama asia.

En tarkoita, että julkiset hankinnat pitäisi korvata sillä, että virkamies selailee GitHubia – koodinjakopalvelua – ja huutaa ensimmäiselle lupaavalle koodivarastolle “tuotantoon”. Ei tietenkään. Mutta nykyisessä teknologiaympäristössä ero prototyypin rakentamisen ja suuren hankintaprosessin välillä alkaa välillä näyttää todella oudolta. Pieni tiimi voi todistaa muutamassa viikossa, että jokin toimintaperiaate toimii. Sen jälkeen suuri järjestelmä saattaa käyttää vuoden määritelläkseen, millainen yritys saa edes tarjota ratkaisua.

Voisiko osaamisen testata ennen miljoonapäätöstä?

Tässä voisi olla yksi kohta, jossa julkisia hankintoja kannattaisi ajatella uudelleen. Mitä jos ennen massiivista kilpailutusta testattaisiin enemmän itse kyvykkyyttä?

Annetaan rajattu ongelma. Turvallinen testiympäristö. Selvät pelisäännöt. Sama tehtävä useammalle toimijalle. Katsotaan, mitä oikeasti syntyy. Ei tarvitse ensin luvata rakentavansa kaikkea kolmeksi vuodeksi – näyttää ensin, että osaa ratkaista ongelman.

Tällainen testaaminen on kuitenkin sovitettava hankintalain tasapuolisen kohtelun ja avoimuuden vaatimuksiin. Vapaamuotoinen karsintatesti ennen kilpailutusta ei ole mikään oikotie, vaan ajatusta on mietittävä osana olemassa olevia menettelyjä. Teknologia tekee tällaisen kokeilemisen koko ajan halvemmaksi. Samaan aikaan monet hankintakäytännöt ovat perua ajalta, jolloin ohjelmiston rakentaminen oli hitaampaa, teknologia vaikeammin saatavilla ja toimittajan vaihtaminen huomattavasti hankalampaa. On hyvä muistaa, etteivät käytännöt ole pelkkä jäänne: ne palvelevat myös avoimuutta ja vastuullisuutta.

Tämä ei ole pelkkää utopiaa: innovaatiokumppanuusmenettely on olemassa juuri sellaista tilannetta varten, jossa kehitystyö ja prototyyppi kuuluvat itse hankintamenettelyyn. Sitä ei ole suunniteltu referenssien korvaajaksi eikä yleiseksi kyvykkyystestiksi, mutta se osoittaa, että tuloksia voidaan ostaa myös tuloksina.

Lopuksi

Mikään tästä ei tarkoita, että julkiset hankinnat pitäisi jättää Discord-referenssien varaan. Mutta kun iso hanke maksaa miljoonia, on kysyttävä, kuinka paljon hinnasta on itse tekniikkaa ja kuinka paljon teknologian ympärille rakennettua koneistoa.

En tiedä. Mutta epäilen, että kiinnostavimmat säästöt eivät tule siitä, että ohjelmoija kirjoittaa koodia vähän nopeammin. Ne tulevat siitä, että katsotaan tarkemmin, millaisen järjestelmän olemme rakentaneet ennen kuin ensimmäistäkään koodiriviä kirjoitetaan.