IT-hankinnat ja julkinen tarjouskilpailu

TkL Aapo Koski väitteli hiljattain aiheesta ”Tehtäväkriittisten, julkisiin hankintoihin perustuvien järjestelmien toimittamisesta”. Tehtäväkriittisellä tässä yhteydessä tarkoitetaan sellaista IT-järjestelmää, jonka vikaantuminen vaikeuttaisi merkittävästi yhtiön liiketoimintaa.

Väitöskirja on hyvin käytännönläheinen ja perustuu kirjoittajan omiin kokemuksiin valtion hätäkeskusjärjestelmän toimituksesta. Kirjassa esitetään konkreettisia parannusehdotuksia julkisiin IT-hankintoihin. Mielestäni kaikki ehdotukset soveltuvat myös ei-julkisiin IT-järjestelmien hankintoihin. Luin väitöskirjan (joka on tiivistelmä kahdeksasta erillisestä aihetta käsittelevästä artikkelista) läpi ja ohessa joitain poimintoja käsiteltävästä aiheesta nimenomaan IT-sopimuslakimiehen näkökulmasta:

Ison IT-järjestelmän hankinta on pitkä prosessi ja oletusarvoisesti ajan kuluessa liiketoimintaympäristö, työkalut, käyttäjät ja hankinnan taustalla olleet lähtökohdat muuttuvat. Tästä syystä ne oletukset, jotka asetettiin projektin alussa, eivät välttämättä enää toimi projektin edistyessä. Tämä tulisi huomioida projektin aikana ja myös projektisopimuksissa. Lähes aina sopimukset ovat kirjoitettu vain yhdenlaista toimitusmallia ajatellen eikä niissä huomioida sitä, että joku projektin vaihe saattaa olla paremmin toteutettavissa vesiputousmallilla ja joku toinen vaihe taas ketterällä menetelmällä ja päinvastoin. Sopimuksissa olisi hyvä varautua, jos ei muuten niin ainakin toteamalla, että osapuolet hyväksyvät mahdollisuuden toimitusmallin muutokseen kesken projektia, jottei väkisin yritettäisi toteuttaa projektia täysin tarkoitukseen sopimattomalla sopimuksella.

IT-järjestelmän vaatimukset hyvin usein keskittyvät listaamaan järjestelmän toiminnallisuuksia, mutta jättävät valitettavan usein laadulliset kriteerit kokonaan määrittelemättä. Hyvä IT-järjestelmä ei kuitenkaan ole kokoelma toimintoja, jos käyttäjän kokemus järjestelmästä jätetään kokonaan huomioimatta. Myös testaukseen tulee kiinnittää enemmän huomiota. Vain testauksesta oikealla materiaalilla ja oikeassa käyttöympäristössä on aidosti hyötyä. Vaikka lakimiehet eivät laadi järjestelmävaatimuksia, olisi myös heidän syytä tarkastaa, etteivät ne ole vain listoja toiminnallisuuksista, vaan myös ei-funktionaalisiin seikkoihin, kuten laatukriteereihin on panostettu. Laadukkaan järjestelmän toteuttamiseen ja laadun testaamiseen tulisi myös sopimuksellisesti kannustaa.

Koski korostaa, että IT-toimittajalle siirtyminen järjestelmätoimittajasta SaaS-palvelutoimittajaksi vaatii perinpohjaista muutosta toimintatavoissa ja ajattelussa. Sama pätee myös sopimuksellisella tasolla. Jos kyse on aidosti SaaS-toimituksesta eli palvelusta, on sitä turha yrittää tehdä sopimuksella, joka on kirjoitettu järjestelmätoimitusta varten. Toimintatavan muutoksen on myös näyttävä sopimustasolla. Esimerkkinä voidaan käyttää järjestelmän virheiden korjausta. Mittariksi virheiden korjaukseen ei voida ottaa vain sitä, montako tikettiä toimittaja on tietyssä ajassa käsitellyt, vaan toimittajan palvelutason mittarina tulisi olla se, miten laadukkaaksi käyttäjät kokevat toimittajan palvelun ja järjestelmän toiminnan.

