Hyvää jatkoa, toivottaa renki

Hyvä renki -blogin toiminta on päättynyt. Kiitokset kaikille osallistuneille.

Toiminta paremman tietoyhteiskunnan infrastruktuurin puolesta ei sen sijaan ole loppunut. Päin vastoin, näiden kahden vuoden aikana moni julkinen hanke on ottanut parempaa suuntaa ja julkinen keskustelu asiasta on ainakin lisääntynyt selvästi. Pikemminkin on niin, että tämä blogi yksittäisenä kanavana on jäänyt yleisen muutoksen jalkoihin ja turhaksi. Ja on myös niin, ettei tänne ole tullut kirjoitettua niin paljon kuin oli suunnitelmana.

Siksi siis hyvää joulua, hyvää jatkoa ja tavataan taas.

toivottaa,
Hyvä renki

ps. saman aihepiirin keskustelua löytyy ainakin

• Codenton blogista
• Otson blogista

Kuinka kansallinen palveluväylä tulisi tehdä

Kansallinen palveluväylä on ehkä merkittävin IT-projekti tällä hetkellä Suomessa, Apottiakin tärkeämpi. Se on luonteeltaan ristiriitainen: toisaalta siinä pyritään uudistamaan koko se tapa, jolla julkisia tietojärjestelmiä Suomessa tehdään. Toisaalta siinä saatetaan vain kaataa 120 miljoonaa sille jolla on syvimmät taskut. Ratkaisut hankkeen ja ehkä koko suomalaisen IT-palvelualan suunnasta tehdään lähikuukausina.

Kun olen seuraillut projektia vuoden verran melko läheltä, koen että minun täytyy kertoa mistä siinä nähdäkseni on kyse, ja mitä sille pitäisi tehdä.

Optimistin tarina

Tekniikkana palveluväylä on itse asiassa suhteellisen yksinkertaista: sovittu toimintatapa ja sovitut rajapinnat siihen, miten toisiin järjestelmiin otetaan yhteyttä. Yhteinen tapa tunnistaa käyttäjät ja tapa selvittää järjestelmien osoitteet. Useimmilla isoilla yrityksillä on jonkinlainen palveluväylä, mutta se on vain osalla pakollista perusinfraa, vähän kuin serverihallit tai nettikaapelointi. Se ei sinänsä ole mitään kauhean ihmeellistä, vaikka toki tarpeellista.

Kansallinen palveluväylä ei ratkaise järjestelmien yhteentoimintaa eikä sinänsä tuo kovin dramaattisia säästöjä. Suurin osa palveluväylään kohdistetuista odotuksista onkin täysin ylimitoitettuja, jos ajatellaan pelkkää väylää.

Mutta kyse on enemmästä kuin vain tietojärjestelmästä. Palveluväylähankkeen – tai kansallinen palveluarkkitehtuurin, kuten sitä nyttemmin kutsutaan – tavoitteena on mullistaa tapa, jolla suomalaisia tietojärjestelmiä tehdään. Hallituksen rakennepoliittisessa ohjelmassa marraskuussa kirjattiin:

”Toteutetaan viipymättä kansallinen sähköinen palveluväylä ja sähköinen tunnistautuminen kustannustehokkaasti sekä Viron yhteistyömahdollisuudet täysimääräisesti hyödyntäen.”

Kremlologian parhaiden perinteiden mukaisesti ”viipymättä” ja ”kustannustehokkaasti” tarkoittavat tässä, että hanke tehdään ketterästi eikä perinteisenä julkishallinnon mammuttiprojektina. ”Viron yhteistyömahdollisuudet täysimääräisesti hyödyntäen” taas tarkoittaa avointa lähdekoodia. Voisihan sen sanoa paljon selvemminkin, mutta ei ole ollut tapana.

Rakennepaketin perustelumuistiossa (s. 71) asiaa selitetään lisää.

”Palveluväylä mahdollistaa tiedon välityksen organisaatioiden välillä yhdenmukaisesti sovituilla tavoilla (yhtenäiset tiedon kuvaukset, rajapintakuvaukset ja standardit) perustuen avoimiin rajapintoihin ja keskeisten osien osalta avoimeen lähdekoodiin. […]

Yhteentoimivuuden lisäksi Palveluarkkitehtuuri luo aiempaa paremmat liiketoimintaedellytykset yrityksille ja erityisesti PK-sektorille, sillä uusi toimintamalli ja avoimet rajapinnat parantavat niiden edellytyksiä osallistua julkisiin ICT-hankintoihin sekä mahdollisuuksia luoda uusia innovatiivisia palveluja julkista tietoa hyödyntäen.”

Tarkoitus on siis toteuttaa suuri julkinen softahanke kevyesti ja nopeasti ja siirtyä integraatioissa käytäntöön, jossa ne tehdään helposti ja toimivat sen sijaan, että niitä jarrutellaan ja rahastetaan niiden avulla toimittajaloukkua. Samalla avataan kaikki mahdollinen data ja rajapinnat ja siirrytään malliin, jossa strategiset julkiset tietojärjestelmät ovat avointa koodia, jotta niitä voidaan hyödyntää tehokkaammin.

Ja tämä toimivien tietojärjestelmien kulttuuri on tietenkin tarkoitus laajentaa koskemaan julkista sektoria yleisestikin – kuten on tehty Virossa. Rakennepaketissa ennakoidaan tästä saatavan kansantalouden tasolla puolen miljardin vuotuiset hyödyt. Siis 500 000 000 euroa joka vuosi.

Tässä vaiheessa varmaan ymmärrätte, miksi olen innoissani hankkeesta. Tässä yritetään tehdä monia niistä asioista, joista olen puhunut viime vuosina. Toisaalta tämä ei ole ainoa totuus hankkeesta, sillä on myös synkempi puoli.

Viron palveluarkkitehtuurin yleisarkkitehtuuri. Keskellä on väylä (X-Road), joka yhdistää tietojärjestelmiä. Tämän tarkkuuden kaaviosta ei tietenkään näe, mitä oikeasti tehdään.

Pessimistin tarina

Taloussanomat kertoi tammikuussa, kuinka palveluarkkitehtuurihanke on ”120 miljoonan euron ontto kuori” ja rahojen käytölle ei ole olemassa suunnitelmaa. IT-hankkeiden tunnettu kriitikko, Professori Tomi Voutilainen taas epäilee, että siitä on tulossa teknologiavetoinen uudistus, jossa unohdetaan loppukäyttäjien tarpeet. Valitun teknologiankin järkevyyttä kyseenalaistetaan, eikä luvattujen puolen miljardin hyötyjen toteutumisesta ole vielä mitään näyttöä.

