julkiset ohjelmistohankinnat Archives - Page 3 of 3

Apotti potilastietojärjestelmien portilla

Helsingin terveyslautakunta päättää huomenna 11.9. käynnistää kilpailutuksen tietojärjestelmähankinnasta, jossa HUS ja alueen kunnat käyttävät yhteensä noin puoli miljardia euroa terveydenhuollon IT:n kokonaisvaltaiseen uusintaan. Tai siis luultavasti ei päätä, vaan hanke jää pöydälle ainakin kolmeksi viikoksi.

Tässä tekstissä käyn läpi hankkeen taustan, merkittävimmät riskit ja mitä sille pitäisi tehdä.

Taustalla on tavoite hankkia koko maan terveydenhuoltoon yhtenäinen tietojärjestelmä. Sitra selvitti tätä SIRIUS-hankkeessa, jossa selvityksen tehnyt Accenture päätyi suosittamaan, että ostakaa koko roska Accenturelta.

Alkujaan HUS:n ja kuntien hanke oli nimeltään SIRIUS 2, mutta kun Hesari uutisoi Accenturen roolista Siriuksessa, vaihtui nimeksi nykyinen APOTTI. Hankkeilla kun ei kuulema ole juuri mitään tekemistä keskenään. HUS:in hanketta vetävä hallintoylilääkäri Lasse Lehtonen ilmoitti että ”Kritiikki ei vaikuta  HUS:n potilastietojärjestelmän hankintaan”.

Nyt päätöstä tekee siis Helsinki. HUS, Espoo, Vantaa, Kauniainen, Kirkkonummi, Kerava tekevät sitten kukin tahoillaan saman päätöksen. Tätä ennen kuntien virkamiestyöryhmä on ensin sen suljettujen ovien takana hyväksynyt. Menettelyä voi syystäkin pitää epädemokraattisena, mutta tätä kuntayhteistyö käytännössä on. Ei mennä siihen nyt, tulee vaan paha mieli.

Apotti Saint Dominic of Silos.

Kyse ei ole pelkästä IT-hankkeesta. Päinvastoin, tavoitteena on uudistaa toimintatavat ja prosessit yhdenmukaisiksi ja järkeviksi. Tavoite on kiistatta hyvä. Pitää pyrkiä hyvään toimintaan, ja tietojärjestelmä on tässä vain apuväline. IT-hankkeiden hyödyt tulevat juuri toimintatapojen muutoksista; pelkkä vanhan toimintatavan siirto tietokoneelle ei tuo minkäänlaisia säästöjä vaan ainoastaan lisätyötä.

Yhtenä esimerkkinä hankkeelle on ilmeisesti toiminut USA:laisen Veterans Health Administrationin (VHA) uusiutuminen maan surkeimmasta terveyspalvelujen tuottajasta kärkijoukkoon vuosikymmenessä. VHA:ssa toteutettiin merkittävä toimintatapopjen uudistus, jonka yhteydessä vanha ja huonosti toimiva tietojärjestelmä päivitettiin pala kerrallaan nykyaikaiseksi. Venkatesh et al. kuvaavat artikkelissaan hyvin muutosta ja niitä toimintatapoja, joilla siihen päästiin.

Apotin tavoitelista on myös melkoinen toiveiden tynnyri. Tavoiteltu järjestelmä muun muassa:

tarjoaa uusien innovatiivisten palvelujen käytön, asiakkaan oman osallistumisen ja sähköisen asioinnin. Asiakkaan vahvempi osallistuminen lisää tyytyväisyyttä ja voimaantumista vähentäen ulkopuolisen tuen tarvetta.
toteuttaa parhaalla mahdollisella tavalla asiakkaan ja potilaan hoidon toteuttamista koko hoitoprosessin ajan riippumatta siitä, missä organisaatiossa kukin hoitoprosessin vaihe tapahtuu.
tarjoaa sosiaali- ja terveydenhuollon prosessien tehokkaan ja taloudellisen integraation muiden organisaatioiden ja heidän asiakkaidensa prosessien kanssa.
mahdollistaa sen, että kulloisessakin hoitotilanteessa asiakkaan ja potilaan ajantasaiset tiedot ovat luotettavasti käytettävissä.
tarjoaa hoitoprosessin eri hoitotapahtumien tuen, ohjauksen ja seurannan.
tukee uusien hoitoprosessien aktiivista kehittämistä ja edistää hoitoprosessin laatua, asiakas- ja potilasturvallisuutta sekä kustannustehokkuutta.
tukee ammattilaista päätöksenteossa ja ohjaa standardin mukaisiin ratkaisuihin vähentäen toimintatapojen vaihtelua ja parantaen asiakas- ja potilasturvallisuutta sekä hoitotuloksia.
mahdollistaa avoimet rajapinnat, joiden kautta kokonaisratkaisuun voidaan liittää tulevaisuuden tarpeita palvelevia lisätoiminnallisuuksia tai vaihtaa yksittäisiä ratkaisun osia.
sisältää tiedonsiirtorajapinnan muihin tarvittaviin, kuten esimerkiksi hallinnollisiin järjestelmiin.
on käyttäjäystävällinen.
toteuttaa sähköisesti modernin käyttöoikeushallinnan, tietoturvan ja suojan sekä niihin liittyvät sujuvat käytännöt (hoitoketjujen hallinta / roolien mukaiset käyttöoikeudet).
mahdollistaa yhteisen järjestelmän hallinnan ja hyödyntämisen usean erillisen järjestelmän sijasta.
tukee vuoden 2011 alusta voimaan tulleen kotikuntalain muutoksen (1377/2010) ja terveydenhuoltolain (1326/2010) vuonna 2014 voimaan tulevan maanlaajuisen vapaan hakeutumisen sujuvaa toteuttamista.
tuottaa hallinnolle ja tutkimukselle tarpeellisia tietoja

Onnistuneiden hankkeiden tavoitteet ovat yleensä kapeasti määriteltyjä ja täsmällisiä. Jos olisin päättämässä asiasta, kysyisin että täsmälleen miten jokainen näistä tavoitteista aiotaan saavuttaa ja miten sitä mitataan.

Minulla on hankkeen suhteen muutama spesifi huoli, niistä alla kolme tärkeintä:

Yritetäänkö tässä ulkoistaa vastuuta?
Riittääkö osaaminen?
Onko valittu teknologia järkevä?

Vastuun ulkoistus

Lääkärilehdessä Lehtonen toteaa, että ”sairaanhoitopiirillä on huonoja kokemuksia järjestelmän kehittämisestä. Se haluaa ostaa valmiin tuotteen ja palvelun, jossa toimittaja vastaa ylläpidosta. Kehitysriski on silloin toimittajalla.”

Näkemys on sivistyneesti sanoen vaarallisen naivi ja herättää epäilyksen, ymmärretäänkö HUSissa oikeasti mitä ollaan tekemässä. Ei tilaajan tarpeisiin laajasti muokattavaa järjestelmää yksinkertaisesti voi ostaa noin. Tälläinen ”avaimet käteen”-toimitus antaa käytännössä toimittajalle avaimet käteen suoraan tilaajan kassaholviin.

Missään organisaatiouudistuksessa ei voida määrittää etukäteen kaikkia tarpeita. Päinvastoin, ja kuten mainittu VHA:n esimerkkikin osoittaa, on syytä edetä askel kerrallaan. Siksi nykyään suuretkin tietojärjestelmähankkeet pyritään tekemään ns. ketterillä menetelmillä, joissa ei sitouduta täsmälliseen määrittelyyn, vaan opitaan vaatimukset projektin aikana.

Tietenkin voidaan ajatella, että ketteryyttä sovelletaan toimittajayrityksen sisällä, ja HUS vaan saa mitä haluaa: toimivan järjestelmän. Mutta kuinka toimittava yritys voisi päättää sairaanhoitopiirin toimintaprosesseista, jota tässä siis ensisijaisesti haluttiin uudistaa? Ei mitenkään.

Vastuuta omista tietojärjestelmistään ei voi koskaan ulkoistaa. Tietojärjestelmiä tuntemattomalle syntyy helposti houkutus kuvitella että kokonaistoimitus ratkaisee ongelmat. Että IT-toimittaja kyllä hoitaa nämä IT-ongelmat. Mutta ei ole hoitanut tähän mennessäkään, vaan päinvastoin terveydenhuoltoalan IT:tä pidetään katastrofina.

On syytä myös huomata, että yllä mainittu Veterans Health Administration omistaa itse potilasjärjestelmänsä (VistA) lähdekoodin ja jakaa sitä avoimena lähdekoodina. En sano, että VistA mitenkään välttämättä sopisi HUSille, mutta oman tietojärjestelmänsä hallinta on VHA:n onnistuneen muutoksen ytimessä.

HUS ja kunnat sen sijaan tähätäävät malliin, jossa tilaajalla ei ole hallintaa tietojärjestelmään, vaan kaikki kontrolli on sysätty toimittajalle. Tämä asettaa HUSin täydelliseen toimittajaloukkuun. Mikään määrä määrittelyjä tai sopimusehtoja ei voi tätä loukkua välttää, mistä HUSilla pitäisi olla jo pitkä kokemus.

Kompetenssi

Sairaalamaailma on kuuluisa siitä, että lääkärintutkinto on avain etenemiseen, eikä muita kuin lääkäreitä haluta päästää johtopaikoille. Tämä näkyy myös Apotti-hankkeessa.

