Avainsana: julkiset ohjelmistohankinnat

Espoo, Epic ja Apotti

Tilanne nyt, 30.1.2013:

Apotti on Helsingin ja Uudenmaan sairaanhoitopiirin (HUS) sekä kuuden pääkaupunkiseudun kunnan hanke potilastietojärjestelmän hankkimiseksi yhdessä. Hankintapäätöksiä tehdään parhaillaan ja järjestelmä on tarkoitus valita loppuvuodesta.

EPIC on wisconsinlaisen Epic Systems Corporationin toteuttama potilastietojärjestelmä, jota Accenture tarjoaa HUSille ja kunnille. Hankkeen alkuvaiheet ovat herättäneet huolen, että kilpailutusta olisi pedattu niin että Epic voittaisi sen.

Espoo on Helsingin länsiosissa sijaitseva 250 000 asukkaan kunta, joka päätti juuri olla lähtemättä mukaan Apotti-hankkeeseen.

Viikko sitten Accenture ja Epic Systems Corporation järjestivät Epicin esittelyn pääkaupunkiseudun valtuutetuille. Paikalla oli tusinan verran valtuutettuja Vihreistä, Perussuomalaisista, Kokoomuksesta ja RKP:stä. Tilaisuudesta löytyy laaja FB-kommenttithreadi, mutta yhteenvedon ja tulkinnan lukee helpommin tästä. Kaikki tiedot perustuvat Epicin asiantuntijoiden vastauksiin, poislukien mahdolliset väärinymmärrykseni.

Ensinnäkin Epic on käytettävyydeltään oikeasti hyvä. Tai no, selvästi parempi kuin nykyään suomessa käytössä olevat järjestelmät. Monimutkaisen ammattilaistyökalun käyttäminen ei ole ihan yksinkertaista hommaa ikinä. Mutta ainakin demossa klikkailumäärät vaikuttivat järjellisiltä eikä tiimalasia tarvinnut tuijottaa.

foo
Epic Systems Corporationin edustajat pyysivät etten julkaisisi tilaisuudessa ottamiani kuvia. Siksi tässä on Nuutti Hyttisen kännykkäkuva, jonka hän ennätti julkaista jo ennen pyyntöä.

Teknisesti EPIC sen sijaan on vanhanaikainen. Sen ydin on kirjoitettu 60-luvun MUMPS-kielellä, joka on nykynäkökulmasta naurettava ja suurin osa käyttöliittymästä on Visual Basicin versiolla 6, jonka virallinen tuki lopetettiin jo 2008. Kuulema tosin Epicillä on Microsoftin kanssa sopimus joka takaa riittävän tuen.

Suurempi ongelma on kuitenkin, että Epic on myös toimintamalliltaan vanhanaikainen. Se on yksi suuri järjestelmä, joka ratkaisee kaikki ongelmat. Kolmansien osapuolien lisäosia ei suosita. Itse asiassa Epic ei tarjoa rajapintoja kolmansille osapuolille lainkaan, vaan integraatioita tehdään ainoastaan asiakkaan suorasta pyynnöstä. Rajapintojen tarkemmasta luonteesta en saanut vastauksia.

Suljettuus menee niin pitkälle, että tosiaan edes kuvia käyttöliittymästä tai tarkkoja ominaisuuksia ei haluta näyttää julkisesti. Myyntitapa muistuttaa 80-luvun kabinettipolitiikkaa, jossa vain asianomaiset tietävät mitä oikeastaan ostettiin ja myytiin, ja hekään eivät saa sitä kenellekään kertoa. Sairaaloiden IT-maailma ei ehkä ole korruptoitunut, mutta siltä tämä taatusti näyttää. Epicin edustajien mukaan syy salailuun on, että sillä estetään kilpailijoita kopioimasta Epicin ominaisuuksia.