Vastaavia tietojärjestelmien yhteentoimivuuteen tähtääviä hankkeitahan on tehty Suomessa ennenkin, ks esim. Julkishallinnon perustietovarantojen rajapinnat (PERA)  tai Valtion yhteinen integraatiopalvelu (VIA). Molemmissa on varmasti tehty paljon sinänsä tarpeellista työtä, mutta kumpikaan ei ole ratkaissut yhteentoimivuuden ongelmia, vaan integraatio on edelleen ihan yhtä jähmeää.

Epäilyksille on siis perusteita. Isoissa julkisissa IT-hankkeissa yleensä päädytään tekemään raskas mammutti, myöhässä ja yli budjetin, tuottaen samalla toimittajaloukku, joka hidastaa kehitystä ja maksaa jatkossakin. Pitäisi olla vahvat perustelut, miksi tällä kertaa kävisi eri tavalla.

Koodin avoimuus hankkeessa on myös hiukan epäselvää. Sitran Mirjami Laitinen sanoi Sitran Real Time Economy-seminaarissa että palveluväylä ei ole avointa koodia, eikä jaettavissa muille. Että se on väärinkäsitys. Sittemmin tosin olen kuullut, että Laitisen esittämä käsitys olisi väärinkäsitys.

Internet-huhun mukaan koodi olisi avointa vain osittain, eikä kaikkea lähdekoodia saataisi. Vahvistusta ei ole, mutta näiden huhujen uskottavuutta lisää se, että Suomen ja Viron välisessä sopimuksessa ei mainita avoimuudesta tai ylipäänsä lähdekoodista mitään.

Kaiken tämän kruunaa, että hankkeessa on nyt onnistuttu käyttämään ensimmäinen vuosi saamatta aikaan paljoakaan. On toki kirjoitettu kokonaisarkkitehtuuri ja pidetty seminaareja. Kumpikaan ei varsinainen ketterän hankkeen avauspaukku. Kehitysympäristökin on tiettävästi pystytetty, mutta kenellekään ei anneta pääsyä siihen.

Palveluväylä näyttääkin tällä hetkellä avoimen koodin hankkeelta, jonka koodiin ei pääse käsiksi; ketterältä hankkeelta, jossa tehdään kaikkea paitsi koodataan ja kehittäjäyhteisönrakentamishankkeelta, jossa kehitysympäristöihin ei pääse kukaan käsiksi. Ja 120 miljoonaa olisi tarkoitus käyttää toistaiseksi tuntemattomaan kohteeseen.

Kumpi kuvaus tilanteesta sitten on totta? Molemmat, ja vain aika näyttää, kumpi perii voiton.

Todellisuudella on vielä tällä hetkellä edellytykset kummankin toteutumiselle. Palveluväylästä voi tulla se käännekohta, jossa jälkikäteen huomataan julkiset IT-hankkeiden kurssin kääntyneen kohti toimivaa ja järjellistä. Tai siitä voi tulla yksi pahimpia esimerkkejä siitä, miten IT:n varjolla vedetään rahat yksityiseen taskuun saamatta mitään toimivaa aikaiseksi. Lähikuukaudet ratkaisevat, kummasta tarinasta tulee totuus.

Tässä siis hahmotelma, mitä nähdäkseni pitää tehdä, jotta optimistin tarina voittaa.

Suuntaviivoja hankkeelle

Hankkeelle tarvitaan täsmälliset tavoitteet. Abstrakteista visioista pitää päästä yksi askel alaspäin konkreettisesti mitattavalle tasolle. Tällaisia täsmällisiä suuria tavoitteita näen hankkeella kolme:

1. Jokainen tieto on yhdessä ja vain yhdessä paikassa (master data). Muut tiedon tarvitsijat hakevat sen tästä tunnetusta paikasta, mahdollisesti käyttäen välikopioita, mutta säilyttämättä koskaan omaa rekisteriä.
2. Kansalaisille tarjotaan mahdollisuus nähdä omat tietonsa ja tarkistaa kuka niitä on katsellut. Tämä toteutetaan kaikelle väylään kytkettävälle tiedolle.
3. Projektissa ei luoda uusia toimittajaloukkuja. Olemassa olevat toimittajaloukut tunnistetaan ja joko rajataan vaikutuksiltaan tai puretaan.

Ensimmäinen tavoite on se mitä julkishallinto saa: selkeämmän ja toimivamman arkkitehtuurin kaikelle tiedolle ja siten toiminnalleen. Ministerienkin visioiman reaaliaikaisen verotuksen tai kuntien tuottavuusharppauksen.

Toinen tavoite on se mitä kansalaiset saavat: vahvemman hallinnan omaan dataansa, ensimmäisen askeleen kohti digitaalista kansalaisuutta eikä vain kuluttajuutta.

Kolmas tavoite taas on se mitä alan yritykset saavat: uudenlaisen lähtökohdan siihen, miten tietojärjestelmiä ostetaan, askeleita kohti toimivaa ja tehokasta markkinataloutta.

Nämä tavoitteet on oikeastaan kirjattu muodossa tai toisessa hankkeen asiakirjoihin, tiivistin ne vaan konkreettisemmiksi. Nämä tavoitteet on syytä pitää kirkkaana mielessä kaikessa toiminnassa, sillä kaiken toiminnan tulee niitä edistää. Eikä ole poissuljettua, että tavoitteita voisi olla muutama lisääkin, nämä olivat vain ne mitä minä näen.

Konkreettisesti projekti on syytä rakentaa mahdollisimman ketteräksi ja avoimeksi.

Ketteryys tarkoittaa tässä etenkin nopeita konkreettisia käyttöönottoja ja pieniä osaprojekteja. Ei vuoden mittaista suunnitteluhanketta, vaan pieniä kokeiluhankkeita, ja niiden pohjalta seuraavia pienehköjä hankkeita.

Avoimuus taas tarkoittaa mukaan ottamista. Palveluväylään on tarkoitus integroida aluksi kymmeniä, sitten satoja tietojärjestelmiä ja myös sitä käyttäviä järjestelmiä on potentiaalisesti vähintään satoja. Kaiken tämän tekeminen keskusjohdetusti ja erilaisilla kahdenvälisillä sopimuksilla veisi vuoskymmenen. Siksi pitää tehdä kaikki mahdollinen, jotta kukin virasto, kunta tai yritys voi toteuttaa omia integraatioitaan mahdollisimman itsenäisesti ja helposti.