Apotin ohjaus- ja kehittämisryhmissä on yhteensä 47 jäsentä, joista nopeasti googlaten:

19 lääkäriä
23 erilaista hallintohenkilöä, juristia tai ekonomia
5 joiden työtehtävä liittyy tietohallintoon tai -tekniikkaan. Heistä

2 valtiotieteen maisteria
1 ekonomi
1 tradenomi (logistiikka)
1 jonka koulutus ei selvinnyt.

Näyttäisi siltä, että hanketta vetämässä ei kenties ole yhtäkään IT-alan minkäänlaista tukintoa suorittanutta henkilöä. Muutamilla toki on alan työkokemusta, mutta varsinaista koulutusta ei.

Suomalainen lääkärinkoulutus on vaativa ja korkeatasoinen. Se ei silti pätevöitä märittelemään suuria tietojärjestelmiä. Sitä varten on olemassa ihan omaa koulutustaan.

Teknologia

Apotti-hanke tähtää vahvasti yhteen monoliittiseen järjestelmään. Siis sellaiseen, joka tarjoaa ulospäin vain kauniisti toimivia rajapintoja ja käyttöliittymiä, eikä sisäisestä toteutuksesta tarvitse kenenkään olla kiinnostunut. Esimerkiksi hankkeessa kaikki tiedot halutaan tallettaa yhteen loogiseen tietokantaan (hankesuunnitelma, kappale 2.2.2).

Siis samassa kannassa kaikki tiedot, sisältäen muun muassa:

hoitokertomukset
asiakkaiden laskutustiedot
sosiaalihuollon asiakastiedot (kyllä, joku on nekin tunkenut osaksi hanketta)
sairaalan toiminnanohjaus sisältäen laitteistojen käytön

Moderneissa järjestelmissä vastuu pyritää pilkkomaan mahdollisimman pieniin osiin, jotta kukin osajärjestelmä voi tehdä yhden asian hyvin. Esimerkiksi SOA-arkkitehtuuri perustuu tähän periaatteeseen. HUS on valitsemassa vanhanaikaisen monoliittisen arkkitehtuurin, jossa kaikki integroidaan tiukasti yhteen. Tai mikäli pellin alla onkin hyviä rajapintoja, HUS ei halua niitä tietää, vaan ne ovat toimittajan sisäinen asia.

IT-alan yleinen kokemus on, että modernit arkkitehtuurit toimivat paremmin kuin vanhanaikaiset.

Ajatus yhtenäisestä järjestelmästä on ymmärrettävä, kun seuraa suomalaisten potilastietojärjestelmien kaaosta. Mutta ongelma ei ole järjestelmien hajanaisuus. Tanskassa vastaava kokonaisuus toimii hyvin. Ongelma on ostamisen tavassa ja osaamattomuudessa.

Yhteenveto

Onnistuvan laajan tietojärjestelmähankkeen lähtökohtana täytyy nähdäkseni olla:

vahva oma osaaminen tietojärjestelmän kehittämisessä
sen mahdollistama asiakkaan hallintaote siihen, mitä ja miksi kehitetään.

Epäonnistuvat hankkeet taas tunnistaa usien seuraavista merkeistä:

Vaatimusmäärittely on maailmojasyleilevä: samaan hankkeeseen on kasattu kaikki maan ja taivaan välillä.
Tilaaja pyrkii ulkoistamaan vastuun omasta järjestelmästään.
Suunniteltu toimintatapa on epätarkoituksenmukainen eikä vastaa alan parhaita käytäntöjä.

Mitkään merkit eivät nyt viittaa siihen, että kumpaakaan onnistumisen avainkohtaa olisi saavutettu. Päin vastoin, epäonnistumislistalta löytyy rasteja.

Hankkeen oma riskianalyysi (hankesuunnitelma, kappale 6.7) ei näitä ongelmia tunnista. Se mainitsee kaksi riskiä: johtamisongelmat ja sen että entä jos hanke ei toteudu. Tietojärjestelmään tai hankintaprosessiin liittyviä riskejä ei mainita.

Päätösehdotus

No, mitä terveyslautakunnan sitten pitäisi päättää?

Hankkeessa on syytä ottaa aikalisä, ja valmistella se uudelleen avoimemmin. Aivan erityisesti hanke on syytä valmistella siitä lähtökohdasta että kokonaisvastuu pidetään tiukasti tilaajan hyppysissä.

Erityisesti on syytä katsoa malleja, jossa ei tehdä yhtä mammuttihankintaa, vaan vaihdetaan järjestelmiä pala kerrallaan perustuen tilaajan hallitsemaan kokonaisarkkitehtuuriin ja ketterään hankintaan.

Tähän mennessä tehdyt selvitykset ja vertailut julkaistaan kaikki. Ainakin seuraavat dokumentit pitää julkaista
- Touko–kesäkuussa 2012 tehdyn ulkoinen riskiarvio (viitattu hankesuunnitelmassa, kappale 6.7.)
- HUSin selvitykset muissa Euroopan maissa tehdyistä vastaavista
- myös dokumentit, joiden olemassaolo ei toistaiseksi ole vuotanut julkisuuteen pitää julkaista

Perehdytään tarkasti Viron ja Tanskan kokemuksiin ja mitä niistä voitaisiin oppia. Teetetään molemmista konsulttiselvitykset, mikäli olemassaolevat (julkaistavat) selvitykset eivät ole riittäviä.

Tarvittaessa hankkeen johtoa vahvistetaan riittävällä tietojärjestelmäosaamisella. Konsultit eivät riitä korvaamaan oman osaamisen puutteita.

Suomen, Viron ja Tanskan ”eHealth-profiili” EU:n ”eHealt Benchmarking III” -raportissa

Terveydenhuollon IT on Suomessa historiallisesti ollut suljettu luostari, jossa lääkärit päättävät keskenään mitä ja miten tehdään. Tuloksena on ollut katastrofi toisensa jälkeen. Se on ollut maan tapa.

Nyt on kyse siitä, onko apotti tullut luostarin portille avaaman sen ja kutsumaan rahvaan tutustumaan saleihin. Vai onko hän ehkä tullut nostamaan salvan säppiin, jotta mokailu ja sikailu voisi jatkua entiseen malliin.

Vastausta emme vielä tiedä, mutta se portti on avattava. Maan tapa on nyt tullut tiensä päähän.

Otso valtuustoon 2012

Tarkkaavaisimmat ovat jo ehkä huomanneet, että noin kahden kuukauden kuluttua järjestetään maassamme kuntavaalit.

Viime torstaina Facebook-sivuni saavutti 720 tykkääjän rajan. 720 on myös äänimäärä, jolla pääsi viime vaaleissa valtuustoon Vihreiden listalla. Tykkäämisellä ja äänestämisellä ei tietenkään ole mitään tekemistä keskenään, mutta numerot ovat kuitenkin samat, mikä on hyvä symbolinen lähtölaukaus vaalikampanjalle. 720 on enemmän kuin useimpien nykyisten valtuutettujen sivulla. Se osoittaa, että hanke on täysin realistinen.

Tämä teksti kertoo miksi sinun kannattaa auttaa minua pääsemään valtuustoon ja miten voit auttaa.

Mistä on kyse

Kyse on tiedosta. Suomessa aiotaan käyttää miljardeja sairaaloiden tietojärjestelmiin tavoilla, jotka ovat epäonnistuneet aina ennenkin. Ajan toimintatapojen päivitystä sellaisiksi, että hankkeet edes voivat onnistua, niin sairaanhoitopiirissä kuin kaupungissakin. Kaupungin tulee myös avata tietovarantonsa ja lähdekoodinsa.

Kyse on kaupungista. Siitä, miten ja minne Helsinkiä rakennetaan. Seudulle on muuttamassa yli 400 000 asukasta lisää. Haluan heille korttelikaupunkia nykyisten moottoriteiden tilalle eikä kolmen talon ryppäitä pitkin Nummi-Pusulaa. Viimeiset 50 vuotta Helsingissä on tehty autoiluun perustuvaa ja kaupunkia hajauttavaa politiikkaa. On aika kääntää tämä kurssi ja rakentaa lisää tiivistä kaupunkia. Sitä, jossa moni asuisi jos voisi.

Kyse on pyöräilystä. Helsingin pyöräteiden kunto on samalla tasolla kuin kadut Romaniassa. Viime vuosina suunnitelmia on onneksi alettu muuttaa vastaamaan jyrkästi nousevia pyöräilijämääriä. Kokemukseni pyöräilyn edistämisessä on kuitenkin opettanut, että muutos ei todellakaan tule itsestään, vaan se on tehtävä. Jokaisesta reunakivestä ja pyörätielle pysäköidystä autosta joutuu taistelemaan erikseen.

Kyse on politiikasta. Tavasta toimia. Siitä, että päätösten tueksi perehdytään tutkimukseen ja haetaan toimivia ratkaisuja, eikä vain toimita ennakkoluulojen perusteella.

Nämä eivät ole asioita, joita ajan jos pääsen valtuustoon. Nämä ovat asioita, joita ajan joka tapauksessa. Valtuuston jäsenyys on tarpeen, koska se antaa painoarvoa ja pääsyn tietoihin, jotka mahdollistavat tehokkaamman toiminnan.

Mitä voit tehdä

Mitään näistä tavoitteista ei voi saavuttaa yksin; kaikkeen tarvitaan yhteistyötä. Toivonkin että jokainen lukija miettii, miten voisi tehdä Helsingistä paremman kaupungin ja ryhtyy toimeen.