Mielenkiintoisesti, Epic kuitenkin tarjoaa koko lähdekoodinsa asiakkaan käyttöön (mutta vain asiakkaan, ei alihankkijoiden). Ensisijainen syy tähän on juridinen: kyse on escrow-palvelua vastaavasta ratkaisusta, jollaista isot asiakkaat usein vaativat. Koodi kuitenkin myös auttaa asiakkaan mahdollista omaa integraatiotyötä. Ilkeämielisesti voisi tulkita, että kyetäkseen käyttämään rajapintoja täytyy siis nähdä ne toteuttava koodikin.

Lähtökohtaisesti siis Epicin laajennokset ja jatkokehityksen tekee Epic Systems Corporation kampuksellaan Wisconsinin Veronassa (vastaa suunnilleen Lempäälää). Jos asiakas haluaa järjestelmältä jotain ominaisuuksia, ne joko löytyvät ennestään, Epic lisää ne järjestelmään niin parhaaksi harkitessaan, tai niitä yksinkertaisesti ei saa mistään. Tietojärjestelmä on käytännössä sama asia kuin toimintatapojen ohjaus, joten tällainen hallinnan menetys tarkoittaa, että terveydenhuollon toimintatapojen kehittäminen ulkoistetaan Wisconsiniin.

Modernit ohjelmistojärjestelmät perustuvat ”ekosysteemiin”, jossa kokonaisuutta orkestroiva yhtiö tekee vain ydinosat tarjonnasta, ja lukuisa joukko pienempiä yrityksiä kehittää kukin omia laajennoksiaan. Hyviä esimerkkejä ovat vaikka Salesforce, jonka asiakkuudenhallintajärjestelmään saa muokkauksia ja laajennoksia sadoilta yrityksiltä tai SAP, jonka toiminnanohjausjärjestelmä on pikemminkin ohjelmointialusta, jonka päälle konsulttitalot koodaavat toiminnanohjauksia. Tai alaa huonommin tunteville vertaus vähän kauempaa: vanha Nokian puhelinkehitys vastaan Applen ekosysteemi ja kaikki applikaatiot.

Ekosysteemiin on menty, koska mikään yksi yhtiö ei yksinkertaisesti pysty kehittämään todella monimutkaisia järjestelmiä kaikkia asiakkaita hyvin palvelevalla tavalla. Ekosysteemi tuottaa paremman lopputuloksen. Se myös sitouttaa asiakkaat paremmin. Vaikka kaikki innovaatiot ovat kilpailijoiden kopioitavissa, ei asiakas halua luopua ekosysteemistä, koska menettää kaikki sen sisältämät palvelut. Ajattele siirtymistä iPhonesta takaisin nokialaiseen.

Mutta kuten sanottu, Epic on ekosysteemin antiteesi. Epic on Nokia. Se on kilpailijoitaan edellä käytettävyydessä samaan tapaan kuin Nokian puhelimet olivat kymmenen vuotta sitten. Eli kilpailijat ovat vaan vielä huonompia. Nykyisillä toimintatavoilla se jää aikanaan väistämättä jälkeen, kun joku kilpailija kykenee ekosysteemin rakentamaan.

Teollisuuspoliittisesti Epicin suljettuus on isompi ongelma kuin STX:n risteilijätilauksen menetys. Uuden risteilijän hytit ja muuta alihankintaa tehtäneen Suomessa ja suurimman osan töistä tekevät samat puolalaiset aivan riippumatta siitä, onko telakka Turussa vai Saint-Nazairessa. Sen sijaan Epicin alihankintatöitä ei Suomeen tippuisi, ainoana poikkeuksena Accenturen asennusdiili.

Terveydenhuollon tarkoitus ei tietenkään ole tuottaa rahaa IT-yhtiöiden kassaan (vaikka toisin voisi joskus luulla alan sopimuskäytäntöjä katsoessa). Mutta kotimaisen alan teollisuuden alasajo on ongelma muutoinkin kuin taloudellisesti. Innovaatiot terveydenhuollon paremmaksi palvelemiseksi syntyvät tarpeiden ja mahdollisuuksien ristiaallokossa, silloin kun järjestelmää kehittävät ja sitä käyttävät ovat läheisesti tekemisissä. Sitä ei tapahdu samalla tavalla 8000 kilometrin päähän.