Sitä varten tarvitaan avoimet testi- ja kehitysjärjestelmät, joilla integraatioita voi kokeilla, vapaasti käytettäviä esimerkkikoodeja, ohjeita, jne. Vielä enemmän tarvitaan väylä käyttävien ja kehittävien ihmisten yhteydenpitoa.

Palveluväylän kehittämiselle ja käytön tueksi pitää rakentaa avoimia keskustelun ja yhteistyön alustoja. Siis esimerkiksi ottaa käyttöön Github, pitää säännöllisiä avoimia seminaareja, tehdä metadatan standardointi avoimesti ja julkisesti, kutsuen kaikki kiinnostuneet mukaan jne. Petri Aukia luonnostelee joitakin hyviä käytäntöjä blogauksessaan.

Kaikki palveluväylän koodi ja mahdollisimman suuri osa integrointikoodista on syytä julkaista netissä avoimella lähdekoodilla. Ei niinkään mistään periaatteellisesta syystä, vaan koska se helpottaa uusien tahojen mukaantuloa ja nopeuttaa uusia integrointeja, kun jo tehdystä työstä voi oppia. Ei ole ollut kerta eikä kaksi, kun avoimen koodin bugi on korjattu sitä käsittelevän palaverin aikana, tai sen myöhästyessä. Avoimuus myös estää palveluväylä-integraatiota muodostumasta taas uudeksi toimittajaloukuksi.

Ja koska rahaa on jonkin verran käytettävissä, projekti voi kannustaa sillä virastoja mukaan toimintaan – ja toimintatapoihin.

Yhteistyösopimus, joka Suomessa salattiin ja Virossa laitettiin nettiin.
Tässä toimintatapojen maahantuonnissa on vielä vähän työtä tehtävänä.

Yllä kuvaamani tavoitteet ja toimintatavat tarkoittavat vallankumousta siinä, miten tietojärjestelmähankkeita Suomessa tehdään. Ne ovat totta kai paras tapa saada palveluväylä nopeasti toimintaan ja käyttöön. Mutta softa on tässä viime kädessä sivuroolissa, tärkeintä onnistumisen kannalta on muuttaa toimintatapoja ja ajattelutapoja.

Ja siksi tärkein yksittäinen ratkaisu on, millaisia ihmisiä hanketta vetämään palkataan. Sellaisen tuloksen saa, millaiset tekijät palkkaa.

Ensinnäkin, pitää palkata osaavia.

Pätevyyttä on monenlaista, ja montaa erilaista osaamista tässä tarvitaankin: poliitista, teknistä, byrokratiaa, muutosjohtamista… Ei tule olemaan helppo homma. Mutta on helppoa keksiä yksi minimiehto, jonka onnistuminen edellyttää: hankkeeseen tarvitaan ihmisiä, jotka ymmärtävät miten ohjelmistoja tehdään.

Vielä konkreettisemmin: jotta hanke voisi onnistua pitää palkata ihmisiä, jotka ovat joskus tehneet työkseen ohjelmointia, mieluiten vielä muualla kuin julkisen sektorin hovihankkijoilla. Kaikkien ei tarvitse vanhoja koodereita, mutta puolet porukasta olisi syytä olla.

Hankkeessa on tarkoitus levittää toimintatapoja, joilla softaprojektit voivat onnistua (sen sijaan että muuttuvat tahmeiksi mammuteiksi). Ja näiden tapojen levittämisessä auttaa paljon, jos oikeasti ymmärtää miten ja miksi ne toimivat.

Toisekseen, pitää palkata muutosta haluavia.

Tehtäessä muutoshanketta avain on totuttujen toimintatapojen muuttamisessa. Tarkoitus on tehdä asiat eri tavalla kuin ennen, ja siksi olisi hyvä palkata ihmisiä, jotka haluavat tehdä asiat paremmin kuin ennen. Haluavat sitä niin paljon, että ovat valmiita näkemään vähän vaivaakin, jotta hanke onnistuisi. Jos näin ei tehdä, hanke tuskin voi onnistua.

Kolmannekseen, pitää palkata ihmisiä, jotka uskaltavat rikkoa totuttuja toimintatapoja.

Kun tarkoitus on muuttaa toimintatavat, halun lisäksi tarvitaan valmiutta rikkoa vakiintuneet käytännöt. Vallankumousta ei tehdä pelkästään kabineteissa pullaa syömällä.

Näillä eväin lähtisin itse liikkeelle.

Kuinka suomalainen tietoyhteiskunta korjataan?

Suomalainen tietoyhteiskunta ei voi hyvin. Hälyttäviä merkkejä näkyy kaikkialla.

• Helsinki ja Vantaa joutuvat maksamaan 2-4 miljoonaa toimeentulotuen hakulomakkeista. Hankintaa ei voi kilpailuttaa, koska kunnat ovat toimittajaloukussa.
• Koko terveydenhuollon IT on yksi valtava murheenkryyni, jossa projektit voivat kestää kymmenen vuotta.
• Olemme julkishallinnon järjestelmäintegraatiossa ehkä 10 vuotta Viroa jäljessä, kun 20 vuotta siten olimme yli 10 vuotta edellä.

Vielä 90-luvulla saattoi vakavalla naamalla puhua Suomesta edelläkävijänä sähköisessä hallinnossa ja asioinnissa. Tänään se kuulostaa vitsiltä, ja pikemminkin pitäisi pyrkiä saamaan naapurimaita kiinni.

Emme kuitenkaan elä jäätyneessä helvetissä. Myös muutoksen merkkejä on ilmassa.

• Yhä uusia datasettejä avataan jatkuvasti
• Ketterät kehitysmallit alkavat olla yksityisellä puolella standardi, ja myös julkisen sektorin onnistumistarinoita löytyy
• Kunnatkin kehittävät yhdessä palveluita avoimena lähdekoodina
• Omituiset ”maan tavat” kyseenalaistetaan julkisesti
• Maan hallitus haluaa avata datat
• Helsinki perustaa kaupunginhallituksen jaoston kaivamaan IT-ongelmat esiin.