Koska vaalijärjestelmämme kuitenkin on mitä on, pyydän myös että autatte minua pääsemään valtuustoon lokakuun kuntavaaleissa.

Tässä siis lista asioista, joita voit tehdä auttaaksesi

Äänestää, jos asut Helsingissä. Vaalipäivä on 28.10., ennakkoäänestys 17.–23.10.

Tykätä Facebook-sivustani, sekä Kommentoida julkaisuja.

Jakaa blogitekstejäni eteenpäin silloin, kun ne ovat jakamisen arvoisia. Huonoja tekstejä ei tietenkään kannata jakaa, vaan ainoastaan niitä jotka vakuuttavat.

Liittyä tukiryhmään suunnittelemaan ja totettamaan vaalikampanjaa. Pistä viesti minulle maililla (etunimi sukunimi (at) iki fi) tai FB:ssä. Liittyminen ei edellytä julkista kannanottoa ja työtä voi tehdä sen verran kun ehtii ja haluaa. Kommenteista ja ideoista on myös paljon apua.

Suositella tutuillesi minua ehdokkaana sopivissa tilanteissa.

Jakaa vaalimainoksia ja kampanjoida kaduilla lokakuussa. Jos pääset avuksi, ota yhteyttä. Lisätietoja seuraa aikanaan…

Lahjoittaa rahaa vaalikampanjaan. Mainokset maksavat ja niitä on vähän pakko olla. Kokonaisbudjetti ylittää 5 000 euroa. Koska en ole rajattoman varakas, rahallisesta avusta on merkittävä ilo. Se saattaa valitettavasti ratkaista läpipääsynkin.
Lain sallima maksimilahjoitus on 3000 euroa ja Vihreiden periaatteena on julkaista yli 800 euroa antaneiden nimet aina. Tätä pienemmistäkin lahjoituksista on suurta iloa, ihan kympistä lähtien.

Rahaa voi lahjoittaa tästä. Näen vain julkistetut lahjoittajat, eli jos haluat että ajattelen sinua kiitollisesti, kerrothan minulle erikseen.

Vaalit tarkoittavat myös joitakin muutoksia blogissa. Tulen toistaiseksi kirjoittamaan hiukan enemmän asiaa ja hiukan vähemmän asiattomuuksia. Palataan niihin sitten vaalien jälkeen. Osoitteeksi tulee myös pian muuttumaan otsokivekas.fi.

Toimittajaloukku ja kuinka se vältetään

Taannoinen kirjoitukseni sairaaloiden tietojärjestelmistä sai jonkin verran huomiota, ja myös Hesari innostui aiheesta eilen kirjoittamaan. Eniten huomiota on saanut Accenturen toiminta ja sen moraaliset aspektit. Se on lopulta kuitenkin vain sivujuonne. Oikea ongelma on siinä, miten tietojärjestelmiä ostetaan, ei siinä miten niitä myydään.

Tilanne ei juuri muuttuisi, vaikka järjestelmäksi valittaisiinkin Cerner ja toimittajaksi Logica, tai vaikka Effica ja Tieto. HUS on joka tapauksessa ostamassa yhtä järjestelmää yhdeltä toimijalta, joka samainen toimija tulee sitten toimittamaan myös järjestelmän kustomoinnit, uudet versiot ja tulevaisuudessa tarvittavat lisätoiminnallisuudet. Koska on vain yksi toimittaja, joka voi ne toimittaa.

Tätä kutsutaan toimittajaloukuksi (engl. vendor lock-in). Se tarkoittaa tilannetta, johon varomaton tietojärjestelmän ostaja joutuu valittuaan järjestelmälle toimittajan: kaikki muutostyöt on pakko ostaa samalta toimittajalta, ja tämä voi rahastaa niillä lähes miten haluaa. Myös huono laatu ja hitaus ongelmien korjaamisessa kulkevat yleensä käsi kädessä toimittajaloukon kanssa.

Alalla vuosikymmeniä toiminuttu myyjää lainatakseni, ”Suomessa on haluttu rakentaa järjestelmä, jossa tuotteet myydään halvalla ja raha tehdään ylläpidolla sekä muutostöillä”. Toimittajan vaihtaminen ei siis ratkaise ongelmia.

Koska koen tietynlaista vastuuta myös ratkaista esiin nostamani ongelmat, esittelen tässä kolme tapaa, jolla HUS voisi yhden toimittajan loukun välttää.

Lähtökohta on, että tietojärjestelmä ei koskaan ole valmis tuote. Sitä ei voi ostaa valmiina ja ”vain käyttää”, vaan käyttöönotto on raskas prosessi, jossa sekä muutetaan järjestelmää että muutetaan organisaation toimintatapoja. Ja käyttöönoton jälkeen muutostarpeet jatkuvat. Unohtuneita tarpeita huomataan, ja uusia syntyy.

Mutta tässä ne kolme optiota HUS:lle

Optio 1) sorsat käteen

Mikäli HUSilla olisi pääsy ja käyttöoikeus ostamansa järjestelmän lähdekoodiin, voisi sairaanhoitopiiri teettää haluamansa muutokset kenellä haluaa, tai vaikka tehdä ne omassa IT-organisaatiossa. Tällöin muutostyöt eivät olisi yhtä hitaita ja kalliita, koska niitä tilattaessa vallitsisi ainakin jossain määrin aito kilpailutilanne.

Toki järjestelmän alkuperäisellä tekijällä (ja muilla sen kanssa työskennelleillä) olisi etulyöntiasema, mutta se olisi merkittävästi nykytilannetta pienempi. Toimittajan vaihtamisen kustannus ei olisi satoja miljoonia, vaan ehkä vain satoja tuhansia, joten mahdollisuudet rahastamiseen tai slarvaamiseen olisivat selvästi pienemmät.

Tämä on se ratkaisu, jota aiemmassa kirjoituksessani ehdotin. Käytännössä tämä vaatisi yhtä lisäehtoa tietojärjestelmän kilpailutukseen: ”Osana kauppaa ostaja haluaa järjestelmän koko lähdekoodin, tarvittavat ohjeet ja koulutuksen sen käyttöön sekä oikeuden tehdä itse tai teettää muutostöitä vapaasti haluamallaan toimittajalla.” Juridisesti sitovana ehto olisi varmasti paljon pidempi, mutta olennainen sisältö on tuossa.

On epävarmaa, suostuisivatko ulkomaiset toimijat kuten Epic tai Cerner tällaiseen ehtoon. Voi olla, että eivät. Kotimaiset toimijat luultavasti suostuisivat: jos kukaan ei heiltä enää ostaisi tietojärjestelmää kuin sikaa säkissä, joutuisivat he myymään sitä sisuskaluineen kaikkineen. Palkinto on liian suuri, jotta Tieto tai Logica heittäisi pyyhkeen kehään.

Optio 2) open source

Toinen vaihtoehto on avoin lähdekoodi. HUS voisi vaatia ehtona, että ostettavan järjestelmän koko lähdekoodi julkaistaan avoimella lisenssillä. Tämä poikkeaa ensimmäisestä vaihtoehdosta siinä, että myös muut kuin HUS pääsisivät käyttämään koodia. Eniten hyötyisivät muut sairaanhoitopiirit, jotka saisivat HUSin järjestelmän käyttöönsä ilmaiseksi, mutta myös HUS hyötyisi, koska avoimuus tehostaa kehitystyötä monin tavoin. Sitä paitsi HUS saisi sitten muiden muutostyöt myös itselleen käyttöön.

Kehityksen lähtökohtana voisi toimia jokin nykyinen potilastietojärjestelmä, valmis avoimen lähdekoodin järjestelmä, kuten USA:n veteraaniterveydenhuollon VistA, tai se voitaisiin kasata tyhjältä pöydältä. Yksikään ratkaisu ei ole ongelmaton. Nykyiset järjestelmät ovat juuri niitä, joita kovasti kritisoidaan, eikä toimittajien halukkuudesta avata koodinsa ole mitään varmuutta. VistA taas sisältää samaa arkaaista MUMPS-kieltä kuin EPICkin eikä amerikkalaisena välttämättä sovellu suoraan Suomen terveydenhuolto-organisaatioon. Ja tyhjältä pöydältä kehittäminen on aina työlästä ja osin riskaapelia.

Optio 3) pilkonta, rajapinnat ja vahva yhteistyö

Tanskassa terveydenhuoltoalan tietojärjestelmät ostetaan pienehköissä osissa: yksi järjestelmä kerrallaan. Eri sairaanhoitopiirit ostavat kuka mistäkin. Alan toimijat – niin yritykset kuin viranomaisetkin – määrittelevät yhteistyössä rajapinnat ja tiedonsiirtostandardit, joita noudattaen järjestelmät toimivat sulavasti yhteen. Kokonaisuutena Tanskassa on ”ekosysteemi” terveydenhuoltoalan tietotekniikkaa tekeviä yrityksiä.

Paperilla järjestelmä kuulostaa melko samantapaiselta kuin Suomessakin. Erona on, että Tanskassa se toimii, kun suomalainen terveydenhuollon IT on katastrofi. Juutit siis ilmeisesti tekevät jotain oikein.

Jari Forsström et al kuvaavat raportissa ”Terveydenhuollon tietojärjestelmät ja Suomi” miten Tanskan ja Ruotsin vastaavat alat toimivat, sekä esittävät näkökantoja siitä, miten potilastietojärjestelmien uudistusta tulisi Suomessa tehdä. Heidän keskeinen johtopäätöksensä on:

Terveydenhuollon kokonaisjärjestelmään sisältyy suuria riskejä.
Hajautetuista ratkaisuista, ohjelmistojen ekosysteemistä, on pohjoismaista hyviä kokemuksia.
Terveydenhuollon tietojärjestelmäkustannuksista noin puolet koostuu henkilötyöstä, joten toimialalla on merkittävä työllistävä vaikutus. Suomalaisen IT-osaamisen taso on korkea ja sitä tulisi voida hyödyntää näin mittavassa kansallisessa hankkeessa.

Käytännössä Suomessa Terveyden- ja hyvinvoinnin laitoksen (THL) pitäisi ottaa vetovastuu ja johtava rooli sairaanhoidon tietojärjestelmäekosysteemin kehittämisestä. Samaan tapaan kuin Tanskan Medcomilla on. THL tosin on taustaltaan tutkimusorganisaatio, eikä muutos ohjaavaksi viranomaiseksi varmasti olisi sille ihan helppo.

Hajautetummassa kehityksessäkin on riskinsä. Jos halua yhteentoimivuuteen ei ole, ei sitä myöskään synny. Standardit voidaan määritellä paitsi hyvin, myös huonosti. Järjestelmiä hankittaessa pitää myös oikeasti ymmärtää, mitä ollaan hankkimassa ja miten se suhtautuu muihin jo hankittuihin järjestelmiin. Tanskassa on saatu aikaan koko alaa koskeva yhteinen henki ja halu tehdä yhdessä järjestelmistä hyviä. Suomesta tämä toistaiseksi puuttuu.

Perinteinen ja moderni terveydenhuollon tietojärjestelmän arkkitehtuuri Forsströmin et. al mukaan. Suomessa käytössä olevat ja Sirius-hankkeessa ehdotetut uudet järjestelmät perustuvat vanhaan monoliittiseen arkkitehtuuriin.

Johtopäätökset

Kaikille kolmelle vaihtoehdolle on yhteistä, että ostaja joutuu tekemään selvästi nykyistä enemmän ja parempaa työtä. Tilaajan puolelle pöytää tarvitaan nykyistä enemmän ammattitaitoa sekä sairaalan hallinnoinnista että erityisesti nykyaikaisesta tietojärjestelmien kehittämisestä.

Tietojärjestelmät muodostavat nykyään organisaation kuin organisaation toiminnan ytimen. Ne ovat se luuranko, jonka varassa organisaatiot liikkuvat. Jos ei tietojärjestelmää soviteta organisaation toimintatapaan, täytyy toimintatavat sovittaa järjestelmään.

On vaarallista fantasiaa kuvitella, että tällaisen ydintoiminnon voisi ostaa valmiina ulkoa ymmärtämättä sen toimintaa itse. Ajatus ulkomaisesta potilastietojärjestelmästä, joka ”vaan toimii” on hopealuoti: fiktiivinen ratkaisu kaikkiin ongelmiin. Se on käärmeöljyä, ei lääketiedettä.

Ihmepillereitä ei ole, vaan terveys perustuu elämäntapoihin; samaan tapaan potilastietojärjestelmän toiminta perustuu organisaation toimintatapoihin. Mikään ratkaisu, jossa ei muuteta sairaanhoitopiirien tapaa ostaa ja tuottaa tietojärjestelmiä, ei tule ratkaisemaan ongelmia.

Kaikki kolme ehdotusta sisältävät myös ongelmia ja riskejä. Yksikään niistä ei ratkaise terveydenhuoltoalan nykyisiä ongelmia mitenkään itsestäänselvästi. Siksi paras mitä osaan suositella on, että jokaista näistä vaihtoehdoista – ja muitakin – tutkitaan tosissaan, ja etsitään paras mahdollinen tapa välttää toimittajaloukku.

Sillä jos jokin on varmaa, niin se, että perinteisenä könttäkauppana ei Suomessa tulla koskaan ostamaan onnistunutta potilastietojärjestelmää. Epäonnistuminen on prosessin sisäänrakennettu ominaisuus.

Tietojärjestelmistä päättää viime kädessä HUSin hallitus. En kehota häiritsemään kenenkään kesälomaa, mutta meillä, jotka ymmärrämme tietojärjestelmiä on vastuu, että he tietävät mistä ovat päättämässä.

Edistääkseni asiaa loin adressin, jonka toivon lukijoiden allekirjoittavan. Siinä vaaditaan HUSin hallitusta selvittämään mahdollisuudet välttää toimittajaloukku. Mitään yksittäistä nimenomaista ratkaisutapaa ei vaadita, ainoastaan katastrofaalisen virheen välttämistä. Addressi toimitetaan alkusyksystä HUSin hallitukselle.

Keskustelualustaksi loin myös Facebook-ryhmän Terveydenhuollon IT korjattava. Liittykää sinnekin, ketkä FB:tä harrastatte ja haluatte aihetta seurata.

Kolmantena tapana vaikuttaa ovat vaalit. Kysykää ehdokkailta, mitä he aikovat tehdä, jotta terveydenhuollon IT-järjestelmien katastrofi saadaan tulevina vuosina korjattua. Erityisesti kysykää tätä sairaanhoitopiirien hallituksissa istuvilta.

Epic fail, eli sairaaloiden IT eilen, tänään ja huomenna

Kaikki nykyään tietävät, että terveydenhuollon IT-järjestelmät tulevat tuhottoman kalliiksi ja toimivat luvattoman huonosti. Erityisesti valtiontalouden tarkastusvirasto avautuu aiheesta säännöllisesti ja asiaa puidaan jo eduskunnassakin. Ylen sanoin, ”Terveydenhuollon it-hankinnoissa lähes kaikki on mennyt pieleen”

Mutta miksi on näin? Pieni tapausesimerkki ehkä valaisee tilannetta. Dickensin kolme aavetta johdattavat teemaan.

Ensin vuorossa menneiden IT-hankkeiden aave.

Helsingin ja uudenmaan sairaanhoitopiiri (HUS) on perinteisesti käyttänyt potilastietojärjestelmänään Uranusta (sama kuin Miranda). Sen kehittämisestä vastasi alkujaan Medici data oy, jonka viisi sairaanhoitopiiriä yhdessä omistivat. Yhtiöitettyä omaa tuotantoa siis. 2007 Medici data myytiin Logicalle (silloin WM-data) hintaan, joka salattiin. Ratkaisun oli tarkoitus helpottaa järjestelmäintegraatioita, koska Logica teki runsaasti muitakin terveydenhuollon järjestelmiä. Alkuperäisessä sopimuksessa HUS sitoutui ostaman Logicalta päivityksiä 700 000 eurolla vuosittain 2012 asti. Todelliseksi kustannustasoksi kuitenkin muodostui 2-3 miljoonaa euroa vuodessa.

Nyt Uranuksesta ollaan luopumassa. Tavoiteltuja integraatiohyötyjä ei saatu, ja järjestelmän käytettävyydestä on tullut paljon valituksia. Koska sairaalaa ei kuitenkaan voi jättää tyhjän päälle, osti HUS vielä kolmen vuoden tuen ja pienkehityksen Uranukseen Logicalta. Hinta oli 15,7 miljoonaa euroa, eli yli viisi miljoonaa vuodessa. Osto tehtiin ilman kilpailutusta, koska vaihtoehtoja ei oikeastaan ole. Tietoviikon sanoin ”Hankinta on tehty ilman kilpailutusta, koska Uranus-potilastietojärjestelmä on Logican kehittämä ja yhtiö omistaa sen oikeudet.” Alkuperäisen kehitystyön toki maksoivat sairaanhoitopiirit.

Alalla toimivan lähteen arvion mukaan sopimuksen sisältämät työt olisi saanut ostettua markkinoilta noin miljoonalla per vuosi. Loput neljä miljoonaa kuluvat siis käytännössä siksi, että Logica on palvelun ainoa mahdollinen tarjoaja, ja voi hinnoitella työnsä kuten haluaa. Monopolimyyjän markkinat ovat tällaiset. (En väitä, että ne ovat kaikki katetta, vaan suuri osa tuhrautuu myös tehottomaan tai turhaan työhön).

Tähän mennessä siis on ensin koodattu järjestelmä itse, sitten myyty se, luultavasti lähes ilmaiseksi isolle IT-talolle. Iso IT-talo on nostanut hintoja ensin vähän ja sitten paljon, mutta pakko on maksaa koska toimittajalla on monopoli järjestelmäänsä. Laatu ei myöskään ole ainakaan parantunut vuosien varrella. On hyvin ymmärrettävää, että HUS haluaa luopua järjestelmästä.

Sitten kuvaan astuu nykyisten IT-hankkeiden aave

Uranuksen tilalle ollaan tuomassa uutta, kansallista yhtenäistä potilastietojärjestelmää. Sitra teetti Accenturella selvityksen kuinka Suomessa voitaisiin yhtenäistää terveydenhuollon potilastietojärjestelmät ostamalla ulkomailta valmis järjestelmä. Sirius-hankkeen projektipälliköt ja lähes koko projektiryhmä olivat joko HUSin tai Accenturen palkkalistoilla, vaikka muodollisesti hankkeen organisoi Sitra. Käytännössä ajatus on, että uusi järjestelmä tuodaan ensin HUSille ja sitten muualle maahan (sivumennen sanoen tämä on ihan järkevä tapa toimia, ei siinä mitään).