Siriuksessa visioitu yksi kansallinen potilastietojärjestelmä olisi kansallinen katastrofi. Se tappaisi Suomesta kaiken kyvyn kehittää ja innovoida terveydenhuollon järjestelmiä ja pikkuhiljaa heikentäisi terveydenhoidon laatuamme.

Espoon päätöksen tärkein seuraus onkin, että Apotista ja Epicistä ei voi sellaista tulla. Integraatiot on nyt pakko tehdä kunnolla, eikä voida yrittää kiertää niiden tarvetta kikkailemalla yhteisellä järjestelmällä.

Ehkä parasta mitä nyt voi tapahtua on, että Epic otetaan käyttöön yhdessä sairaanhoitopiirissä tai kunnassa Suomessa, mutta ei muualla. Silloin sen parempi käytettävyys asettaa standardin sille, miten kelvollinen järjestelmä toimii. Sitten käy se, mitä Epic yrittää salailullaan välttää, eli kilpailijat kopioivat sen käytettävyyden ja ideat. Pikkuhiljaa saattaa syntyä suomalaisia järjestelmiä osaksi kansainvälistä potilastietojärjestelmien ekosysteemiä.

Ajatus vain Suomeen tehtävästä järjestelmästä on osoittautunut huonoksi. Mutta suljettujen potilastietojärjestelmien siirtomaaksi ryhtyminen ei ole sen parempi idea. Pitää tavoitella kansainvälisesti toimivia järjestelmiä, joiden ekosysteemissä myös suomalaiset alan yhtiöt menestyvät. Suurin vastuu on nyt alan yrityksillä saada kerrankin jotain kelvollista tuotettua, mutta se vaatii, että julkishallinto ei estä kehitystä.

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

Apotin riskit

Sain käsiini APOTTI-hankkeen riskianalyysin, joka terveyslautakunnan kokousmateriaaleissa salattiin. Se on julkinen dokumentti, joten jaan sen tässä, olkaa hyvät. Postausta on muokattu.

Mitä raportti sanoo?

Tämä on bisnestason analyysi siitä, mitä riskejä hankkeen toteuttamiseen liittyy. Teknisiä riskejä tai hankittavaan järjestelmään liittyviä riskejä ei ole analysoitu. Tämä on ilman muuta virhe, mutta valitettavan yleinen sellainen.

Työmenetelmänä on ollut haastatella hankkeen johdossa olevat henkilöt ja rakentaa yhteenveto heidän esiin tuomistaan huolista. Tästä lähtökohdasta riskianalyysi on sinänsä hyvin tehty, mutta siis hankkeeseen nähden liian suppea.

Muuan riskianalyysejä työkseen tekevä ammattilainen kommentoi:

”Mitään analyysiframeworkkiä tai standardia ei ilmeisesti ole sovellettu, vaan tulosten luotettavuudesta on lähinnä PWC:n sana. Jos otetaan vertailukohdaksi kirjallisuudessa tyypillinen viitekehys

  1. Projects – failing to deliver;
  2. IT service continuity – when business operations go off the air;
  3. Information assets – failing to protect and preserve;
  4. Service providers and vendors – breaks in the IT value chain;
  5. Applications – flaky systems;
  6. Infrastructure – shaky foundations; and
  7. Strategic and emergent – disabled by IT.

Tässä PwC:n paperissa on näistä käsitelty kevyesti ensimmäistä ja viimeistä, ei muita.”

Toinen, 20 vuoden kokemuksella riskianalyysejä tehnyt ja lukenut IT-ammattilainen kommentoi analyysiä ”En ole urallani ikinä nähnyt näin kriittistä analyysiä hankkeesta jota ei ole vielä edes aloitettu”. Hän saattoi toki olla hiukan kyyninen.

