7.10.2016

Miksi IT-järjestelmien hankkiminen on niin vaikeaa?

Teknisesti, projektihallinnollisesti ja sopimusjuridiikan kannalta IT-järjestelmän hankkiminen on edelleen yksi haastavimmista hankkeista yritysten toiminnassa. Miksi se yhä on niin vaikeaa, vaikka tekniikka, palvelumallit ja kohonnut sopimusosaaminen tarjoavat jo kohtuullisen ennustettavat puitteet hankinnoille

Tiedä mitä haluat ja tarvitset

Useimmiten hanke lähtee liikkeelle siitä, että asiakas tekee tarvekartoituksen. Toimittajat tarjoavat kukin omia ratkaisujaan asiakkaan tarpeisiin. Tässä vaiheessa riskinä usein on, että hanketta ryhdytään viemään eteenpäin ”toimittajan tuote edellä” eli asiakkaan todelliset tarpeet peilataan niiden ratkaisujen kautta, joita toimittajien tuotteet tarjoavat. Tämä on luonnollistakin ja vain harvoin asiakas ja toimittaja lähtevät tyystin puhtaalta pöydältä eli kokonaan räätälityönä rakentamaan ratkaisumalleja. Ongelmaksi voi toimituksen tapahduttua nousta se, ettei lopputulos aivan ollutkaan sitä, mitä asiakas oli hakemassa, mutta toisaalta toimittaja on toimittanut juuri sen, mitä on koko ajan tarjonnutkin. Osapuolten ”kommunikaatio” ei ole kohdannut ja ollaan tilanteessa, jossa pitää selvittää, mitä oikeastaan on sovittu.

Varmista riittävät resurssit

Asiakkaan eli tilaajan näkökulmasta vaikuttaisi riittävältä varmistaa, että toimittajalla on tarvittavat muskelit tehdä sovittu työ ja toimittaa sopimuksen mukainen tuote tai järjestelmä. Harvoin hanke kuitenkaan etenee, ellei myös asiakkaalla itsellään ole osoitettuna riittävät resurssit omassa organisaatiossaan. Asiakkaan pitää pystyä antamaan tarpeelliset määritykset toimittajalle, reagoida riittävän nopeasti väistämättä aina eteen tuleviin ennakoimattomiin tilanteisiin ja kysymyksiin sekä antamaan muu tarvittava palaute toimittajalle. Hyvin usein viivästystilanteessa keskeiset riidan aiheet liittyvät siihen, onko toimituksen viivästys johtunutkin asiakkaan puutteellisesta toiminnasta, hitaudesta ja epäselvistä ohjeista.

Keskity olennaiseen

IT-hankkeissa usein esitetyn lausahduksen mukaisesti hyvin suunniteltu on 95-prosenttisesti tehty. On myös todettu, että viimeinen 5 % vaatii 95 % resursseista. Tämä koskee sekä toteutusta että sopimusta. Sopimusneuvotteluissa pitäisi heti tarttua vaikeimpiin kysymyksiin, jolloin triviaalimmat seikat voidaan sopia, kun ensin on tuorein voimin tahkottu ratkaisu olennaisimmista. Nykyisenä pilvipalveluiden aikana voi myös olla niin, että neuvoteltavat asiat ovat supistuneet varsin vähiin. Asiakkaan ja toimittajan välisessä suhteessa on vain muutama neuvoteltava ”parametri”, loppu tulee vakioidusti samanlaisena kaikille asiakkaille.

Sitä saa mitä mittaa

Yhä harvemmin hankinnan kohteena on erillinen asiakkaan laitteisiin asennettava ohjelmisto, ja useammin toimittajan tuottama palvelu, jonka ostaminen on asiakkaalle ”kulu” entisen ”investoinnin” sijaan. Asiakas ostaa kapasiteettia tai toiminnallisuutta. Palvelutasoehdot eli SLA:t ovatkin keskeisessä asemassa. Käytettävät mittarit riippuvat palvelun luonteesta. Tyypillisiä mittareita ovat käytettävyys (esim. palvelu ylipäätään käytettävissä taikka tiettyjen prosessien kesto), käyttökatkojen määrä ja kesto, vastaaminen vikailmoituksiin jne. Toimitus voi olla myös hybridi, jossa ensin tehdään asiakkaan tarpeisiin perinteisellä mallilla järjestelmä, jonka käyttö sitten ostetaan toimittajalta palveluna. Tällöin sopimusta kirjoitettaessa on ehdottomasti syytä erottaa vaiheet kahdeksi erilliseksi sopimukseksi, koska muutoin lopputuloksesta on mahdoton saada toimivaa. Palveluvaiheeseen mennään vasta, kun toimitus on valmis ja hyväksytty.

Työtä vai tulosta

Yllättävän usein sopimusta jälkikäteen luettaessa on edelleenkin epäselvää, mistä loppujen lopuksi on sovittu. Onko sovittu työtunneista vai siitä, että toimitetaan sovittu tulos? Suuri osa erimielisyystilanteista voitaisiin välttää, jos jo sopimusneuvotteluissa riittävän selkeästi sovitaan (ja kirjataan myös sopimukseen), mikä on sopimuksen kohde. Tuotteen ostaminen on eri asia kuin palvelun tai työn ostaminen. Lisäksi ketterät (agile) ohjelmistokehitysmetodit, kuten vaikkapa scrum, asettavat haasteita sille, miten tavoiteltu tulos pystytään määrittelemään riittävän tarkasti ja molemmille osapuolille yksiselitteisesti.

Riitatilanteessa edellä kuvatulla jaottelulla on vaikutusta melkein kaikkeen. Konkreettisena esimerkkinä voidaan mainita ääritilanne eli sopimuksen purkaminen. Jos osapuolet ovat ajautuneet asetelmaan, jossa sopimuksen purkaminen on vaihtoehtona, on hyvä huomata, että tulosvelvoitteellinen sopimus purettaessa on osapuolten lähtökohtaisesti palautettava saamansa suoritukset puolin ja toisin, mikäli ne ovat palautettavissa. Asiakas palauttaa jo mahdollisesti saamansa työn tulokset ja toimittaja palauttaa maksetut rahat. Jos sopimus koskee vain työpanoksen eli palvelun hankintaa, ei palautusvelvollisuutta käytännössä ole, koska saatua palvelua ei voi palauttaa. Rahojakaan ei näin ollen palauteta. Tosin tilanne on harvoin kokonaisuudessaan näin yksinkertainen ja tulkintaan vaikuttaa myös, jos toimitus on tehty vaiheittain ja asiakas on hyväksynyt vaiheita.

Tähän samaan problemaattiseen kategoriaan kuuluu myös tilanne, että asiakas ensin kilpailuttaa toimittajat ja sitten tinkimiskierrosten jälkeen valitsee halvimman. Vasta tämän jälkeen neuvotellaan siitä, mitä sillä hinnalla oikeasti saa. Asetelma ei kummankaan osapuolen näkökulmasta ole omiaan johtamaan parhaaseen lopputulokseen.

Kun IT-sopimusta neuvoteltaessa pitää mielessä ainakin edellä mainitun muistilistan, ollaan jo paljon lähempänä onnistunutta lopputulosta.

Tatu Kulmala