Rengit lekottelevat pihalla ja isäntä katsoo voimattomana vierestä Eero Järnfeltin maalauksessa vuodelta 1893. 120 vuotta myöhemmin kone tekisi renkien työt, jos softa vaan toimisi oikein.

Hyvä renki on blogi, jolla on tavoite. Me haluamme korjata suomalaisen tietoyhteiskunnan.

Blogi kertoo asioista, jotka IT-hankkeissa ja käytännöissä on vialla, sekä ideoista, miten tilannetta voisi korjata. Puhumme tekniikasta ja puhumme yhteiskunnasta, sillä ongelma on molemmissa, ja se täytyy korjata niissä molemmissa. Puhumme projekteista, hankintajuridiikasta, kommunikaatiosta, markkinataloudesta, hallintokäytännöistä ja toimintakulttuurista, sillä kaikki nämä liittyvät tietoyhteiskuntaan.

Meillä ei ole mitään hopealuotia, joka ratkaisisi kaikki ongelmat. Sellaista ei ole olemassakaan. Mutta olemme vuosien varrella kohdanneet muutamia hyviä ideoita, jotka auttavat eteenpäin:

• Ketterä kehitys saa projektit lähes aina onnistumaan vesiputousta paremmin
• Avoin data luo tilaa uusille yllättäville palveluille
• Avoin koodi on varsinkin julkishallinnossa hyvä tapa välttää toimittajaloukkuja.
• Pilvipalvelut nopeuttavat kehitystä ja mahdollistavat kevyet kokeilut
• Käyttäjälähtöinen suunnittelu tuottaa palveluita, joille on oikeasti käyttöäkin
• Julkisuus ja avoin keskustelu vähentävät korruptiota ja moraalittomia toimintatapoja

Nämä eivät ole valmiita vastauksia, nämä ovat lähtökohtia etsintäretkelle jolle pyydämme sinut mukaan.

Hyvän rengin ylläpidosta vastaa Codento – pienehkö helsinkiläinen ohjelmistoyritys. Mutta vallankumouksia ei tehdä yksin. Siksi kutsummekin mukaan kaikki, jotka ovat samalla asialla. Ei haittaa oletko asiakkaamme, kilpailijamme, tai kuka vain. Toimiva tietoyhteiskunta on meidän kaikkien etu.

Pyydämme, että:

1. Tykkäät rengistä Facebookissa tai seuraat meitä Twitterissä
2. Kutsut kaverisikin mukaan
3. Vinkkaat meille, kun näet jotain, mistä pitäisi kertoa eteenpäin
4. Etsit tapoja saada IT-projektit onnistumaan paremmin
5. Vaadit kotikunnassasi ja työpaikallasi, että IT-ongelmia ei hyväksytä, vaan ne korjataan.

Hyvään renkiin voi tarjota tekstejä ja ideoita kommentilla, FB:ssä tai vaikka maililla otso.kivekas (at) codento.com. Ei haittaa, vaikka sama teksti olisi jo julkaistu muualla.

Toimittajaloukku vantaalaisittain

Kesäkuussa Vantaa osti toimeentulotuen nettihakemuksien käsittelyjärjestelmän 1,9 miljoonalla CGI:ltä (ent Logica, ent VM-Data) suorahankintana, kilpailuttamatta. Heinäkuussa selvisi, että Helsinki on ostanut saman toiminnallisuuden CGI:ltä 1,85 miljoonalla, myöskin kilpailuttamatta.

Kumpikin kaupunki osti noin kahdella miljoonalla nettilomakkeen ja sen integroinnin taustajärjestelmiin. Useammankin eri asiantuntijan arvio julkisten tietojen perusteella oli, että tuon pitäisi maksaa pikemminkin kymmeniä tuhansia euroja kuin miljoonia. Jos taustajärjestelmä on poikkeuksellisen hankala, niin ehkä 200 000€. Mutta ei kahta miljoonaa.

Mistä on kyse

Suorahankinta tarkoittaa sitä, että kaupunki ei etsi markkinoilta parasta tai halvinta ratkaisua, vaan ostaa järjestelmän tietyltä yhtiöltä tämän määräämään hintaan. Koska hankintatapa on ilmeisen altis erilaisille väärinkäytöksille ja vedätyksille, on sen käyttöä rajattu laissa tiukasti. Hankintailmoituksessa Vantaan kaupunki perustelee suorahankintaa näin:

”Toimeentulotuki on kiinteä osa Vantaan asiakastietojärjestelmää, eikä sitä voi erottaa VATJ:stä aiheuttamatta hankintayksikölle huomattavaa teknistä ja taloudellista haittaa. Mikäli sähköinen toimeentulotukiasiointi hankittaisiin kolmannelta osapuolelta, olisi rakennettava erillisiä integraatioita ja tietoliikenneyhteyksiä eri järjestelmien välille. Samalla tieto hajaantuisi useaan tietokantaan, mikä estäisi asiakastiedon keskittämisen samaan järjestelmään. VATJ:n rajapinnat eivät ole avoimia, joten kaikki integraatiot olisi rakennettava erillisinä. Edellä mainitut seikat aiheuttaisivat hankintayksikölle huomattavia ylimääräisiä taloudellisia kustannuksia. Hankinta on tehtävä pakottavasta lainsäädännöstä johtuvista syistä. Vantaan kaupunki ei tällä hetkellä pysty noudattamaan toimeentulon käsittelylle asettuja määräaikoja.”

Tässä on kyseessä toimittajaloukku. Se on tilanne, jossa tietojärjestelmää tarvitseva taho on täysin yhden toimittajan armoilla. Tällöin toimittaja voi käytännössä sanella hintansa. Katsotaanpa vähän tuota hinnoittelua.

Vantaalla lasketaan säästettävän järjestelmän avulla 15 henkilötyövuotta. Kun yksi henkilötyovuosi maksaa vajaat 38 300, tarkoittaa tämä 425 000 euron vuotuista säästöä. Ihan kiva säästö siis, pitkän päälle.

Mutta Vantaa on mukana Apotti-hankkeessa, jossa Helsingin seudun kuntien terveydenhuollon ja sosiaalitoimen järjestelmät korvataan yhdellä yhteisellä järjestelmällä. Nyt ostettava koodi on siis tarkoitus heittää roskikseen parin vuoden jälkeen. Realistisesti luultavasti hankkeen loppupäässä, noin 2018.