”Riskienhallintaan vähemmän tutustuneille suomennoksena:

  1. Konsultti pitää erittäin todennäköisenä, että toimintaa ei saada muutettua hankkeen toteutuksen kautta. Tällä on hankkeen hyötyjen muodostumiselle katastrofaaliset seuraukset.
  2. Muutosjohtajuus, hankkeen vaatimat resurssit ja uuden oppiminen ovat kaikki todennäköisesti menossa pieleen.
  3. (Poliittinen) päätöksenteko hankkeessa epäonnistuu. Päättäjille ei saada oikeaa tietoa ja päätökset tehdään väärien tietojen valossa.
  4. Hankkeen hinta tulee karkaamaan käsistä. (Mikä on konsulttiraportissa poikkeuksellisen voimakas ilmaisu)”

Muutamia huomioita

Sitten vähän yksityiskohtaisempi läpikäynti. Alla omia tulkintojani ja suomennoksiani esiin nostetuista riskeistä. Analyysi kun on kirjoitettu kaunistelevalla konsulttikielellä, jota ei siihen tottumattoman ole aina helppo lukea.

4.1. Hankkeen perusteisiin liittyvät riskit

”Haastatellut kokivat hankinnan laajuuden riskinä sekä tunnistivat kokonaisuuden niin suureksi, että sen ymmärtäminen on haastavaa.”

Kyllä näin on. Normaali johtopäätös olisi pilkkoa hanke ymmärrettävän kokoisiin osiin. Isot IT-hankkeet epäonnistuvat lähes aina juuri siksi, että ne ovat liian suuria ymmärrettäviksi.

”Tuottavuuden kasvun odotukset ja laadulliset tavoitteet pitää varhaisessa vaiheessa konkretisoida mittareiksi, jotka sallivat mahdollisimman vähän tulkinnanvaraisuutta. Jos onnistumista ei konkretisoida mittareiksi jää koko hankinnan menestys subjektiivisten arvioiden varaan ja altistuu spekulaatiolle. Hankkeelle tulee asettaa mitattavissa olevat tavoitteet, joiden toteutumista tulee seurata ja johtaa.”

Niin tulisikin. Miksi sitä ei ole tehty? Jos kyse on ennen kaikkea toimintatapojen muutoshankkeesta, miksi niitä muutoksia ei ole lähdetty hahmottelemaan ensimmäisenä?

4.2. Hankintarengasmalliin liittyvät riskit

”Haastateltavat kokivat HUS:in kaikkein kiireisimmän aikataulun riskiksi, sillä sen koettiin aiheuttaneen tarpeetonta kiirettä hankkeen suunnittelussa ja hankintailmoituksen teossa. Tämän riskin koettiin konkretisoituvan juuri nyt hutiloituun hankintailmoituksen julkaisemiseen ja neuvotteluvaiheen aloittamiseen ilman riittävää suunnittelua.”

Konsultti sanoo, että valmistelua ei ole tehty kunnolla ja että hankintailmoituksessa on ongelmia.

4.5 Hankintaorganisaatioon liittyvät riskit

”Ohjausryhmän työskentelyä pidettiin asiaa edistävänä ja pääasiallisesti tehokkaana, mutta tietotekniikan ja hankintaprosessien substanssiosaamisen koettiin olevan riittämätöntä.”

”Kehittämisryhmän työskentelyssä riskejä nousee haastateltavien mielessä asioiden esittelyn ja aikataulun liiallisesta nopeudesta, yhteisen kielen ja ymmärryksen puutteesta ja keskustelun vähäisyydestä. Asioita on tuota kehittämisryhmään nopealla aikataululla ja haastateltavat kokivat että usein esiteltyjä asioita ja dokumentteja on ollut liian myöhäistä muuttaa. Kehittämisryhmän jäsenistä usea totesi että hankintajuridinen ja tietotekninen sanasto on ongelmallista ja yhteisen kielen puute on hankaloittanut asioiden ymmärtämistä. Riskinä on, että kehittämisryhmä ei pysty täysipainoisesti edistämään hankinnan onnistumista, koska jäsenillä ei ole riittävää hankinnan ja tietotekniikan substanssiosaamista.”