Hyvän toimituksen onnistumiseksi kommunikoinnin merkitystä ei voi olla korostamatta. Kommunikoinnilla Koski tarkoitta aitoa, asiakkaan (myös loppukäyttäjien) ja toimittajan välistä kommunikointia, jota on käytävä henkilökohtaisesti ja fyysisesti, ei kirjallisesti. Tältä osin lakimiehenä otan sen vinkin, etten aina lisää sopimukseen vaatimukseksi ”kirjallista” ilmoitusta pyynnöstä, virheestä tai muusta havainnosta. Jos kommunikoinnilta vaaditaan aina kirjallista vaatimusta, se jäykistää prosessia liiaksi eikä edesauta asiakkaan tavoitetta; saada paras mahdollinen järjestelmä käyttöön. Sellainen syntyy vain aidolla, joustavalla ja luontevalla kommunikoinnilla toimittajan ja asiakkaan välillä.

Tehtäväkriittisen järjestelmän hankkivan tahon on voitava luottaa järjestelmän toimintaan ja sen toimittajaan kaikissa olosuhteissa. Toisaalta luottamuksen rakentaminen julkisessa hankinnassa on haastavaa, sillä koko prosessi alusta alkaen perustuu enemmän sakkoihin ja sanktiointeihin kuin luottamuksen rakentamiseen. Myös hankintasopimukset on perinteisesti kirjoitettu ”luottamus hyvä, kontrolli parempi” -näkökulmasta. Toimittajaksi voi julkisessa hankinnassa valikoitua taho, josta asiakkaalla ei ole mitään ennakkotietoa eikä aikaisempaa kokemusta. Lisäksi asiakkaan toiveet järjestelmästä ja toisaalta toimittajan käsitys asiakkaan tarpeista eivät välttämättä kohtaa. Mikään näistä ei ole luottamusta erityisesti rakentava seikka. Hankintalaki ei myöskään erityisesti edesauta asiakkaan ja toimittajan välisen luottamuksen rakentamista. Esimerkiksi kommunikointi asiakkaan ja toimittajan välillä tarjousaikana on tasapuolisuussyistä hyvin rajoitettua. Toisaalta vain vapaa kommunikointi asiakkaan ja toimittajan välillä voi edesauttaa luottamuksen rakentamista. Nämä ovat seikkoja, joihin ei juuri sopimuksellisesti voi vaikuttaa, ainakaan niin kauan kuin hankintalaki on mitä on, mutta nämä on hyvä huomioida projektin menestyksen kannalta.

Julkisissa IT-hankinnoissa trendinä on ketterien toteutusmenetelmien suosiminen. Tämän olisi syytä ja sen pitääkin näkyä myös tarjousvaiheessa ja lopullisessa sopimuksessa. Ketteryys IT-projekteissa tarkoittaa, että maali voi muuttua matkan varrella ja tällä voi olla vaikutusta myös aikatauluihin. Liian usein näkee tarjouspyyntöjä, jossa on lyöty lukkoon kiinteät aikataulut ja määritelty toiminnallisuudet hyvinkin tarkasti. Sakollisten aikataulujen ja tarkkojen toiminnallisten vaatimusten määrittely eivät edesauta ketteryyden toteutumista. Tältä osin lakimiesten tulisi kehittää sopimuksiin uudenlaisia kontrollikeinoja tai hyväksyä se, että ketterään projektiin luontaisesti sisältyy enemmän epävarmuutta kuin perinteiseen vesiputousmalliin. Toisaalta asiakkaan näkökulmasta heidän tulisi ymmärtää se, että ketterän menetelmän valitseminen toimitustavaksi vaatii asiakkaalta enemmän kuin perinteinen menetelmä. Asiakas ei voi ketterässä toimituksessa odottaa 9 kuukautta sitä, että toimittaja tuo hänelle valmiin järjestelmän, vaan hänen on osallistuttava kahden viikon välein palavereihin, jossa projektin suunnasta ja toiminnallisuuksista päätetään.

Ylipäätään ison IT-järjestelmän hankkiminen on vaikeaa ja riskialtista. Hankintalaki ei erityisesti tue hyviä käytänteitä IT-järjestelmähankinnassa, mutta huolellisella ennakkovalmistautumisella ja panostamalla sekä tarjouspyyntövaiheeseen että varsinaiseen sopimukseen, voidaan hankinnan onnistumista edesauttaa.

Kirjoittaja Arto Lindfors on IT-asioihin erikoistunut lakimies Fondialla ja osallistunut mm. IT2018 ehtojen laadintaan.