Jos oletetaan, että säästöt saataisiin täysimääräisinä, ehtisi järjestelmän elinkaaren aikana siis säästyä noin 2,1 miljoonaa euroa. Eli projekti maksaa sen verran, että se juuri ja juuri kannattaa vielä tilata. Pienikin viivästys tai budjetinylitys, niin olisi kannattanut ennemmin palkata 15 ihmistä lisää.

Helsingissä taas kustannussäästöksi on laskettu 0,8 – 1,6 miljoonaa euroa vuodessa. Toisaalta järjestelmään liittyy kaikenlaisia oheiskuluja enemmän, joten kokonaisuudessaan takaisinmaksuajaksi on laskettu 3 vuotta käyttöönotosta. Jos käyttöönotto saadaan tehtyä suunnitellusti 2014 alkuun, järjestelmä ehtii olla käytössä ehkä 3-4 vuotta, eli sopivasti juuri niin kauan, että se kattaa kulunsa. Kuinkas sattuikaan.

Vaikuttaisi siltä, että tässä on tehty niin sanotusti maksukykypohjaista hinnoittelua. Siinä tuote maksaa juuri niin paljon, kuin mitä asiakas on siitä korkeintaan valmis maksamaan. vaikka se olisi kymmenen kertaa kohtuullinen hinta.

Vapaassa markkinataloudessa tuotteensa saa tietenkin hinnoitella juuri kuten haluaa. Yleensä vaan ylihinnoittelija menettää asiakkaansa, mutta toimittajaloukussa ei. Toimittajayrityksellä on kissanpäivät, asiakas on pulassa.

Asiakas, joka hankkiutuu tällä tavoin toimittajan armoille, on hoitanut asiansa todella huonosti.

Miten tähän on tultu

Helsingin sosiaalitoimessa on käytössä CGI:n toimittama ATJ-järjestelmä ja Vantaalla VATJ. Tai no, oikeastaan CGI ei ole niitä toimittanut. Historia on hiukan monimutkaisempi. ATJ tarkoittaa AsiakasTietoJärjestelmä ja VATJ on siitä muokattu versio, Vantaan AsiakasTietoJärjestelmä. Ne kehitti pääkaupunkiseudun kuntien omistama PKT-tietokeskus 80-luvulla. Kyse oli siis kuntayhtymästä, joka teki kuntien omiin tarpeisiin ATK-järjestelmiä. Se, että eri kunnille tehtiin omat versiot oli ajan tapa.

Vuosina 1997-2007 Suomessa tapahtui tietojärjestelmiä toimittavien yritysten kentässä melkoinen myllerrys. valtio, kunnat ja kuntayhtymät alkoivat luopua it-yksiköistään. Alan yritykset ostivat niitä ja toisiaan nopeassa tahdissa. Seurauksena julkishallinnon tietojärjestelmät päätyivät lopulta lähes kaikki kahdelle toimijalle: Tiedolle ja Logicalle. ATJ:n polku fuusiopuussa kulki näin:

• 1990 PKT-tietokeskus fuusioitui Kunnallistiedon (muiden kuntien vastaava yksikkö) kanssa KT-tietokeskukseksi
• 1997 KT-tietokeskus listautuu pörssiin nimellä Novo Group
• 2004 ruotsalainen VM-Data ostaa Novo Groupin
• 2006 brittiläis-hollantilainen LogicaCMG ostaa VM-datan
• 2012 kanadalainen CGI ostaa Logican

Kun kuntien yhteinen yksikkö muuttui ensin kuntien omistamaksi yhtiöksi, sitten kotimaiseksi pörssiyhtiöksi ja lopulta kansainvälisen yrityksen haarakonttoriksi, toimintatavat kulkivat perässä hitaammin. Alkujaan ATK-yksikön vastuulla ei ollut pelkästään koodaaminen, vaan myös tuleviin kehitystarpeisiin varautuminen ja suunnittelu. Ja siellä se on edelleenkin. Ei jollain Vantaan sosiaalitoimella ole ollut realistisia edellytyksiä suunnitella ja ennakoida tietojärjestelmiensä kehitystarpeita, arkkitehtuurimuutoksia ja mahdollisia kilpailutuksia. Käytännössä ATJ:n ja VATJ:n kehityksestä ovat vastanneet PKT-tietokeskuksen perilliset, KT-kuntatieto, Novo, VM-data, Logica ja nyt CGI. Kaupungin rooliksi on jäänyt kysyä paljonko rahaa varataan budjettiin ja maksaa laskut.

Hanna Kuusela ja Matti Ylönen kuvaavat kirjassaan Konsulttidemokratia tätä rakennetta. Valtion ja kuntien IT-yksiköt päätyivät osaksi isoja konsulttitaloja, mutta niiden rooli toiminnassa oli ja on edelleenkin paljon suurempi kuin ulkopuolisella tarjoajalla saisi olla. Vantaa ja Helsinki eivät ole ongelmiensa kanssa mitenkään yksin. On aivan normaalia ja maan tapa, että IT-yritys rahastaa kovalla kädellä yksinoikeuttaan järjestelmään, joka on alkujaan tehty kuntien rahalla. ”Järjestelmien suljetut ohjelmistorajapinnat toimivat suoranaisena kiristyskeinona, jolla sosiaali- ja terveydenhuollon yksiköitä pakotetaan hankkimaan kaikki palvelut samalta toimittajalta”.

ATJ:n ja tulevan Kansallisen sosiaaliarkiston (KanSa) integrointisuunnitelma. Kuva ei liity suoraan tässä käsiteltyihin projekteihin.

Varsinainen virhe ei siis ollut tämä yksi hankinta. Virhe on tehty joka päivä viimeiset viisitoista vuotta, kun sosiaalitoimen ydintoimintojen järjestelmää ei ole otettu millään tapaa omaan hallintaan – edes rajapintojen tasolla. Pörssiyrityksen tehtävä on tuottaa voittoa, eikä suojella kuntia näiltä itseltään. Kun työntää päänsä katiskaan, hyviä lyhyen tähtäimen ratkaisuja ei enää ole.

Apotti korjaa tilannetta osin, koska siinä vaaditaan avoimia rajapintoja, joiden päälle uusia lisäosia voidaan hankkia muualtakin kuin taustajärjestelmän toimittajalta. Tosin rajapintojen määrittely ja pahimmassa tapauksessa avoimuuskin jää taustajärjestelmän toimittajan vastuulle. Samassa katiskassa on siis kaikkien muidenkin päät, ja silmäkoko on isompi eli pikkukalat pääsevät kulkemaan.