Ensinnäkin, niinhän minä sanoin: osaamista tarvittaisiin lisää. Toisekseen, tästä tulee huolestuttavasti kuva, että hanketoimiston yläpuolisessa ohjauksessa ollaan aika tuuliajolla, eikä tosiasiallista mahdollisuutta tai kykyä ohjata hanketta ole. Hanketoimisto työskentelee siis hyvin itsenäisesti, ilman että sen tarvitsisi kuunnella ulkopuolisia. Tämä vastaa kuvaa, joka erityisesti HUS:n toiminnasta on perinteisesti ollut ja josta ehdottomasti pitäisi päästä eroon.

”Riskienhallintatoimenpiteet eivät ole vielä konkretisoituneet työkaluiksi vaikka keskustelu riskeistä ja niiden vaikutuksista onkin moniulotteista.”

Konsulttikielellä tässä lukee, että riskien hallitsemiseksi ei ole tehty mitään.

”Hanketoimisto on mitoitukseltaan minimaalinen verrattuna hankinnan laajuuteen, sen resurssien pieneneminen olisi merkittävä riski ja vaarantaisi hankkeen onnistumisen.”

Konsultin mielestä hanketoimisto ei ole tehtäviensä tasolla.

4.6 Kilpailuttamiseen, neuvotteluvaiheeseen ja sopimukseen liittyvät riskit

”Koska valmiita järjestelmiä tällä puolelle on hyvin rajallisesti ja ulkomaisissa järjestelmissä ei ollenkaan, ei järjestelmätoimittajien voida ajatella pystyvän demonstroimaan valmiita ratkaisuja.”

Konsultti huomauttaa, että tässä ei olla ostamassa valmista järjestelmää vaan järjestelmä räätälöidään joka tapauksessa HUSin ja kuntien käyttöön. Senhän toki tiesimmekin, mutta päinvastaistakin kuvaa yritetään julkisuuteen antaa.

”Sosiaalihuollon asiantuntijaryhmän perustaminen hanketoimiston alaryhmäksi on välttämätön ja kiireellinen riskienhallinta toimenpide. Ryhmän tulisi valmistautua neuvottelumenettelyyn luomalla tavoitetila ja määrittelemällä hankintaa niin konkreettiseksi että se on kommunikoitavissa palveluntuottajaehdokkaille.”

Konsultin mukaan hankkeessa ei siis tunneta sosiaalihuollon vaatimuksia, eikä järjestelmä luultavasti tule niitä palvelemaan. Miksi sosiaalihuoltoa edes yritetään tuoda mukaan samaan hankkeeseen, kun onnistumisen edellytyksiä ei tunnu olevan?

”Suuressa osassa haastatteluita nousi esille riskinä prosessien määrittelemättömyys ja tavoiteltavan IT-arkkitehtuurin kuvauksen puute.”

Hankkeen tavoitteita ei siis oikeastaan ole määritelty. Riski, jota on kansalaiskeskustelussa pidetty merkittävänä.

”Riskiä hankeorganisaation erimielisyyksistä liittyen määrittelyyn tulisi hallita antamalla selvitys siitä miksi nykyiseen toimintamalliin on päädytty.”

Haastateltavat siis ihmettelevät, miksi hanketoimisto toimii sammutetuin lyhdyin. Vahvistaa valitettavasti ylläkin jo syntynyttä kuvaa ongelmallisesta johtamistavasta.