Selvityksessä parhaaksi järjestelmäksi todettiin amerikkalainen Epic ja toiseksi tuli myöskin amerikkalainen Cerner. Jatkotoimenpiteinä HUS aloitti Sirius 2 -hankkeen, jossa valmistellaan varsinaista järjestelmän kilpailutusta, ja Accenture hankki oikeudet myydä Epic-järjestelmää Suomessa (*).

Tässä kohti kannattaa taas pysähtyä hetkeksi. Olemme siis tilanteessa, jossa on konsultin avustuksella käytännössä päätetty, mikä järjestelmä tullaan valitsemaan. Samainen konsultti on nyt ainoa taho, jolta tuon järjestelmän voi saada. On siis Accenturen ehdotuksesta käytännössä päätetty, että potilastietojärjestelmät koko suomeen tulee toimittamaan Accenture.

Terveydenhuollon ATK-päivillä niin Accenturen kuin HUS:inkin edustajat löysi parhaiten Epicin tiskiltä. Lapussa lukee ”Olemme Epicin ständillä. Tervetuloa”

Ja kerrontavastuu siirtyy nyt tulevien IT-hankkeiden aaveelle

Seuraavaksi HUS kilpailuttaa potilastietojärjestelmän hankinnan syksyllä 2012. Accenture tarjoaa Epicciä, Logica tarjonnee Cerneriä. Muitakin varmasti osallistuu.

Accenture voittaa kilpailutuksen, ja alkaa viiden vuoden projekti, jossa Uranus korvataan Epicillä. Kahdeksan vuoden sisään kaikki muutkin suomen potilastietojärjestelmät korvataan Epicillä. Kustannuksiksi arvioidaan 1.2 – 1.8 miljardia euroa, josta 60% menee Accenturelle ja Epic Systemsille. Loput ovat sairaanhoitopiirien omia kuluja.

Alun jälkeen hankinnat tullaan tekemään ilman kilpailutusta; muita vaihtoehtoja ei oikeastaan ole. Epic-potilastietojärjestelmä on Epic Systemsin kehittämä ja Accenture omistaa sen jälleenmyyntioikeudet Suomessa.

Aiemmin HUS oli siis yhden monopolitoimittajan kuristusotteessa, ja tämä hyödynsi sitä laskuttamalla useita miljoonia vuodessa. Jatkossa koko maan sairaanhoitopiirit ovat yhden monopolitoimittajan kuristusotteessa, ja arvioitu kustannustaso on useita satoja miljoonia vuodessa. Siis monopolitoimittajan arvioima kustannustaso.

Tämäkin voisi vielä olla ihan ok. Nykyisestä katastrofista eroon pääseminen maksaa väistämättä paljon rahaa, teki sen miten tahansa. Jos yhtenäisellä ja toimivalla potilastietojärjestelmällä saadaan jatkuva koneiden odottelu ja turhien lomakkeiden täyttely sekä systeemin aiheuttamat hoitovirheet karsittua, on tämänkin potentiaaliset hyödyt jopa satoja miljoonia.

Olisin ihan valmis hyväksymään vaikka kymmenen miljoonan vuotuisen välistävedon, jos sen vastineeksi saataisiin toimiva sairaalajärjestelmä. Mutta miksi ihmeessä saataisiin? Todennäköisempää on, että se toimii suunnilleen yhtä hyvin kuin Uranuskin.

Julkiset kilpailutukset voitetaan sillä, että tarjottava järjestelmä on itsessään halpa. Usein tarjoukset tehdään jopa tappiolla. Tarjoava yritys tekee voittonsa lisä- ja muutostöistä, joiden hinta on kova. Ostaja ei tietenkään halua ostaa kalliita lisätöitä, vaan ostaa niitä ainoastaan jos on pakko.

Eli jos järjestelmä toimii hyvin, jäävät toimittajalta kalliit lisätyöt saamatta, mutta jos se on koko ajan katastrofin partaalla, tili juoksee. En väitä, että kukaan rikkoisi softiaan tahallaan, mutta olemme luoneet järjestelmän, jossa menestyvät lähinnä yhtiöt joiden järjestelmissä on kriittisiä ongelmia. Sitä saa mitä tilaa.

Ratkaisun avain onkin tilata toisin.

Potilastietojärjestelmän kaltainen suuri, monimutkainen ja erittäin kustomoitu tuote luo voimakkaan lock-in efektin. Asiakas on käytännössä täysin riippuvainen lähdekoodin haltijasta, joka voi sanella hintansa ja ehtonsa. Vaihtaminen toiseen järjestelmään vie vuosia ja maksaa kymmeniä miljoonia. Siksi asiakkaan on hallittava lähdekoodia itse.

Toimitusehtoihin on siis lisättävä, että sairaanhoitopiiri saa lähdekoodin hallintansa ja vapaat oikeudet ostaa kehitystyötä järjestelmään keneltä haluaa sekä jakaa tilaamiaan muutoksia muiden sairaanhoitopiirien kanssa. Eli Vaikka Accenture myy Epicin lisenssit HUSille (15% kustannuksista), ylläpito ja muutostyöt (45% kustannuksista) voidaan tilata keneltä vain.

Parhaiten tämä onnistuisi vaatimalla avoimen lähdekoodin lisenssiä, mutta tärkeimmät hyödyt saadaan vaatimalla jatkokehitysoikeus vain itselle. Välttämätöntä on kuitenkin rikkoa yhden toimittajan monopoliasema. Välttämätöntä on katkaista se kuristusnaru, jolla suuret IT-talot sairaanhoitopiirejä hallitsevat.

On mahdollista, että nykyiset tarjoajat eivät halua lähteä tällaiseen kisaan mukaan, mutta viime kädessä järjestelmän voi vaikka tehdä tyhjästä. Jos käytettävissä on viisi vuotta ja miljardi euroa, sillä oikeasti tekee jo aika paljon koodia. Potilastietojärjestelmät ovat monimutkaisia, mutta ei niiden niin monimutkaisia tarvitse olla. Monopolitoimittajan intressissä on aina tehdä järjestelmästä monimutkaisempi; asiakkaan hallitsemassa IT:ssä näin ei olisi pakko olla.

Koodin omistus tai avoimuus ei ole mikään hopealuoti, joka ratkaisee kaikki IT-hankkeiden ongelmat. Vaikka asiakas omistaisi kaiken koodin, hankkeet voidaan silti mokata. Mutta irtautuminen toimittajan liekanarusta on välttämätön edellytys sille, että hankkeet voivat onnistua.

Terveydenhuollon tietojärjestelmäongelmat ovat ratkaistavissa, mutta ne eivät ratkea ilman muutosta toimintatavoissa.

(*) Accenture on ainoa tiedetty Epicin myyjä Suomessa, ja on syytä olettaa, että sopimus antaa heille yksinoikeuden. Varmaa tietoa tästä ei minulla kuitenkaan ole.

11 syytä miksi valtion laitosten kannattaa avata koodinsa

Valtion laitos, potentiaalinen asiakas, on teettämässä uutta tietojärjestelmää. Korvataan kasa vanhoja systeemejä, ja integroidutaan toiseen kasaan. Kehitys tarkoitus tehdä mahdollisimman ketteränä, joidenkin rajapintojen avaamista avoimena datana valmistellaan. Perusarkkitehtuuri on järkevän näköinen ja teknologioiden suhteen tarjoajia pyydetään tekemään ehdotuksia. Kaiken kaikkiaan asiakas vaikuttaisi olevan aika kartalla siitä, miten softaprojektia kannattaa tehdä.

Ajattelin ehdottaa heille, että mitä jos julkaisisitte myös lähdekoodinne avoimena. Alla perusteita, miksi heidän kannattaisi näin tehdä. Lisää saa ehdottaa.

Maanmittauslaitoksen oskari.org-portaali on hyvä esimerkki siitä, kuinka valtion laitos julkaisee kehittämänsä koodin vapaaseen käyttöön

Uuden järjestelmän koodi on kokolailla yhteen tarkoitukseen tehtyä, eikä sille pääosin ole nähtävissä muuta käyttötarkoitusta. Siksi yleinen perustelu kehittäjäyhteisön tekemästä ilmaisesta työstä ei tässä tapauksessa ole soveltuva.

Mutta ne argumentit…

A) Virasto hyötyy itse:

Mahdollisuus siirtää kehitys- ja ylläpitovastuita toimittajalta toiselle paranee. Uusi toimittaja tai toimittajakandidaatti voi perehtyä koodiin jo etukäteen omin nokkinensa, valita tekijät sitä silmällä pitäen ja ylipäänsä harkita, lähteekö tarjouskilpailuun mukaan ollenkaan. Tämä johtanee hiukan parempiin tarjouksiin, ja etenkin uusi tiimi pääsee tuottavaan työhön nopeammin.

Koodin laatu paranee, koska useimmat eivät kehtaa tuottaa julkaistavaksi samanlaista kuraa, jota suljettuun järjestelmään voi piilottaa. Analogisesti, ”on eri asia laulaa suihkussa kuin lavalla”. Tämä helpottaa elinkaarenhallintaa ja laskee ylläpitokuluja etenkin pitkällä tähtäimellä.
Vaikutus toki perustuu laajempaan kulttuuriseen muutokseen, jossa koodaajat vaativat itseltään ja toisiltaan korkeampaa laatua. Koodin avaaminen on ehkä vain tuon muutoksen katalyytti, mutta toimiva sellainen.