Apotin tapa voi kuitenkin periaatteessa, jos kaikki sujuu onnellisten tähtien alla, johtaa ihan oikeisiin hyötyihin, kun ulkomailla jo valmiiksi kehitetyn järjestelmän ominaisuuksia saadaan käyttöön ”ilmaiseksi”. Vantaan ja Helsingin tapa, jossa yksityisellä yrityksellä on vain yhden asiakkaan käytössä oleva vanhanaikainen tuote, ei missään kuviteltavissa olevassa maailmassa voi johtaa kuin katastrofiin.

Mitä sitten pitäisi tehdä?

Ratkaisua ongelmiin avaa Espoon melko vastaava tapaus vuoden takaa. Espoo hankki kotihoidon optimointisovelluksen (älkää kysykö mikä se on) suorahankintana Tiedolta, koska sovellus rakentui suoraan Tiedon Effican päälle, ja ”sovellus on teknisistä syistä pakko hankkia Effica-järjestelmän toimittajalta.”

Kolme yritystä valitti markkinaoikeuteen, vedoten siihen, että ovat toimittaneet vastaavia järjestelmiä. Valituksia ei tutkittu, koska ne myöhästyivät, mutta Espoo päätti kuitenkin perua hankinnan ja kilpailuttaa työt.

En tiedä Espoon hankkeen jatkoa tarkemmin, mutta nyt Espoo testaa yhdessä Lahden ja Kuntien Tieran kanssa ”hyvinvointijärjestelmien tietojen välittämistä palveluväylän kautta” perustuen Viron X-roadiin. Kuulemani mukaan siinä pilotoidaan juurikin kotihoidon optimointisovellusta. Palveluväylän ansiosta itse sovelluksen voi tehdä helposti kuka vain, vaikka taustalla on edelleen Tiedon Effica.

Menemättä tällä kertaa sen syvemmälle X-roadin ja väyläarkkitehtuurin kiehtoviin saloihin, tiivistän mitä Helsinki ja Vantaa voisivat länsinaapurilta tässä oppia

1. Älä tilaa suorahankintana järjestelmätoimittajaltasi, vaikka he kuinka sanoisivat että on pakko. Se on luultavasti laitonta ja varmasti tyhmää.
2. Rakenna arkkitehtuuri, jossa uudet sovellukset ovat irrallaan perustiedoista ja hankinnat voidaan tehdä vapaasti. Se on ensimmäinen askel toimittajaloukusta vapautumiseksi
3. Tee se mieluiten vuosia sitten. Jos et kuitenkaan tehnyt, tee se heti.

ps. Hesarin Tuomas Peltomäki kirjoitti tänään myös toimittajaloukusta ja Helsingin hankkeesta. Kannattaa lukea.

Julkaistu alkujaan Otson blogissa

Mitä lääkkeeksi eReseptille?

Perjantaina nousi pieni haloo siitä, kuinka sähköiseen reseptiin mahtuu vain 50 merkin pituinen selitys käyttötarkoituksesta.

”Ongelman korjaaminen tulee kalliiksi ja vie aikaa, kertoo projektipäällikkö Riitta Konttinen THL:stä.

– Siinä menee noin puolitoista vuotta. Kärsivällisyyttä tarvitaan ennen kun uudistus saadaan käyttäjälle. Muutosten tekeminen ei ole myöskään halpaa.”

Onhan se tietenkin vähän omituista, että puolen päivän työltä kuulostava muutos vie puolitoista vuotta. Mutta todellisuus on joskus omituisempi kuin mitä uskoisi. Tämä ei nimittäin ole suinkaan ensimmäinen omituisuus sähköisen reseptin historiassa.

Valtiontalouden tarkastusviraston surullisenkuuluisa raportti Sosiaali- ja terveysalan IT-hankkeista käsittelee sähköistä reseptiäkin:

• Hanke on eri muodoissaan elänyt 80-luvulta asti, myöhästyen toistuvasti. Suurin syy myöhästymisiin on ollut kiire.
• Vuonna 2002 eReseptiä oli tarkoitus pilotoida 2003. Pilotti viivästyi vuoteen 2005.
• Vuonna 2007 KanTa-palvelut (joista eResepti on ensimmäinen osa) oli tarkoitus toteuttaa noin vuodessa. Tämänhetkisen aikataulun mukaan resepti on käytössä julkisella sektorilla tänä vuonna ja yksityisellä 2015 mennessä. Muut KanTa-palvelut tulevat myöhemmin.
• Alkuperäinen kustannusarvio oli 20 miljoonaa, nyt eReseptin kokonaiskustannuksiksi arvioidaan 70 miljoonaa.
• Sekä aikataulut että kustannusarviot ovat olleet vaihtelevia. VTV:n sanoin: ”Sosiaali- ja terveysministeriöllä ei ole ollut selkeä ja realistista näkemystä KanTa-hankkeen kokonaisaikataulusta. Eri toimijoille esiteyt aikataulut ovat siirtyneet toistuvasti, mikä on johtanut terveydenhuiollon toimijoiden epäluottamukseen minsteriön ohjeistusta kohtaan.”

50 merkin raja ei sinänsä ole kauhean merkittävä ongelma. Itse asiassa voi olla, ettei se ole ongelma ollenkaan. Käyttötavan kohdalle kun voi kirjoittaa myös ”erillisen ohjeen mukaan”. En ole oikea ihminen arvioimaan, paljonko tilaa tarvitaan. Jos kuitenkin katsotaan projektipäällikkö Konttisen tavoin, että 50 merkkiä on liian vähän, niin tässä on kaksi vähän merkittävämpää ongelmaa:

1. Miksi tätä ei havaittu aiemmin, ja
2. Miten korjaus voi kestää puolitoista vuotta (ja maksaa paljon).

Ensimmäinen kysymys voidaan esittää oikeastaan kaikille IT-hankkeille. Sellaista projektia ei nimittäin olekaan, jossa kaikki olisi keksitty etukäteen. IT-hankkeet ovat luonteeltaan ennen kaikkea oppimisprojekteja, joissa opitaan ymmärtämään, mitä hankkeessa oikeastaan pitääkään tehdä. Sivutuotteena sitten syntyy softa.

Vaikka ennakkomäärittelyissä olisi ollut mukana kuinka monta lääkäriä, apteekkaria ja potilasta, on silti selvää, että kunhan järjestelmä saadaan käyttöön, tulee esiin tarpeita joita ei ennalta ajateltu. Se on ihan normaalia.