”Suurimpana kustannustenhallinnan riskinä pidettiin sitä, että palvelun oston hinta muodostuu kokonaisuutena paljon ennakoitavaa suuremmaksi. Tämä liittyy olennaisesti ”jälkilypsyn” mahdollisuuteen, eli siihen ettei palvelutasosopimuksessa ole huomioitu kaikkea vaan järjestelmätoimittaja pystyy rahastamaan muutos-, räätälöinti- ja päivitystöillä loputtomasti.”

Kyse on toimittajaloukusta. Valitulla toimintamallilla se on mahdotonta välttää. Välttämisen tapoja olen käsitellyt aiemmin. Niihin kuuluu ennen kaikkea hankkeen pilkkominen, keskeisten osien kontrollin pitäminen itsellä ja avoimuus.

Riskianalyysi ei sen sijaan tarjoa tähän näitä yleisesti tunnettuja vastauksia, vaan ehdottaa, että palkataan hankintakonsultti. Analyysin kirjoittanut PriceWaterhouceCoopers onkin tiettävästi palkattu hankkeen hankintakonsultiksi.

4.8 Implementaatioon liittyvät riskit

”Sekä muutosjohtajuutta että operatiivista muutosta tulee toteuttaa systemaattisesti koko hankkeen ajan. Kaikkialla ei ole vielä otettu muutoksen ensimmäistäkään askelta, nämä organisaatiot tulee tunnistaa riskien hallitsemiseksi ja niiden toimintaan vaikuttaa ensi tilassa.”

Suomeksi: konsultin mukaan hanke on ainakin osin tuuliajolla.

4.9 Viestintään liittyvät riskit

”Viestintään liittyviä riskejä voidaan hallita tehokkaimmin toimimalla proaktiivisesti. Hanketoimiston tulee aktiivisesti huolehtia oikean ja ajantasaisen tiedon levittämisestä sekä hankintarenkaan päätöksenteolle, hankintarenkaiden osapuolille, lehdistölle ja muille kiinnostuneille sidosryhmille.”

Riski selvästikin on toteutunut ja sen hallinta epäonnistunut. Hanketoimsito ei ole kyennyt toimittamaan julkisuuteen oikeaa ja ajantasaista tietoa, vaan päin vastoin keskeisiä päätöksenteon asiakirjoja on pyritty pimittämään julkisuudelta. Esimerkiksi hankintailmoitus ja tämä riskikartoitus jaettiin Helsingin terveyslautakunnassa vain paperilla, jottei niitä levitettäisi julkisuuteen. Erittäin huono käytäntö, mutta valitettavasti ei ainutlaatuinen.

Avoimempi tiedotuskulttuuri olisi varmasti auttanut hanketta paljon. Esimerkiksi väärinkäsitykset 1,8 miljardin euron hinnasta olisivat voineet jäädä syntymättä. Vielä ei ole myöhäistä reagoida tähän riskiin!

4.10 Johtamiseen ja organisointiin liittyvät riskit

”Merkittävimmät johtamiseen ja organisointiin liittyvät riskit johtuvat siitä ettei hankinnan parissa työskentelevien asiantuntijoiden rooleja, vastuita ja valtuuksia ole kuvattu. Tämä riski ei koske vain ohjaus- ja kehittämisryhmään sekä hanketoimistoa vaan kattaa myös kussakin kunnassa työskentelevien asiantuntijoiden toimintaa hankkeessa.”

Suomeksi: konsultin mielestä hanketta ei ole suunniteltu kunnolla, vaan se on kaikilla tasoillaan  tuuliajolla tai vähintään aivan liian keskeneräinen päätöksiä varten.

”Ohjausryhmään kohdistuu riski siitä, että heidän panoksensa hankkeen läpiviemiseen jää pinnalliseksi ”tuen antamiseksi”. Tukemisen sijaan vaativa hanke vaatii johdolta todellista sitoutumista ja panostusta hankalienkin asioiden läpivientiin. Lisäksi johdon tulee investoida aikaansa aihealueeseen perehtymiseen, jolla parhaiten vältettäisiin riski siitä että päätöksiä tehdään vajavaisin tiedoin.”

