Miten tietojärjestelmähankinta epäonnistuu tai onnistuu

Jokaisen tietojärjestelmähankinnan kriittisin vaihe on alussa, ennen kun tarjouspyyntöä tai määrittelyä aletaan valmistella. Siinä kohti pitäisi kysyä, mitä me oikeastaan olemme tekemässä. Ja usein hankinta epäonnistuu jo tässä kohtaa, koska kriittisiä kysymyksiä ei käydä riittävästi läpi.

Tärkein kysymys liittyy siihen, mitä olemme organisaationa tekemässä. Tietojärjestelmää ei voi erottaa toimintatavasta, jota sen olisi tarkoitus tukea. Esimerkiksi Apotti on tullut surullisenkuuluisaksi rakenteisesta kirjaamisesta erotuksena aiempien potilastietojärjestelmien vapaatekstikenttiin. Apottia ei voi käyttää ilman rakenteista kirjaamista, muissa Suomessa käytetyissä järjestelmissä taas voi kirjata lähinnä vapaatekstinä. Oliko muutos rakenteiseen kirjaamiseen harkittu ja tietoinen päätös? Ymmärrettiinkö sen seurauksia riittävästi?

Yleensä toimintatapoja halutaan muuttaa: jos tavoitteena ei olisi muutos, luultavasti jatkettaisiin kuten ennenkin. Eli hankinta lähtee siitä, että ymmärretään haluttu muutos toiminnassa. Jos muutosta ei mietitä tietoisesti, on iso riski, että päädytään määrittelemään järjestelmä tukemaan aiempaa toimintatapaa – josta siis haluttiin eroon. Miika Kuha kirjoittaa omassa blogitekstissään siitä, miten tätä organisaation muutosajurien tunnistamista voi tehdä. Yksi hyvä työkalu on myös arvovirtakartta.

Toisaalta toimintatapaakaan ei voi määritellä irrallaan tietojärjestelmästä, vaan yhteys on kaksisuuntainen: toimintatavasta seuraa millainen järjestelmä halutaan, mutta tarjolla olevista vaihtoehdoista seuraa, millainen toimintatapa on mahdollinen. Käytännössä toiminnan muutosta ja järjestelmävaihtoehtoja pitää selvittää rinnakkain tai vuorotellen iteroiden.

Tietojärjestelmän hankintaan on kolme perusstrategiaa: valmistuote, oma kehitys ja strateginen kumppani. Jokaisella on omat hyvät ja huonot puolensa, eikä ole olemassa mitään yleissääntöä että yksi olisi toista parempi.

Miksi valita valmistuote?

Valmistuotteen etuna on, että se on valmiina saatavissa, eli nopea – ja milloin se on valintana mahdollinen, se on yleensä halvin vaihtoehto. Haittapuolena on, että valmistuote on sellainen kuin on, joten toimintatapa täytyy sopeuttaa siihen. Useimpia järjestelmiä pystyy jonkin verran muokkaamaan ja käyttämään vaihtoehtoisilla tavoilla, mutta mitä kauemmas erkaannutaan tuotteen perusprosessista, sen heikommin se luultavasti tukee toimintatapaa. Siksi valmistuotetta valittaessa tärkein kysymys on, pystymmekö sovittamaan toimintamme tähän järjestelmään? Kuinka kykeneviä ja halukkaita olemme muuttamaan toimintaa?

Valmistuote voi olla SaaS-palvelu tai erikseen asiakaskohtaisesti asennettava

järjestelmä. Tilanteesta riippuen sen hankinta voi olla luottokorttiostos, monimutkainen sopimusneuvottelu tai mitä tahansa näiden väliltä. Perusprosessina on selvittää vaihtoehdot, vertailla ja koekäyttää niitä, tunnistaa muutokset omiin toimintatapoihin ja arvioida niiden hyvät ja huonot puolet. Lopuksi tasapainotetaan kustannuksia ja toimintatapoja. Julkisena hankintana erityinen haaste on, että toimintatapoja arvioidaan vasta vaihtoehtojen tunnistamisen jälkeen, mikä tekee suoraviivaisen tarjouspyynnön vaikeaksi.

Mitä oma kehitys tuo, jos siihen päädytään?

Oman kehityksen etu on puolestaan se, että järjestelmän voi määritellä juuri haluamakseen. Huono puoli on, että kehitys on hidasta ja kallista, lähes aina paljon kalliimpaa kuin valmiit ratkaisut. Useimmiten käykin niin, että tavoitteita on kustannussyistä pakko karsia, eikä järjestelmä täytäkään niitä toiveita mitä alussa oli. Lisäksi järjestelmän määrittely on aidosti vaikeaa. Etukäteen tehdyt tarkat määrittelyt unohtavat aina jotain olennaista, ja toisaalta sisältävät asioita joita ei lopulta tarvitakaan. Ongelmaa voi hallita ketterällä lähestymistavalla, mutta sen hintana tulee epävarmuus lopullisista kustannuksista.