Ketterissä menetelmissä tämä tosiasia pyritään tunnustamaan, ja tuottamaan loppukäyttäjille toimiva järjestelmä mahdollisimman usein, ideaalisti kahden viikon välein. Kun lääkärit pääsevät kokeilemaan järjestelmää pian, selkiytyvät tulevat tarpeetkin nopeammin. Vuoden 2002 jälkeen eReseptiä olisi ehditty demota 250 kertaa. Niissä olisi varmasti löytynyt muutamakin virhe ja kehitysidea.

Sähköisen reseptin kehitysjakso ei kuitenkaan ole kaksi viikkoa, vaan ilmeisesti kaksi vuotta. Jos ja kun nyt huomataan pieni puute, sen saaminen korjatuksi vie 18 kuukautta. Potilasturvallisuuden takia tarvitaan tietysti aika paljon parempi testaus kuin jossain webikaupassa. Ja kokonaisuudessa on toki monia toimittajia. Mutta vähintäänkin kolmen kuukauden kehitysjaksojen pitäisi olla hajautetussa monitoimittajaympäristössäkin aivan realistista.

Tämä ei kuitenkaan vastaa itse kysymykseen: miten tämä voi olla näin?

Politiikan kommentaattori Veikko Eranti kertoo fiktion keinoin, miten tämä lapsus olisi voinut tapahtua. ”Koko sektorin liiketoimintamalli nimittäin perustui sekundan myymiseen ymmärtämättömille keiloille, ”huipputeknologian” kauppaamiseen pohjimmiltaan kirjoituskoneajassa eläville ihmisille, joiden sihteerit hoitivat heidän sähköpostinsa.”

Kuten yleensäkin, todellisuus on tietenkin hiukan monimutkaisempi. Viidenkymmenen merkin raja ei ole syntynyt yhdessä palaverissa, eikä kyse ole vain yhdestä järjestelmästä.

eResepti koostuu Reseptikeskuksesta ja sitä käyttävistä potilastietojärjestelmistä sekä apteekkijärjestelmistä. Suomessa on yli 300 kuntaa, 20 sairaanhoitopiiriä, 4000 yksityisen terveydenhuollon toimijaa ja 800 apteekkia. Jokaisella näistä on oma järjestelmä ja jokaisella niistä toimittava yritys. Kyse on siis tuhansista asiakkaista ja kymmenistä softantoimittajista.

Eri osapuolien kommunikaatio perustuu XML-muotoisiin CDA R2-sanomiin, jotka määritellään HL7-standardeissa. Kaikille eri kentille annetaan kiinteät pituudet, ja käyttötarkoituksen pituus sattuu olemaan 50 merkkiä. Alle 12-vuotiaan painolle on muuten 5 merkkiä, joten parasta olla tekemättä satakiloisia lapsia.

Esimerkkireseptissä Pekka Potilaalle on määrätty Diapamia ahdistuksen hoitoon.

XML sinänsä ei tekstimuotoisena formaattina vaadi kentille pituusrajoja. Itse asiassa olisi helpompaa tehdä sanomajärjestelmä, jossa ei rajoja ole. Mutta sitten kaikkia eri järjestelmiä päivittävät softatalot eivät tietäisi etukäteen, täsmälleen minkä mittaisilla teksteillä eResepti pitäisi testata. Nykyaikaiset systeemit toki selviäisivät helposti pitkistäkin teksteistä, mutta kaikki järjestelmät eivät ole nykyaikaisia.

Jossain on siis olemassa apteekkitietojärjestelmä, joka kykenee vain tähän määrään. Monet kykenevät enempään. Nyt luotiin uusi kansallinen järjestelmä rajoittaen sen toimintaa heikoimman vanhan järjestelmän speksein.

Suomessa, toisin kuin vaikka Tanskassa, ei ole mitään kansallista tahoa, joka ohjaisi terveydenhuollon järjestelmien kehitystä yhteentoimivaan – tai ylipäänsä toimivaan – suuntaan. Sen sijaan jokainen taho tekee asiat omalla tavallaan, ja ainakin eReseptiä kehitettiin vahvasti konsensusperiaatteella, eli ratkaisujen tuli sopia kaikille. Ja VTV:n sanoin:

”Hankkeen toteuttamisen etenemiselle ei ole riittävää ponninta, koska jatkuva rahoitus on omiaan edistämään eri osapuolten jatkorahoituksen saamista omalle henkilöstölleen”.

Eli suomeksi: Mitä vähemmän edistystä, sen enemmän rahoitusta. Ihmekös tuo jos kestää. Ei ole tietenkään projektin toimittajan vastuulla ajatella asiakkaan etua. Se on asiakkaan vastuulla. Pitäisi osata ostaa IT-järjestelmiä.

Ei ole normaalitila tai business as usual, että hankkeet myöhästyvät kymmenen vuotta tai budjetti kolminkertaistuu. Se kertoo siitä, että asiat ovat vakavasti pielessä. Ulkopuolisen on mahdotonta sanoa, tarkalleen mihin aika ja rahat ovat menneet. Niillä tuskin on lennelty Bahamalle, vaan hyvä arvaus on, että ne ovat menneet vääriin toimintatapoihin. Esimerkiksi siihen, että yritetään pakottaa kaikki toimijat käyttämään samoja protokollaversioita.

Ydinviestissään Eranti on siis täysin oikeassa: ongelmana on, että tilaajan puolella pöytää ei ole riittävää osaamista hankkia IT-järjestelmiä. Valtiontalouden tarkastusvirasto päätyi aivan samaan johtopäätökseen: ”Kokonaisuudessaan arvioiden Sosiaali- ja terveysministeriöllä ei ole ollut osaamista eikä edellytyksiä johtaa KanTa-hanketta eikä sitä edeltänyttä sähköistä potilaskertomushanketta osana kansallista terveyshanketta.”

No, mitä lääkettä terveydenhuollon IT:lle sitten pitäisi määrätä? Tässä kolme ideaa:

1. Pitää perustetaa Tanskan Medcomia vastaava organisaatio THL:n tai Sosiaali- ja terveysministeriön yhteyteen vastaamaan terveys-IT:n kokonaisarkkitehtuurista.
2. Järjestelmät pitää päivittää vähintään neljä kertaa vuodessa. Kaikki sellaiset ohjelmistot ja toimintatavat, jotka tekevät tiheästä julkaisusta ongelmallisia, pitää korjata.
3. Jokaiseen IT-hankkeeseen pitää palkata yksi ihminen, joka ymmärtää mitä siinä ollaan tekemässä. Kokemukseni mukaan se parantaa merkittävästi hankkeen onnistumismahdollisuuksia.