Systeemiin liittyviä järjestelmiä tekevien työ helpottuu. Periaatteessahan hyvin dokumentoitu rajapinta riittää, mutta käytännössä asia ei ole näin. Rajapinnoissa on bugeja, ja dokumentaatio on aina epätäydellistä. Rajapinnan käyttäjän työtä tehostaa joskus paljonkin, kun rajapintaan ei tarvitse suhtautua mustana laatikkona, vaan hän voi tarkistaa mitä siellä alla oikeasti tapahtuu ja siten ymmärtää rajapintaa paremmin. Antti kuvaa efektiä hyvin Codenton blogissa.

Koodin avaaminen – kuten datan avaaminenkin – on hyvää PR:ää. IT-mediaa kiinnostavat nämä asiat tällä hetkellä, ja niillä pääsee vaikuttamaan edistykselliseltä ja coolilta. En lähde nyt erittelemään hyvän maineen etuja; mainetta pidetään yleisesti tavoiteltavana asiana.

B) Yhteiskunta kokonaisuudessaan hyötyy:

Avatulle koodille voi löytyä yllättäviä käyttötarkoituksia muualla. Vähintään se voi toimia eri työkalujen käyttöesimerkkinä tai opiskelijoiden harjoitustyömateriaalina. Mahdollisuus merkittävään käyttöön on vähäinen, mutta ennakoimattomia asioita tapahtuu. Tämä tuo myös potentiaalisia PR-hyötyjä jos käyttöä löytyy.

Koodin toimittaja voi hyödyntää kertyneen osaamisen lisäksi myös syntynyttä koodia seuraavassa vastaavassa hankkeessa vaikkapa naapuriviraston puolella. Toimittaja tai seuraava asiakas siis hyötyvät työn tehostumisesta. (sivumennen sanoen: olen yhdessä vanhassa duunissa opensourcannut työkalukoodia jotta sitä voisi käyttää toisillakin asiakkailla).

Koodin avoimuuden yleistyminen tuo uusia bisnesmahdollisuuksia. Esimerkiksi riippumatonta pienimuotoista lähdekoodin ja järjestelmän laadun auditointia. Jos auditointi vaatii raskaat neuvottelut että koodin edes näkee, maksaa se paljon. Avoimen koodin auditointia taas voi tehdä pikkufirma ohimennen ja esim. jättää tarjouksen vasta kun tietävät koodista löytyvän jotain parannettavaa.

C. Muut argumentit:

Julkishallinnon pitää lähtökohtaisesti olla avointa ja julkista ja suljettua/salaista vain jostain pakottavasta syystä. Periaate löytyy jo perustuslain tasolta (hallinnon avoimuus). Itse asiassa avoimessa koodissa on kyse asiakirjajulkisuuden periaatteen loogisesta laajennoksesta.

Myös voimassaoleva hallitusohjelma itse asiassa kehottaa tähän: ”Avoimeen lähdekoodiin perustuvien ratkaisujen käyttöönottoa edistetään julkisen hallinnon kokonaisarkkitehtuurin puitteissa ja kustannushyötyanalyysin pohjalta.” Avaamisesta on jonkin verran hyötyjä, eikä juuri lainkaan kustannuksia, joten sitä kuuluu siis edistää.

Näyttäisi siltä, että julkisissa IT-projekteissa avoin data, ketterä kehitys ja avoin lähdekoodi linkittyvät käytännössä yhteen. Maanmittauslaitos, joka on avoimen datan lippulaiva Suomessa, on myös ketterän kehityksen edelläkävijä ja julkaisee koodinsa avoimena. Sama koskee Sitraa. Yhteys saattaa olla osin satunnainen, ja johtua vain ajan hengestä, mutta sitä ei kannata ohittaa. Kaikki kolme kun linkittyvät uusiin toimintatapoihin ja haluun tehdä julkisista ohjelmistoista hyviä ja kansalaisia palvelevia. Metatarina, jonka menestys voi johtaa todella suuriinkin hyötyihin aivan kaikille.

Lopuksi

Avoimen koodin hyödyt eivät rajoitu vain siihen, että itse koodi on avoimena saatavilla – vaikka siitä on joskus suuriakin hyötyjä toki. Hyötyjä liittyy myös työtapoihin ja ajattelutapaan, jossa avoimuus on lähes itsestäänselvyys. Salasanojen kirjoittamisesta koodin sekaan ei tarvitse edes keskustella, kun koodi on avoimena githubissa. Rajapinnan bugisuus ei ole peruste lyödä hanskoja tiskiin viikoksi, kun voi käydä katsomassa mikä siellä on rikki, ja raportoida virheen täsmällisesti. Ja niin edelleen.

Avoimuus on pienten hyötyjen kasautumista, joka voi levitessään johtaa suuriin ja yllättävinkin muutoksiin. Ja on syytä huomata, että avoimuutta vastaan ei julkishallinnossa puhu oikeastaan mikään: siksi pienetkin hyödyt riittävät perusteeksi.

Joka tietoa lisää

VR otti käyttöön uuden lipunmyyntijärjestelmänsä vaiheittain keskiviikon 14.9. ja perjantain 16.9. välillä. Nettikauppa lakkasi toimimasta heti keskiviikkona, eikä ole alkanut toimia kunnolla tähän mennessä. Sunnuntaina oli pieniä häiriöitä muussakin lipunmyynnissä. Lippuautomaatit tippuivat pelistä maanantaina, ja pian niiden perässä myös asemien lipunmyynti.

VR on tietysti tullut viime aikoina tunnetuksi kyvyttömyydestään liikennöidä junia, joten sikäli tämä ei yllättänyt ketään. Tällä kertaa syypää ei kuitenkaan ole yksin junayhtiö, joka ei saa junia liikkeelle, vaan myös ohjelmistoyhtiöt, jotka eivät saa ohjelmistoja toimimaan: parivaljakko Tieto ja Accenture.

Ongelmana on näet VR:n uusi tietojärjestelmä. Verkkokauppa, asemajärjestelmä ja automaatit käyttävät samaa taustajärjestelmää. Ja taustajärjestelmää ei ilmeisesti oltu tehty kestämään tätä käyttöä. Uudet lipputyypit ja integroinnit lisäsivät kuormaa: ”Emme osanneet ennakoida tällaista. Meillä oli 20-kertainen kysyntäpiikki normaaliin verrattuna” kommentoi hankkeen vastaava. Alalla toimivat lukijat ymmärtävät varmasti, että uudistukset aiheuttavat piikkejä, ja niiden suuruutta on mahdollista arvioida. On aivan normaali käytäntö varautua merkittäviin kysyntäpiikkeihin järjestelmäuudistuksissa, varsinkin jos käyttömalli muuttuu, kuten tässä tapahtui.

Tämä ei ole mitenkään ainutkertaista. Etenkin Tieto on surullisen kuuluisa suurista ohjelmistohankkeista, jotka menevät täysin penkin alle. On kyse sitten eduskunnan äänestysjärjestelmästä, Oulun päiväkotijärjestelmästä, yhteishausta tai ajoneuvorekisteristä.

Eikä tässä nyt ole kyse vain Tiedosta. Samanlaisia kauhutarinoita löytää muidenkin suurten IT-talojen toimittamista projekteista. Taas eilen kuului paljon ideoita, kuinka voitaisiin säätää laki, ettei niiltä saa ostaa mitään, koskaan, ikinä. Vaikka tulisi EU:lta sakot. Tai ehkä moista tuhoa tekevät organisaatiot voisi kieltää EU:n terroristijärjestösäädösten perusteella?

Eiväthän tälläiset fantastiset ehdotukset tietenkään ratkaisisi ongelmaa, vaikka olisivat mahdollisiakin, mitä ne eivät ole. Jos maan kymmenen suurinta IT-toimittajaa lakkaisivat tänään olemasta, olisi meillä muutamassa vuodessa tilalla uudet aivan samanlaiset. Ongelma ei ole yksittäisen yrittyksen huonous tai pahuus, se on syvemmällä.

Asian ydin on tässä Ari Järvelän (Tieto) lausumassa ”VR:n tietojärjestelmä on arkkitehtuuriltaan hyvin monimutkainen järjestelmäkokonaisuus.”

Lippujärjestelmä ei toki ole mikään javakurssin harjoitustyö. Siinä on useammanlaisia lippuja, useita eri tapoja ostaa niitä, ja junavuorojakin on 1200 joka päivä. Junamatkoja tehdään 44 miljoonaa vuodessa, eli ehkä 150 000 arkipäivänä. Ei tätä koodaa iltapäivässä.

Vertailun vuoksi: yksi yhteistyökumppani rakensi lippuvarausjärjestelmän, jolla voi ostaa kaikki maailmassa myytävät elokuvaliput, 230 miljoonaa lippua kuussa. Ihan vaan demotakseen fancy-fancy-bling-bling-ui-systeemiään. Kai sitä joku viikon pari koodasi, satakertaista kapasiteettia. Toki paljon yksinkertaisempaa ratkaisua, ei yhtä monimutkaista kuin VR:llä.

Mutta juuri siitähän tässä on kyse: yksinkertaisista ratkaisuista. Ei VR:n lipunmyynnin olisi mikään pakko olla arkkitehtuuriltaan hyvin monimutkainen. Näin alan ammattilaisena voin sanoa, että jos haluaa toimivaa, systeemistä kannattaa sen sijaan tehdä melko yksinkertainen, ja hyväksyä monimutkaisuutta vain se minimimäärä, joka on ihan pakko. Ei tässä olla mitään ydinvoimalaa tekemässä, vaan ihan tavallista lipunmyyntijärjestelmää.