Suomeksi: konsultin arvio on, että johtoryhmä ei ole tilanteen tasalla.

Liite 1: : Haastatellut asiantuntijat

”Hanketoimisto antoi 21 henkilön listan haastateltavista henkilöistä. Näistä Lasse Lehtonen (HUS) ja Mikko Rotonen (HUS) kieltäytyivät haastattelusta. Tapio Korhosen (Helsinki) kanssa ei saatu sovittua sopivaa haastatteluaikaa hänen kiireisen kalenterinsa vuoksi.”

Siis hankkeen projektipäällikkö ja hanketoimiston keskeisin puuhamies kieltäytyvät riskienhallintakonsulttien haastattelusta. Aikatauluongelmat voi ymmärtää, sellaista sattuu, eikä aina voida jäädä odottamaan jokaista. Mutta suora kieltäytyminen on varovaisesti sanoenkin hyvin erikoista.

Jos aiemmat kriittiset huomautukset voisikin ajatella konsulttien ylivarovaisuudeksi (ja tulkintani niistä ylireagoinniksi), niin tässä kohti viimeistään syntyy kuva, että hankkeen johtamisessa on nyt jotain pahasti ongelmallista.

Mitä raportti ei sano

Vielä merkittävämpää kuin riskianalyysin sisältö on, se mitä siinä ei ole.

  • Teknisiä riskejä ei ole käsitelty juuri lainkaan.Selvästikin tarvitaan vielä erillinen riskianalyysi siitä, miten itse järjestelmän mahdollisiin ongelmiin varaudutaan. Tätä on syytä käsitellä jo ennen hankintaa, koska riskeihin täytyy reagoida jo kokonaisarkkitehtuurissa (jota ei ole ainakaan julkaistu, jos on suunniteltu).
  • Vertailua saman kokoluokan epäonnistuneisiin hankkeisiin (esimerkiksi NHS) ei ole tehty. Miten aiotaan välttää brittien virheet?
  • Vaihtoehtoja yhteen toimittajaan sitoutumiselle toimittajaloukon välttämiseksi ei ole käsitelty.
  • Riskiä, että järjestelmää joudutaan vaihtamaan uudestaan ei ole käsitelty lainkaan. Muuan IT-ostopäällikköä siteeratakseni ”ensimmäinen mitä kysyn on aina, että miten systeemistänne pääsee sitten aikanaan eroon”. Nyt HUS aikoo käyttää satoja miljoonia päästäkseen eroon Uranuksesta. Paljonko Apotista luopuminen tulee maksamaan?

Yhteenveto

Hankkeesta tulee tämän raportin perusteella ongelmallinen kuva. Vaikuttaa siltä, että hanketta ajetaan kuin käärmettä pyssyyn, eikä osaaminen ole riittävällä tasolla näin suureen hankkeeseen. Valittu toimintatapa on koettu ongelmalliseksi, mutta halukkuutta keskustella siitä ei ilmeisesti hankkeen johdossa ole.

Hankkeen johtajaa Lasse Lehtosta lainatakseni, ”Kritiikki ei vaikuta hankintaan”.

Tältä pohjalta täytyy sanoa, että riittävää riskianalyysiä hankkeen käynnistämiseksi ei ole tehty. Sitä ei tosin tarvitakaan, koska jo tämä kevyt analyysi osoitti johtamisessa ja toimintatavoissa merkittäviä puutteita, jotka täytyy korjata jotta hankkeella olisi onnistumisen mahdollisuuksia.

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ä:

  1. Yritetäänkö tässä ulkoistaa vastuuta?
  2. Riittääkö osaaminen?
  3. 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:

  1. vahva oma osaaminen tietojärjestelmän kehittämisessä
  2. 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ää?

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

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

  3. 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

  4. 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ä.

  5. 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:

  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.

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:

  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.

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ä?