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:
- Jos hankintaan ryhtyessä ei tiedetä mitä ollaan hankkimassa ja miksi, hankinta todennäköisesti epäonnistuu.
- 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.
- 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.
Moi. Itse olen käyttänyt Apottia sen tullessa Vantaan kaupungille, sekä myöhemmin Laskson sairaalassa.
Väärin kirjoituksessasi on se, ettei voisi vapaatekstiä kirjoittaa. Kyllä voi, lyhyesti jokaiseen rakenteisen kirjasmisen kohtaan, sekä pidempään tekstiä hoitokertomukseen. Näin niin kuin ruohonjuurikäyttäjänä.
Moi, kiitos tarkennoksesta. Itsehän en ole Apottia työkseni koskaan käytänyt, kun en tosiaan terveydenhuollon alalla toimi. Ehkä pitää hiukan säätää sanamuotoa, että ei tule väitettyä mitään epätotta.
P.S. Rakenteinen kirjasminen oli ensin, sitten vasta valittiin Apotti.
Siinä on huonot puolensa, se on sillisalaatti, josta kukaan ei erota eri sinesosia. Liian srkavs. Laaksossa jopa lääkärit laittoivat viestiä hoitajille, että laittakaa nyt vaan yhteen paikkaan ne tärkeät asiat, ettei heidän aika mene eri asioiden etsimiseen monesta paikasta.
Koetas joskus tehdä tilastoja vapaatekstikenttien sisältämästä tekstipuurosta. Saattaa se tulla ikävä rakenteista kirjaamista. Sitä ei usko, ellei ole kokenut kantapään kautta, kuinka monella tavalla sama yksinkertainenkin tieto voidaan kirjata. Jos yhteenvedoilla tai tilastoinneilla ei ole väliä – sellaisiakin aihepiirejä toki lienee – niin sen kun vaan. Mutta terveyden- ja sairaanhoitoon liittyvissä tehtävissä on kyse aina myös laajemmista kysymyksen asetteluista, kuin yhden potilaan ongelmista.
Kyllä, juuri tämä on rakenteisen kirjaamisen pointti. Se on sitten vaikeampi kysymys, mikä kaikki pitää kirjata rakenteisesti ja miten siitä voitaisiin tehdä mahdollisimman sujuvaa. Se ei ole ihan helppoa.
Tästä jäi ehkä ”jatkuvan kehittämisen” näkökulma pois. Yleensä mikään softa ei ole täysin valmis, vaan aina voisi parantaa. Lisäksi valmiskin softa vaatii ylläpitoa. Tämän takia talon sisäisen tiimin kehittämä softa voi olla hyvä ja kustannustehokaskin valinta pidemmän päälle. Tosin kehitystyötä ei saa lopettaa, kun tavoitteet on saavutettu. Eli talossa on koko ajan töissä vähintään 3-5 hengen tiimi hoitamassa vaativampaa asiakastukea, poistamassa bugeja ja kehittämässä tärkeimmiksi koettuja ominaisuuksia.
Hyvänä puolena softahankinta tarvitsee tehdä vain kerran, kun talon sisäinen kehitys pitää sen ajantasalla. Ainakin, jos se on riittävästi resursoitu. Lisäksi käyttäjien tarpeisiin pystytään vastaamaan kohtalaisen joustavasti ja nopeasti sekä kulmia oikomaan ilman uusia hankintaprosesseja tai lisämaksuja konsulteille. Parhaimmillaanhan strateginen kumppanuuskin pystyy ainakin jollain tapaa tarjoamaan näitä etuja.
Eetu: Asia on juuri noin kuin sanot. Jotta blogi pysyisi kohtuullisen mittisena ja välittäisi yhden pontins elvästi, oli pakko karsia aika paljon siihen liittyviä asioita pois.
Jatkuvaan kehittämiseen ryhdyttäessä oma tiimi on useimmiten järkevä ratkaisu. Mutta on hyvä ymmärtää, että siinä sitoudutaan tosiaan siihen että on to oma tiimi pysyvänä kuluna ja siihen että organisaation pitää kyetä palkkaamaan softakehittäjiä. Koska jos tähän ei varauduta, operaatio menee jossain vaiheessa pieleen
Rakenteinen kirjaaminen on tarpeen, koska big data.
Se, onko terveydenhuollon tietojärjestelmän ensisijainen tavoite auttaa hoitamaan potilaita vai tuottaa dataa, on kiinnostava valinta. Se on myös sellainen valinta, jonka moni muukin organisaatio joutuu tekemään. Mitä vähemmän dataa on, sitä paremmassa kunnossa eli rakenteisempaa sen on oltava. Metalle tai Googlelle riittää mainoskohdistukseen vähän heikompikin laatu, ja määräkin on laatua kun sitä on riittävästi.
Toisaalta aina on tarjolla kevyempi, epämuodollisempi ja myös epätasaisempaa laatua tuottava toimintatapa joka ei tuota käyttökelpoista dataa ja saa jokaisen tiedolla johtajan sydämen vuotamaan verta ja tietokoneen sylkemään prosessikaavioita.