Yksinkertaisemmat arkkitehtuurit, joissa voidaan asioita muuttaa pala kerrallaan, ratkaisisivat monta ongelmaa. Itse asiassa juuri siihen VR:nkin uudistuksessakin pyrittiin. 15 miljoonaa euroa ja yksi katastrofaalinen käyttöönotto myöhemmin voidaan todeta, että jokin meni vikaan. Se jokin ei ole tekniikkaa. Jokaisen teknisen ongelman takana on aina organisatorinen ongelma, josta johtuu, ettei teknistä ongelmaa ole ratkaistu.

Eli miksi VR:n lipunmyyntijärjestelmä on arkkitehtuuriltaan hyvin monimutkainen? Miksi sen koodaaminen on jättiläishanke, johon tarvitaan toista sataa työntekijää? Miksei sitä tehty pienempänä, helpommin ja pala kerrallaan?

Vastauksia on tietenkin monenlaisia, ja jokaisella virheellä on ainutkertainen historiansa. Tälläisessä löysäranteisessa tarkastelussa riittänee todeta: on sekä myyjän että ostajan intressissä, että hanke on suuri ja monimutkainen.

Ohjelmistohankkeet tehdään monessa vaiheessa alkaen alustavasta määrittelystä, määrittelyn ja erilaisten suunnittelujen kautta toteutukseen. Samat IT-talot tekevät kaikkia vaiheita, ja kilpailevat sitten itse määrittelemiensä järjestelmien toteutusprojekteista.

Jos ohjelmistohankkeeseen tarvitaan 200 henkeä, Suomesta löytyy noin kaksi IT-taloa, jotka voivat sen toimittaa. Aivan, Tieto ja Accenture. Sata henkeä saisi penkkiä lämmittämään jo muutama muukin yritys, ja 20 vaikka kuinka moni. Suuren IT-talon konsultin kannattaa tietenkin määritellä järjestelmä, jonka lähinnä oma talo voi toteuttaa.

Ostajan kannalta – ja puhun nyt ihmisestä, en organisaatiosta – suuri hanke on tietenkin suurempi. Ajatelkaa katumaastureita, kyllä sillä koolla on väliä. Ja jos hankkeita pilkkoo, joutuu koordinoimaan eri projekteja, kun ”kokonaistoimituksen” ongelmia voi aina turvallisesti olla havaitsematta. Sitäpaitsi vakiotoimittajalt ostaminen on turvallista. Kukaan ei ole saanut potkuja siksi, että osti Tiedolta. Jos pikkufirma mokaa, vika on ostajan joka luotti siihen, mutta jotunnettu toimittaja mokaa, niin eihän se voi olla ostajan vika.

Hyvän ja pahan tiedon puu

Taisin lupailla jotain ratkaisujakin. Otsikko on vihje: lisää tietoa.

Nimittäin avointa tietoa. Kaikki julkisten tahojen tilaamat ohjelmat pitäisi julkaista avoimen koodin lisenssillä. Avaaminen helpottaisi pienempien yritysten mahdollisuutta osallistua tarjouskilpailuihin, kun omien rahkeiden riittävyyttä voisi tutkia etukäteen. Avaaminen helpottaisi järjestelmien integraatiota, kun rikkinäisen rajapinnan voisi korjata tai ainakin ymmärtää sen toimintaa. Ja avaaminen poistaisi vendor-lock-inneistä suurimman osan.

Kaiken julkisen koodin avaaminen toisi vähitelleen kustannussäästöjä, kun asioita ei tarvitsisi tehdä uudestaan niin monta kertaa, ja kun yritykset uskaltaisivat tarjota projekteja halvemmalla. Vielä merkittävämpi potentiaalinen hyöty tulisi epäsuorasti, jos ja kun ohjelmien laatu alkaisi pikkuhiljaa parantua.

Ja kun yksikään julkinen taho ei tee ohjelmistobisnestä, eivät oikein tehdyt ohjelmat voi sisältää liikesalaisuuksia tai mitään niihin verratavaa salattavaa tietoa. Merkittäviä haittoja ei siis ole.

Monimutkaisuuden ongelmaa avoimuus ei suoraan ratkaisisi. Mutta se olisi osa kulttuurista muutosta kohti parempia ohjelmistoja, pois tästä murheen laaksosta, jossa tavoite on vain saada paljon perseitä tuoleja lämmittämään, ei mitään valmista.

Itse asiassa koodin avaaminenhan on vain virallisten dokumenttien julkisuuden looginen laajennos. Ei mitään radikaalia, ei mitään vallankumouksellista. Paitsi että avaaminen parantaisi radikaalisti julkisia ohjelmistohankintoja. Parhaat ratkaisut ovat yksinkertaisia.

Kirjoittaja on töissä yrityksessä, joka hyötyisi merkittävästi, jos Tiedolta ja Accenturelta ostettaisiin vähemmän softahankkeita sekä kansalainen valtiossa, joka hyötyisi merkittävästi, jos Tiedolta ja Accenturelta ostettaisiin vähemmän softahankkeita.

Avoin koodi julkisissa hankinnoissa

Kirjoitin oheisen tekstin Voiman avoin koodi-liitteeseen (Voima 6/2010, Heinä-elokuu). Samaisessa liitteessä tekstejä mm. Tomi Toiviolta (joka kasasi jutut ja kirjoitti suurimman osan nimettömistä artikkeleista, kaikki kunnia hänelle), Mjr:ltä, Kemppiseltä ja ties keneltä. Kemppisen teksti on tajunnanvirtaa ohi aiheen, mutta kannattaa lukea, jos saa liitteen käsiinsä.

Oma tekeleeni tuntuu nyt suoraan sanottuna hiukan raskaalta ja kömpelöltä. Jotenkin julkaiseminen paperilla "pakotti" tylsän viralliseen asiatekstilajiin ilman itseironiaa ja vihjailua, ja yleisön aliarviointi sitten taas kömpelöön ilmaisuun. No, onneksi liitteen taitto ja painojälki oli sen verran huonoa, ettei tekstiä siitä jaksa kukaan lukea.

Aiempia kirjoituksiani aiheesta tämän linkin takana

------------------------------------------

Avoin koodi julkisissa hankinnoissa

Avoimen koodin käytöstä julkisella sektorilla on puhuttu jo pitkään. Yleensä ajatellaan vain olemassa olevien ohjelmien, kuten Linuxin ja OpenOfficen käyttöä kouluissa ja virastoissa. Avoimen koodin lisenssit voivat kuitenkin hyödyttää julkista sektoria toisellakin tavalla, julkiselle tahoille kehitetyissä ja räätälöidyissä järjestelmissä.

Ohjelmistojen ostaminen on ammattilaisillekin vaikeaa. Vaatimukset ovat monimutkaisia, eivätkä yleensä täysin tunnettuja, vaihtoehdot eivät ole vertailukelpoisia ja laatu parhaimmillaankin vaihtelevaa. Julkisiin ostoihin tuo lisävaikeutensa hankintalain tiukat säädökset
kilpailutuksesta ja ostoprosessista. Ei ole mikään ihme, että IT-hankintojen ongelmia puidaan säännöllisesti eduskuntaa myöten. Tunnetuimpia ovat terveydenhuoltoalan järjestelmäongelmat, mutta samoja ongelmia esiintyy kaikkialla muuallakin. Seurauksena julkiset tietojärjestelmät ovat yleensä raskaita ylläpitää ja muokata, sekä vaikeita käyttää. Avoin koodi voi auttaa tässä kolmella tavalla.

Ensimmäinen ongelma: Alkuperäisen järjestelmän tehnyt yritys omistaa siihen oikeuksia, tai ainakin ei-julkista tietotaitoa. ohjelmiston toimittajan vaihtaminen on todella kallista, ja monopolimyyjän hinnoittelu sen mukaista. Näin ollen järjestelmän parannukset ja varsinkin yhteensopivuusmuutokset jäävät usein tekemättä.

Ratkaisu: Jos tietojärjestelmien koodi olisi avointa, kuka tahansa voisi tehdä integrointityön, eikä riippuvuutta pääsisi syntymään. Osa avoimuuden hyödystä saadaan jo sillä, että koodi on ostajan vapaasti käytettävissä. Ostajalla ei kuitenkaan usein ole omaa osaamista koodin tutkimiseen, jolloin täysi avoimuus on hyödyllisempää.

Toinen ongelma: Vanhoihin järjestelmiin on yleensä raskasta integroida uusia osia, koska niitä ei ole suunniteltu sitä varten, eikä integroijilla ole usein pääsyä muuttamaan vanhaa järjestelmää yhteensopivammaksi.

Ratkaisu: Jos järjestelmien koodi olisi vapaata, integrointityö voitaisiin kohdistaa sinne, missä se on tarkoituksenmukaisinta tehdä. Myös vaihtoehtojen tutkiminen ja ratkaisujen testaaminen olisi oleellisesti helpompaa.

Kolmas ongelma: Julkisten ohjelmistohankintojen prosessit ovat yleensä raskaita, ja niihin osallistuminen on pienille yrityksille erittäin vaikeaa. Yksi syy tähän on, että hankeet kytkeytyvät yleensä vanhoihin järjestelmiin, ja tämän integraation vaatimaa työmäärää on erittäin
vaikea arvioida.

