Public Sector IT Procurement Requires an Agile Mindset (Available in Finnish)

Authors: Outi Jousi, Jesper Nevalainen, and Annika Juhola

Julkiset IT-hankinnat ovat ketteryyslaji

Julkiset IT-hankinnat ovat puhuttaneet paljon viime aikoina niin lehtiartikkeleissa kuin sosiaalisessa mediassakin. Haluamme tässä blogipostauksessa tuoda esiin muutamia seikkoja, joita keskustelussa ei ole vielä huomioitu.

Hankintalaki on hyvä työkalu, mutta se rajaa vertailumahdollisuuksia

Hankintalaki sinällään soveltuu hyvin käyttötarkoitukseensa. Laki perustuu EU-sääntelyyn, joten sitä ei ole mahdollista muuttaa merkittävästi. Julkisissa IT-hankinnoissa tarjousten vertailu kohdistuu usein ohjelmistokehittäjien ja muiden asiantuntijoiden osaamiseen ja kokemukseen. Tämä johtuu siitä, että hyvien vertailuperusteiden löytäminen koetaan monesti haasteelliseksi. Hankintalaki asettaa vertailutekijöille rajoituksensa: ne eivät saa antaa käyttäjälleen liikaa harkintavaltaa, eli pisteiden perusteet pitäisi pystyä löytämään tarjouspyyntöasiakirjoista. Yritykseen liittyvät soveltuvuustekijät tulisi myös pitää erillään hankinnan kohdetta (ohjelmistoa) koskevista vertailutekijöistä. Vertailukriteerit eivät saisi syrjiä tai suosia ketään ja niiden tulisi aidosti liittyä hankinnan kohteeseen.

Mahdolliset liikevaihto- ja referenssivaatimukset tulisi harkita huolella, sillä ne rajaavat osan kilpailijoista pois. Kokemuksemme mukaan alihankintana tai ryhmittymänä tarjoaminen on varsin korkean kynnyksen takana, sillä se edellyttäisi uusien yhteistyösuhteiden ja -sopimusten luomista, huomioiden usein kireä tarjoamisaikataulu. Ongelma voidaan ratkaista jakamalla hankinta pienempiin osiin ja sallimalla osatarjousten antaminen.

Räätälöityä vai pilvipalvelua?

Usein tavoite voidaan saavuttaa tutkimalla markkinoilla tarjolla olevia valmisohjelmistoja, jotka ovat usein pilvipalveluita. Aktiivinen markkinavuoropuhelu onkin kaikkien etu. Sen sijaan, että asiakkaalle kehitetään kokonaan uusi ohjelmisto, voidaan harkita päästäisiinkö riittävän hyvään ratkaisuun tarkastelemalla tavoitteita kriittisesti. Päästäisiinkö hyvään lopputulokseen muokkaamalla tavoitteita ja kilpailuttamalla valmisohjelmistot?

Tältä osin kannattaa huomioida, että pilvipalvelun palvelinten sijaintimaalla on väliä. Oikeuskäytäntö ja tietosuojasääntely velvoittavat selvittämään tietosuojan tason siinä maassa, jonne dataa siirretään.

Resurssivuokraa vai tulosvastuullisuutta?

Mikäli tarpeeseen ei löydy valmista ratkaisua, tulee sellaisen kehittäminen kilpailuttaa. Resurssivuokra ei kuitenkaan ole ainut tapa hankkia ”aidosti agilea” ohjelmistoprojektia. On mahdollista kirjoittaa sopimus, jossa toimittaja ottaa vastuun lopputuloksesta, eikä ainoastaan tarjoa resursseja tilaajan työnjohdon alaisuuteen tuntihinnalla. Vesiputousmallinen kaiken ennalta suunnitteleminen ei silti ole tarpeen, vaan kehitystä voidaan tehdä yhteistyössä täysin ketterästi.

Vertaillaan sellaista, jolla on aidosti merkitystä

Millä tarjouksia sitten kannattaisi vertailla, jos CV-kilpailu unohdetaan?  Olemme monesti pitäneet hyvänä vertailukriteerinä Minimum Viable Productin (MVP) tai sitä pienemmän ohjelmisto-osan toteutusta. Sen tekemisestä tulisi maksaa toimittajille, jotteivat tarjoamiskustannukset muodostu kohtuuttoman suuriksi. Vertailukriteerien tulisi myös MVP:n arvioinnin osalta olla mahdollisimman objektiivisia.

Asiakkaan resurssit ovat tärkeitä hankinnan onnistumiselle

Ketterä ohjelmistokehityssopimus ei sovi joka tilanteeseen, eikä ketteryys ole itsetarkoitus. Tärkeintä on saada asiakkaan tarpeita vastaava ohjelmisto. Asiakkaan olisi myös hyvä käyttää aikaa tarpeen määrittelyyn ja hankinnan valmisteluun.

Jotta ketterä ohjelmistokehitys voisi onnistua, tulisi asiakkaalla olla aidosti aikaa ja osaamista olla siinä aktiivisesti mukana. Asiakkaan resurssien varmistaminen on siten tärkeää hankinnan onnistumiselle ja aikataulussa pysymiselle. Asiakkaan tulee kyetä tekemään ratkaisuja jatkuvasti ja nopealla tahdilla.

Projektikurissa tulisi pysyä

Suuri osa IT-hankintoja koskevista riidoista johtuu siitä, että vastapuolelle on haluttu olla hieman liiankin höveleitä. On suostuttu aikataulu- ja sisältömuokkauksiin, samalla kenties budjetti sivuuttaen. Tai on innostuttu kehittämään järjestelmästä vielä parempaa, jolloin alkuperäisessä aikataulussa pysyminen on muodostunut haasteelliseksi. Suuri osa riitaisuuksista poistuu, jos ”projektikurissa” pysytään kummallakin puolella pöytää, eli tehdään vain se, mistä on yhdessä kulloinkin sovittu.  Tällöin varmistetaan myös se, ettei sopimus tule muutetuksi hankintalaissa kielletyllä tavalla.

Kehityksen ketteryydestä ei silti tarvitse luopua. Oikein tehty ketterä sopimus pysyy ohjelmistokehityksen edetessä jatkuvasti ajantasaisena.