Julkaistu alkujaan Codenton blogissa

It-hankintaprojekti sairastaa

Kauppalehti julkaisi tänään Debatti-palstallaan oheisen mielipidekirjoituksen, jonka kirjoitimme yhdessä työpaikkani Codenton toimitusjohtajan, Petri Aukian kanssa.

Alla myös teksti muodossa, jossa sen lähetimme. KL teki tavanomaiseen tapaan pientä journalistista editointia.

Debattikirjoituksemme Kauppalehdessä 24.9.2012

Suomeen on syntynyt julkisen sektorin it-järjestelmien osalta hankintakulttuuri, jolla on kahdenkymmenen vuoden epäonnistumisen historia. Voitaisiin kai sanoa, että it-projekteissa on systemaattisesti epäonnistuttu jo niin pitkään, ettei kukaan enää odota muuta.

Tällainen toimintatapa ei tuota IT-alan ”Nokioita”, yrityksiä, jotka omalla alallaan ylittäisivät kansainväliset rajat ja tavoitteet. On toimittava toisin, jotta saadaan muodostettua kansallisia voittajayrityksiä ja niiden tyytyväisiä asiakkaita.. Esimerkiksi Posti, joka Nokian kanssa aikanaan loi NMT-verkon ja oli aikoinaan nousukiito Soneran menestykseen.

Menestymättömyyden vertailukohtaa voi hakea vaikka urheilusta: jos kestävyysjuoksussa ei ole viime vuosikymmeninä hurrattu kansainvälisillä kentillä, kukaan ei ole pettynyt, jos mitaleita ei tule. Eivät edes valmentajat ja urheilijat itse. Tehdään niin kuin on aina ennenkin tehty, sillä niin ei mene ainakaan enemmän pieleen.

Vähän sama asenne näyttää olevat myös it-hankinnoissa. Julkinen sektori ostaa sinnikkäästi samoilta tahoilta, arvioinneissa käytetään vanhoja tuttuja menetelmiä ja projektit vedetään läpi aivan niin kuin ennenkin. Tehdään varman päälle – niin ei ainakaan voi saada potkuja. Mutta ei myöskään kehitytä.

Erityisen huono menestys on terveydenhuollon it-järjestelmien suhteen.

Viimeaikoina esille ovat olleet HUSin tietojärjestelmäprojektit. Muutenkin otsikoissa on ollut, kuinka suomalaiset terveydenhuollon järjestelmät maksavat 50 kertaa enemmän kuin Viron. Näyttää siltä, että suomalaisten terveydenhuoltojärjestelmien hankinta vaatisi vähän tervehdyttäviä toimenpiteitä, sen verran sairasta homma on.

Kuten monesti aiemminkin julkisen sektorin it-mokien yhteydessä, syyttävä katse suuntautuu järjestelmätoimittajaan. Se ei ole ehkä toiminut asiallisesti, mutta laillisesti kuitenkin. Ostajapuoli kuitenkaan voi paeta vastuutaan alihankkijan selän taakse. Vastuu valinnoista ja päätöksistä kuuluu kuitenkin aina ostajalle. Mikä tietysti edellyttää sitä, että ostajalla pitäisi olla riittävästi osaamista.

Suomalaiseen it-hankintakulttuuriin on juurtunut ajattelumalli, jossa ostetaan ensin mahdollisimman halvalla ja maksetaan toimittajalle sitten enemmän tulevina vuosina erilaisten räätälöintien ja järjestelmäpaikkailujen muodossa. Osittain saattaa olla kyse siitä, että pitää ostaa halvalla. Tällöin myös järjestelmätoimittaja lähettää paikalle halvimmat eli kokemattomimmat tyyppinsä. Osittain on kyse ihan kulttuurista: uskotaan, että näin näiden it-projektien kuuluu mennäkin. Ei kuitenkaan kuulu. Tapa on kallis ja tuottaa huonoa laatua.

Iso-Britanniassa muutama iso it-talo haaskasi vastaavaan terveydenhoitohankkeeseen pari miljardia ennen kuin hanke keskeytettiin.

Yritykset voivat toki hassata rahansa aivan vapaasti sellaisiin investointeihin kuin haluavat, mutta kun leikitään veronmaksajien rahoilla, pitäisi toimia tarkemmin. Esimerkiksi HUS on kuuluisa siitä, että se ylittää vuodesta toiseen budjettinsa. Ja kunnat kaivavat rahat jostain muualta, veronmaksajien taskuista jos ei muuta.

Ostajan osaamista on se, että ostettavat asiat pitäisi kyetä pilkkomaan alaprojekteihin. Väitämme, että yli 100 miljoonan ohjelmistohankkeet epäonnistuvat aina. Kun ne palastellaan järkeviksi kokonaisuuksiksi, onnistumisen mahdollisuudet ovat paljon paremmat. Sadan miljoonan kokonaisuuden työntäminen alihankkijan vastuulle on merkki osaamattomuudesta.

Jokaiseen it-projektiin pitäisi kuulua myös se, että toimittaja voidaan vaihtaa kesken kaiken itse projektin kärsimättä, jos työt eivät etene.

Toivon mukaan julkisella sektorilla ja alalla herätään nyt siihen, ettei kahdenkymmenen vuoden järjestelmäperinteitä enää voida ylläpitää. Ostamisen osaamisen tasoa pitää nostaa. Kyse ei ole pelkästään veronmaksajien rahoista vaan myös siitä, että tietoyhteiskunta tarvitsee toimivia ja ketteriä järjestelmiä.

Otso Kivekäs, asiantuntija, Codento

Petri Aukia, toimitusjohtaja, Codento

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:

1. Terveydenhuollon kokonaisjärjestelmään sisältyy suuria riskejä.
2. Hajautetuista ratkaisuista, ohjelmistojen ekosysteemistä, on pohjoismaista hyviä kokemuksia.
3. 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.

Julkaistu alkujaan Otson blogissa

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:

1. 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.
2. 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.
3. 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.
4. 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:

1. 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.
2. 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).
3. 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:

1. 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.
2. 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ää.
3. 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.

Julkaistu alkujaan Otson blogissa