Oman kehityksen kustannusta voi joskus olla mahdollista alentaa avoimen lähdekoodin kehityksellä, jossa samaa kustannusta jakamaan saadaan suurempi joukko käyttäjiä. Esimerkiksi monien Suomen kaupunkien kehitämä eVaka-päivähoitojärjestelmä on tästä hyvä esimerkki.

Oma kehityskin on useimmiten ulkoa hankittua ohjelmistokehitystä, käytännössä ketterän tiimin kilpailutus. Omana osaamisena on kuitenkin välttämättä oltava tuoteomistaja, joilla on kykyä ohjata kehitystä ja käydä jatkuvaa vuoropuhelua toimintatapojen ja kehitystyön ristipaineessa. Yleistäen voisi sanoa, että ulkoistetussa kehityksessä onnistuvat sellaiset organisaatiot, jotka kykenisivät tekemään saman kehitystyön myös sisäisesti. Voidakseen hankkia koodausta, pitää myös ymmärtää jonkin verran koodausta.

Strategisen kumppanuuden merkitys on suuri

Strateginen kumppani on ulkopuolinen firma, joka kehittää omaa ohjelmistotuotettaan, mutta tiiviissä yhteistyössä kanssamme, niin että meidän tarpeemme ohjaavat osittain heidän tuotekehitystään. Näin saadaan osa oman kehityksen joustavuudesta ja mahdollisesti osa valmistuotteen kustannusedusta, mutta haasteena on tiivis sitoutuminen yhteen toimijaan ja sen tuleviin ratkaisuihin. Onnistunut suhde vaatii kumppanin tavotteiden ja insentiivien ymmärtämistä sekä molemminpuolisen luottamuksen kehittämistä.

Strateginen kumppanuus on enemmän kuin hankinta, se on molemminpuolinen pitkäaikainen sitoumus yhteisiin tavoitteisiin. Yritysten välillä tällaiset kumppanuudet ovat kohtuullisen yleisiä, julkisella sektorilla sen sijaan hankintalaki tekee onnistuneen kumppanuuden erittäin vaikeaksi ja riski tulla hyväksikäytetyksi on merkittävä.

Hankintastrategiaa kannattaa harkita huolella

Hankintastrategian valinta ei ole suoraviivainen kysymys. Ratkaisun tekeminen vaatii samaan aikaan riittävää ymmärrystä omista tarpeista ja kyvyistä ja toisaalta markkinoilla tarjolla olevista ratkaisuista. Usein kannattaa aloittaa omien tarpeiden analyysistä ja sen rinnalla selvittää markkinalla tarjolla olevia vaihtoehtoja, jotta voi vertailla niiden sopivuutta omiin tarpeisiin.

Hyvin usein toimintatapa valitaan heti alkuun, eikä vaihtoehtoja sille mietitä oikeastaan missään vaiheessa. Tämä on monen epäonnistuneen hankinnan taustalla. Toinen virhe on ajatella, että aloitetaan vaan hankinta ja antaa markkinan ratkaista, millaisia esityksiä tulee. On kuitenkin käytännössä mahdotonta tehdä tarjouspyyntöä, johon voi vastata yhtä hyvin ketterällä kehitystiimillä kuin valmisjärjestelmällä. Monet keskeisimmät valintakriteerit strategioiden välillä ovat myös organisaation sisäisiä: muutoskyvykkyys, ohjelmistoprojektin hallintaosaaminen, ymmärrys omista prosesseista.

Varsinaista hankintaosaamista on mahdollista ostaa ulkoa, mutta strategista valintaa konsultti ei voi tehdä organisaation puolesta. Siihenkin toki voi hankkia apua, mutta sisäinen panos on merkittävä, koska ymmärryksen mitä ollaan tekemässä ja miksi täytyy syntyä organisaation sisälle.

Yhteenveto

Tässä vielä hankintastrategiasanoma tiivistetysti:

1. Jos hankintaan ryhtyessä ei tiedetä mitä ollaan hankkimassa ja miksi, hankinta todennäköisesti epäonnistuu.
2. Hankintastrategian valinnassa käsitellään samaan aikaan tavoitteita, organisaation muutoskyvykkyyksiä ja osaamista sekä markkinoilla olevaa tarjontaa. Mikään näistä irrallaan toisista ei riitä ratkaisuun.
3. Sellaista strategiaa ei ole, jolla voisi onnistua ilman, että ymmärtää mitä on tekemässä. Oman osaamisen lisääminen on aina osa hanketta.

Teksti on julkaistu alun perin Withmoren blogissa. Withmore auttaa tämäntyypisissä haasteissa mielellään.