Ratkaisu: Jos hankkeeseen liittyvien järjestelmien lähdekoodi olisi tarjoajien saatavilla, pienemmätkin yritykset voisivat arvioida, onko niillä realistisia mahdollisuuksia suoriutua hankkeesta esimerkiksi kymmenesosalla perinteisen tarjoajan kustannuksista.

Lisäksi avoimuudesta syntyisi vahva verkostovaikutus. Jos vaikka Tampereen yliopistollinen sairaala on hankkinut hyvän potilastietojärjestelmän, miksei Helsingin yliopistollinen sairaala
saisi ottaa sitä käyttöön myös? Miksi heidän pitäisi tuottaa omansa? Tai jos HYKS haluaa tehdä omansa, ainakin TAYSiltä voisi omaksua rajapinnat ja soveltuvat osat. Yhden kunnan tai sairaanhoitopiirin säästö ei ole toiselta pois, päin vastoin.

Tulisi siis säätää laki, jonka mukaan kaikki julkisille tahoille tehtävät uudet ohjelmistot tulee julkaista avoimen lähdekoodin lisenssillä, esimerkiksi Creative Commons cc-by-sa:lla. Ratkaisu pitää tehdä lailla, koska hankintaprosesseja yleensä konsultteina valmistelevat suuret IT-talot tuskin ovat kiinnostuneita sahaamaan omaa oksaansa. Eivätkä yksittäiset ostajatkaan välttämättä ymmärrä, miksi avoimuus hyödyttä heitä, vaikka ensimmäisen oston hinta nousisikin.

Yhteiskunnan kannalta julkisen sektorin koodin avoimuudella on useita etuja, eikä juurikaan haittoja. Moraaliselta kannalta voidaan myös kysyä, miksi meidän kaikkien verovaroilla ostettu ohjelmisto ei olisi meidän kaikkien vapaassa käytössä?

Hihittävät nörtit

Kauppalehti tietää kertoa, että ”Eduskunta pui it-pulmia: nörtit hihittävät ja käärivät rahat” ja että Keskustapuolueen edustaja Vilkunan mukaan tietotekniikan ammattilaiset hihittävät keskuudessaan yhteiskunnan antamalle mahdollisuudelle rahastaa törkeällä tavalla täysin laillisesti.

Siltä varalta, että joku ei sitä tiedä, kerrottakoon, että ei se mene noin.

Suurin osa nörteistä, joiden kanssa olen ikinä aiheesta puhunut, on ollut lähinnä vihaisia tai ärtyneitä tavasta(*), jolla julkisen puolen IT-hankkeita hoidetaan. Loput ovat olleet ahdistuneita. Osa siksi, että on itse ollut niissä joskus mukana.

Nörtit eivät myöskään niitä hukattuja rahoja näe. He saavat vain palkkansa, joka toki on suurempi kuin pitsakuskilla, mutta yleensä matalampi kuin raksamiehellä. Suurten IT-toimittajien omistajat saavat tuottoa osakkeilleen, mutta suurin osa rahasta hukkuu yksinkertaisesti turhaan ja tehottomaan työhön, ei siihen että joku vetäisi välistä.

Puhtaasti alaa tuntevan sivusta seuraajan näppituntumalla, suurimmat syyt julkisen puolen IT-ongelmiin ovat:

Ongelmat ostamisessa. Osa ongelmista johtuu direktiiveistä ja hankintalaista, mutta lähinnä kyse on osaamisen puutteesta. Projektien ja järjestelmien ostaminen on aidosti vaikeaa, varsinkin kun siihen liittyy sekavia säädöksiä ja raskas organisaatio, jossa on paljon intressitahoja. Kun ostoja tekeviä instansseja on sadoittain, ja jokainen ostaa isoja järjestelmiä harvoin, on selvää, että useimpiin niistä ei mitenkään voi kertyä riittävää osaamista.

Joukko palveluntarjoajia on oppinut hyödyntämään tätä osaamattomuutta ja säädösten kiemuraisuutta. Ei nyt mennä nimiin, mutta niitä on sekä isoja että pieniä. Alalla on kuvionsa, miten myyjä vedättää prosessia: vendor lock-in on niistä vain yksi, tosin ehkä merkittävin.
Vedättämisen tekee myyjä, ei nörtti. Se kuuluu myyjän ammattitaitoon, eikä liity IT-alaan sinänsä mitenkään. Osataan sitä muillakin aloilla.

Vilkuna toteaa myös aivan oikein, että syy on systeemissä. Siksi vika pitää myös korjata systeemissä. Firmojen syyllistäminen ei niiden toimintaa lopeta, eikä ostajien syyllistäminen opeta kenellekään ostamista. Yhtä mahdollista ratkaisua pohdin aiemmin.

Korruptiota ja varsinkin puolittaista korruptiota (à la maan tapa) varmasti on, mutta en usko, että se on prosentuaalisesti mitenkään kauhean merkittävä tekijä tässä.

(*) Toki on olemassa hyvin hoidettuja julkisen puolen IT-hankkeita. Tämä kirjoitus ei käsittele niitä, vaan sitä suurta enemmistöä, joka ei ole hyvin hoidettu.

Avoin hankinta on avointa koodia

Olin tiistaina taas eduskunnassa, ja Jyrki Kasvi puhui taas. Tällä kertaa kyseessä oli Tieken aamiaistilaisuus ”avoin ja ketterä julkinen hankinta”. Jyrki käsitteli joustavien ja tuottavuutta oikeasti parantavien tietojärjestelmähankkeiden hankaluudesta ja mistä se johtuu. Hänen pääajatuksensa olivat, että pitää miettiä kunnolla etukäteen mitä oikeastaan halutaan, ja lähteä prosessimuutoksista eikä it-järjestelmästä. Keskustelussa myös korostettiin ketterämpää menttelyä, että etukäteen ei voi tietää mitä täsmälleen tarvitsee, ja hankkeet pitää märitellä niin, että korjauksia voidaan tehdä projektin aikana.

Hyviä huomioita, mutta eivät riittäviä parantamaan julkisten it-hankkeiden karmeaa tilaa. On kuitenkin olemassa yksinkertainen (osa)ratkaisu, joka sysäisi liikkeelle kehityksen oikeaan suuntaan. Sitä ei tuotu esiin, enkä itsekään sitä iljennyt sanoa – idea on ehkä hieman liian poliittinen työnantajan nimissä sanottavaksi.

Sanon sen tässä: kaikki julkisten tahojen ostamat ohjelmistot pitäisi lailla pakottaa avoimiksi. Esimerkiksi cc-by-sa-lisenssillä.

Tällä ratkaistaisiin kaksi keskeistä julkisten hankintojen ongelmaa:

Vanhoihin järjestelmiin integroituminen on yleensä raskasta, jopa mahdotonta, koska vanhojen järjestelmien rajapinnat ovat riittämättömiä. Jos vanha järjestemä on avoimesti muokattavissa, sinne voidaan lisätä tarvittavat rajapinnat. Ratkaisu ”tehdään jatkossa riittävät rajapinnat” ei tuo samaa, koska tulevia tarpeita on mahdoton tietää nyt, ja niiden arvailu tulee kalliiksi.
Hankkeissa syntyy yleensä vahva vendor lock in: kun alkuoperäisen hankkeen tekee vaikkapa Tieto, jonka omaisuutta koodi on, ei muutoksia ja jatkotarpeita voi oikeastaan ostaa muualta. Monien IT-talojen ydinosaamista on tämän lock innin rahastaminen siten, että kilpailutukseen tarjotaan ohjelmisto tappiolla, ja voitot rahastetaan sitten muutoksilla.

Lisäksi avoimuudesta syntyisi vahva verkostovaikutus. Jos vaikka PSHT on hankkinut hyvän potilastietojärjestelmän, miksei HUS saisi ottaa sitä käyttöön myös? Miksi heidän pitäisi tuotaa omansa? Tai jos HUS haluaa tehdä omansa, ainakin PSHTltä voisi omaksua rajapinnat ja soveltuvat osat.

Ratkaisu on pakko tehdä lailla, koska muutoin oligopolimaisessa asemassa olevat isot IT-talot voivat kustannusnostoilla pelotella suuren osan ostajista olemaan vaatimatta avoimuutta. Ja ostajat eivät välttämättä ymmärrä, miksi avoimuus hyödyttä heitä, vaikka ensimmäisen oston hinta nousisikin.

Demarisoituna mallina tuosta voisi olla, että kaikki ohjelmakoodi on kaikkien julkisen puolen toimijoiden vapaassa käytössä, ja sitä voidaan luovuttaa alihankkijoille julkisia hankkeita varten (mutta ei muuhun käyttöön). Tällä saataisiin varmasti kohtuullinen osa avoimuuden hyödyistä, eikä se olisi ihan niin pelottavan kuuloista 70-luvun kommunistikammoonsa juuttuneille.

Moraaliselta kannalta voidaa myös kysyä, miksi meidän kaikkien verovaroilla ostettu ohjelmisto ei olisi meidän kaikkien vapaassa käytössä?

Kysyin tuosta ideasta kommenttia Kasvilta tilaisuudne jälkeen, ja kuulema ei riittäisi muuttaa hankintalakia, vaan myös kilpailulainsäädäntöä pitäisi rukata (en tosin aivan tajunnut miksi). Kuulema ongelmana on edes mahdollistaa avoimena koodina tilaamine suljetun rinnalla, saati että sitä suosittaisiin.

Idea ei ole alkujaan omani, vaan jatkojalostin sen Mikon kirjoituksen pohjalta