Apotti-hanke on herättänyt ennennäkemättömän määrän keskustelua sekä Suomen IT-piireissä, että julkisuudessa. Mahdollisesti ensimmäistä kertaa yleiseen keskusteluun on noussut se, miten ongelmallisia ja kalliita julkisin varoin toteutettavat IT-järjestelmät ovat.
Olen mielenkiinnolla seurannut aiheen ympärille syntynyttä Facebook-ryhmää. Keskustelun laatu on korkeatasoista ja siihen osallistuvat sekä IT-alan että terveydenhuollon ammattilaiset.
Tämän kirjoituksen tarkoituksena on kerätä teemoja, jotka vallitsevat keskustelun taustalla - valitettavasti usein hukkuen yksityiskohtien ja tarkan argumentoinnin sekaan. Pyrin nostamaan tarkasteltavan ongelman sellaiselle tasolle, että voidaan päästää irti kehää kiertävistä argumenteista (esimerkki: "ketterät menetelmät auttaisivat - ei voi käyttää koska X, Y, Z"). Yritän myös tuoda keskusteluun muutaman uuden käsitteen ja idean, jotka ehkä jäsentävät aihetta niiden mielissä, jotka tämän kirjoituksen lukevat.
Millaista on hyvä ohjelmistokehitys?
Jotta voitaisiin verrata vaikkapa Apotin toimintamalleja johonkin, esittelen ensin oman parhaan näkemykseni siitä, miten järjestäytyy toimivia, kestäviä ja kauniita ohjelmistoja tuottava kehitysmalli. Listaan ominaisuuksia, joita tällaisella mallilla voisi olla. Mitä enemmän näitä saadaan käyttöön samassa hankkeessa, sitä varmemmin se tuottaa arvokkaita tuotoksia.
- Ekosysteemeitä hierarkkisen hallinnon sijaan.
- Varhainen ja usein toistuva altistuminen todellisuudelle.
- Osapuolilla on tasapainoinen riskijakauma.
- Ohjelmiston rakenne tukee kohtaa 1.
Katso mitä Apple, Google, Facebook ja muut uuden sukupolven teknologiayritykset tekevät, niin ymmärrät. Onko erityisiä syitä, miksi näin ei voitaisi toimia julkishallinnon IT-hankkeissa? Varmasti tuhat syytä. En vain usko, että mikään niistä kestää tarkempaa tarkastelua.
Ekosysteemeitä hierarkkisen hallinnon sijaan
Julkishallinnon IT-hankkeissa istuu norsu keskellä huonetta. Kaikesta muusta keskustellaan, mutta silmiini ei ole osunut kritiikkiä sitä kohtaan, että hankkeita vedetään täysin ylhäältä alaspäin johdettuna. Korkeintaan vaaditaan parempaa osaamista sinne norsunluutornin huipulle.
Parempi suunta olisi pyrkiä minimoimaan hallinnon määrä ja keskittyä siihen, että pystytään reagoimaan nopeasti ärsykkeisiin.
Tähän päästään mielestäni niin, että luodaan pieni ja erittäin asiantunteva organisaatio, jolla on niin korkean tason mandaatti "tehdä kaikki tarvittava onnistumisen varmistamiseksi", että asioiden hyvin tekeminen ei muutu mahdottomaksi.
Tällainen organisaatio omistaa kaiken koodin, infran yms. mitä hankkeessa syntyy. Erityisesti tämä organisaatio vastaa ns. ytimestä, joka löytyy jokaisen hyvin tehdyn tietojärjestelmän keskeltä. Käyttöjärjestelmissä sen nimi on "kernel", potilastietojärjestelmässä se on potilastietojen optimoitu tietomalli, sen toteuttava tietokanta ja nämä kaksi yhdistävä logiikka. Tämä ydin on suojattu rajapinnoilla, jotka tämä organisaatio omistaa ja joiden kehityksestä ja muutoksesta se vastaa.
Jokainen ekosysteemi siis tarvitsee ytimen. Applella on AppStore. Linuxissa on Linus Torvaldsin hallinnoima Linux Kernel. Tällaisen ytimen päälle voidaan tuottaa erilaisia laajennuksia, käyttöliittymiä, sovelluksia. Mutta niin, ettei mikään yksittäinen osa pysty rikkomaan kokonaisuutta.
Tällaisessa mallissa pärjätään pienellä ydinorganisaatiolla, muu työ voidaan kilpailuttaa. Mikä parasta se voidaan kilpailuttaa pienilläkin yrityksillä, jolloin ei olla jumissa kahdessa tai kolmessa toimittajassa, joiden välillä on ehkä kilpailua, mutta ei juurikaan eroa lopputuloksen laadussa tai hinnassa (lue: huono ja kallis).
Kun tähän lisätään hyvin tehty käyttöliittymästandardi, ei pitäisi käytettävyydessä olla suuria eroja eri osajärjestelmien kesken.
Varhainen ja usein toistuva altistuminen todellisuudelle
Sähköisen reseptin viimeaikainen uutiskynnyksen ylittänyt kompurointi on tästä mainio esimerkki. Hanketta on jossain muodossa kehitetty tai valmisteltu 1980-luvulta asti. Vuonna 2013, kun se on saatu pikkuhiljaa käyttöön, käy ilmi että järjestelmä ei ihan vastaakaan todellisuuden tarpeita.
Ei. Oikea vastaus tähän haasteeseen ei ole entistä tarkempi ja perinpohjaisempi määrittelyprojekti. Ei, vastaus ei myöskään ole juristiarmeijan laatimat sopimukset, jotka kieltävät virheiden tekemisen toimittajilta.
Ohjelmisto, joka altistuu todellisuudelle vasta kun se on valmis, on kuin ihminen joka altistuisi elämälle vasta 18-vuotiaana. Kompleksit järjestelmät (ihminen, ohjelmistot) vaativat evoluutiota tullakseen toimiviksi.
Tämä on tärkein yksittäinen asia, minkä ketterä kehitys on tuonut (takaisin) ohjelmistokehitykseen.
Todellisuus on niin monimutkainen, että sen kanssa toimivan järjestelmän on pakko kompuroida ensin, että siitä saadaan toimiva.
Ja juuri niinhän nyt on sähköisen reseptinkin kanssa käymässä. Ongelma vain on, että altistuminen tapahtuu liian myöhään. Lisäksi järjestelmä ja varsinkin sen hallinto ovat liian kankeita pystyäkseen mukautumaan tällaisiin "yllätyksiin". Sen sijaan nyt joudutaan odottamaan puolitoista vuotta(!), jotta loppukäyttäjän näkökulmasta täysin triviaali muutos saadaan tehtyä.
Ja juuri niinhän nyt on sähköisen reseptinkin kanssa käymässä. Ongelma vain on, että altistuminen tapahtuu liian myöhään. Lisäksi järjestelmä ja varsinkin sen hallinto ovat liian kankeita pystyäkseen mukautumaan tällaisiin "yllätyksiin". Sen sijaan nyt joudutaan odottamaan puolitoista vuotta(!), jotta loppukäyttäjän näkökulmasta täysin triviaali muutos saadaan tehtyä.
Osapuolilla on oltava tasapainoinen riskijakauma
Englannin kielessä on osuva sanonta "to have skin in the game". Siitä tässä on kysymys.
Julkishallinnon IT-hankkeissa erityisesti ja julkishallinnossa ylipäätään on valtava ongelma tässä suhteessa. Virheistä, vakavistakaan, ei yleensä tule seuraamuksia sen tekijöille. Toisaalta myöskään onnistumisesta ei palkita. Tämä on virkamiesjärjestelmämme pimeä puoli.
Vapailla markkinoilla sekä virheistä että onnistumisista rangaistaan/palkitaan. Käynnissä on jatkuva evoluutio, joka tuottaa koko ajan parempia ratkaisuja todellisiin ongelmiin.
Aiemmin mainitsemassani ytimen omistavassa organisaatiossa työskentelevillä julkishallinnon työntekijöillä olisi aivan ehdottomasti oltava "nahkaa pelissä". Tuntuvat rahalliset korvaukset, jos hanke onnistuu. Potkut koko porukalle, jos epäonnistuu. Näin karrikoidusti. Palkitsemisjärjestelmien asiantuntijoilla on varmasti hienosyisempiä malleja.
Ohjelmiston rakenteen on tuettava ekosysteemin rakentamista
Apotin kaltainen monoliittinen ostos (jos ollaan edelleen ostamassa Epic-järjestelmää) ei toteuta tätä vaatimusta. Kovan ytimen tunnistaminen, suunnitteleminen ja rakentaminen on erittäin vaativaa. Vielä vaativampaa on sellaisen ostaminen. En oikeastaan osaa edes kuvitella, miten sellainen ostettaisiin "valmiina".
Ihan lonkalta heitettynä miettisin itse vaikkapa Suomen terveydenhuollon IT:n omaa pilviarkkitehtuuria. Tässä pilvessä sitten ajettaisiin ytimiä, joiden ympärille voidaan vapailla markkinoilla tuottaa toimivia osasia. Tätä on ansiokkaasti edistetty Taltioni-palvelussa.
Totta kai tässäkin tarvitaan hallintoa ja valvontaa. Mutta kyseessä ei ole edelleenkään rakettitiede. Apple tutkii ja hyväksyy jokaisen sovelluksen ennen sen päästämistä AppStoreen. Ongelma on aivan varmasti ratkaistavissa, jos keskitytään ongelman ratkaisuun, eikä byrokratian laajentamiseen.
Kenties olisi kannattavampaa viedä julkisen IT:n hallinta pois puhtaasti julkishallinnollisen byrokratian piiristä, jos näyttää siltä, että asioita ei yksinkertaisesti saada toimimaan? Toimiva ratkaisu olisi valtion omistama voittoa tavoittelematon yritys. Sen henkilökunta ei olisi virkamiehiä, vaan kunnollisilla kannustimilla motivoituja ammattilaisia.
Big Bang
Lopuksi vielä muutama sananen aiheesta, josta on ainakin Facebook-ryhmässä keskusteltu, ja joka kaipaisi laajempaakin huomiota.
Suomen julkishallinnon ja etenkin terveydenhuollon rakenne on todella hajanainen. Toimijoita ja erilaisia prosesseja, johtamistapoja ja eritysvaatimuksia on käsittämätön määrä näin vähäväkiselle valtiolle. Tämä ongelma on pyörinyt paljon niissä argumenteissa, joilla on haluttu puolustaa nykyistä tehotonta ja kallista toimintakulttuuria.
Kyllä, prosesseja on muutettava, eikä tietojärjestelmä voi korjata huonoja toimintatapoja. Tietojärjestelmä voi vain tehostaa (parhaimmillaan) sitä toimintatapaa ja prosessia, jonka mukaan toimitaan muutenkin.
Mielestäni Apotissa yritetään saada aikaan ns. Big Bang, eli paljon muutosta aikaan kerralla ja keskusjohtoisesti. Ehkä ajatellaan, että vain tarpeeksi suuri ja mahtipontinen hankejärkäle saa byrokratian juoksuhaudat revittyä auki. Voi olla, mutta tulokset eivät näytä kovin vaikuttavilta tähän mennessä.
Paljon helpommin hallittavissa oleva lähestymistapa olisi rakentaa Apotin ydinjärjestelmä ja joku rajattu määrä sovelluksia ytimen päälle yhteistyössä yhden pienen ja muutokselle valmiin sairaanhoitopiirin (tai jopa yksittäisen laitoksen) kanssa. Mieluusti vielä niin, että tulevat loppukäyttäjät ovat mukana varmistamassa toteutuksen altistumista todellisuudelle alusta asti.
Kun on saatu yksi onnistuminen, voidaan alkaa neuvottelemaan muiden yksiköiden kanssa. Tässä kohtaa mielestäni vaaditaan raakaa liikemiestaitoa ja mahdollisesti jopa lainsäätäjän painostusta siihen, että jokaiselle sairaanhoitopiirille ja peräkylän terveyskeskukselle ei tehdä poikkeuksia järjestelmiin, varsinkaan sen ytimeen. Joko käytät yhteistä järjestelmää ja muutat prosessit sen kanssa yhteensopiviksi tai sitten olet oman onnesi nojassa.
