Miten tietojärjestelmähankinta epäonnistuu tai onnistuu

Jokaisen tietojärjestelmähankinnan kriittisin vaihe on alussa, ennen kun tarjouspyyntöä tai määrittelyä aletaan valmistella. Siinä kohti pitäisi kysyä, mitä me oikeastaan olemme tekemässä. Ja usein hankinta epäonnistuu jo tässä kohtaa, koska kriittisiä kysymyksiä ei käydä riittävästi läpi.

Tärkein kysymys liittyy siihen, mitä olemme organisaationa tekemässä. Tietojärjestelmää ei voi erottaa toimintatavasta, jota sen olisi tarkoitus tukea. Esimerkiksi Apotti on tullut surullisenkuuluisaksi rakenteisesta kirjaamisesta erotuksena aiempien potilastietojärjestelmien vapaatekstikenttiin. Apottia ei voi käyttää ilman rakenteista kirjaamista, muissa Suomessa käytetyissä järjestelmissä taas voi kirjata lähinnä vapaatekstinä. Oliko muutos rakenteiseen kirjaamiseen harkittu ja tietoinen päätös? Ymmärrettiinkö sen seurauksia riittävästi?

Yleensä toimintatapoja halutaan muuttaa: jos tavoitteena ei olisi muutos, luultavasti jatkettaisiin kuten ennenkin. Eli hankinta lähtee siitä, että ymmärretään haluttu muutos toiminnassa. Jos muutosta ei mietitä tietoisesti, on iso riski, että päädytään määrittelemään järjestelmä tukemaan aiempaa toimintatapaa – josta siis haluttiin eroon. Miika Kuha kirjoittaa omassa blogitekstissään siitä, miten tätä organisaation muutosajurien tunnistamista voi tehdä. Yksi hyvä työkalu on myös arvovirtakartta.

Toisaalta toimintatapaakaan ei voi määritellä irrallaan tietojärjestelmästä, vaan yhteys on kaksisuuntainen: toimintatavasta seuraa millainen järjestelmä halutaan, mutta tarjolla olevista vaihtoehdoista seuraa, millainen toimintatapa on mahdollinen. Käytännössä toiminnan muutosta ja järjestelmävaihtoehtoja pitää selvittää rinnakkain tai vuorotellen iteroiden.

Tietojärjestelmän hankintaan on kolme perusstrategiaa: valmistuote, oma kehitys ja strateginen kumppani. Jokaisella on omat hyvät ja huonot puolensa, eikä ole olemassa mitään yleissääntöä että yksi olisi toista parempi.

Miksi valita valmistuote?

Valmistuotteen etuna on, että se on valmiina saatavissa, eli nopea – ja milloin se on valintana mahdollinen, se on yleensä halvin vaihtoehto. Haittapuolena on, että valmistuote on sellainen kuin on, joten toimintatapa täytyy sopeuttaa siihen. Useimpia järjestelmiä pystyy jonkin verran muokkaamaan ja käyttämään vaihtoehtoisilla tavoilla, mutta mitä kauemmas erkaannutaan tuotteen perusprosessista, sen heikommin se luultavasti tukee toimintatapaa. Siksi valmistuotetta valittaessa tärkein kysymys on, pystymmekö sovittamaan toimintamme tähän järjestelmään? Kuinka kykeneviä ja halukkaita olemme muuttamaan toimintaa?

Valmistuote voi olla SaaS-palvelu tai erikseen asiakaskohtaisesti asennettava

Teknologiavalintojen ja organisaation käyttämien järjestelmien rooli on suuri ja pohdinta siitä miten asia ratkaistaan on strateginen

järjestelmä. Tilanteesta riippuen sen hankinta voi olla luottokorttiostos, monimutkainen sopimusneuvottelu tai mitä tahansa näiden väliltä. Perusprosessina on selvittää vaihtoehdot, vertailla ja koekäyttää niitä, tunnistaa muutokset omiin toimintatapoihin ja arvioida niiden hyvät ja huonot puolet. Lopuksi tasapainotetaan kustannuksia ja toimintatapoja. Julkisena hankintana erityinen haaste on, että toimintatapoja arvioidaan vasta vaihtoehtojen tunnistamisen jälkeen, mikä tekee suoraviivaisen tarjouspyynnön vaikeaksi.

Mitä oma kehitys tuo, jos siihen päädytään?

Oman kehityksen etu on puolestaan se, että järjestelmän voi määritellä juuri haluamakseen. Huono puoli on, että kehitys on hidasta ja kallista, lähes aina paljon kalliimpaa kuin valmiit ratkaisut. Useimmiten käykin niin, että tavoitteita on kustannussyistä pakko karsia, eikä järjestelmä täytäkään niitä toiveita mitä alussa oli. Lisäksi järjestelmän määrittely on aidosti vaikeaa. Etukäteen tehdyt tarkat määrittelyt unohtavat aina jotain olennaista, ja toisaalta sisältävät asioita joita ei lopulta tarvitakaan. Ongelmaa voi hallita ketterällä lähestymistavalla, mutta sen hintana tulee epävarmuus lopullisista kustannuksista.

Oman kehityksen kustannusta voi joskus olla mahdollista alentaa avoimen lähdekoodin kehityksellä, jossa samaa kustannusta jakamaan saadaan suurempi joukko käyttäjiä. Esimerkiksi monien Suomen kaupunkien kehitämä eVaka-päivähoitojärjestelmä on tästä hyvä esimerkki.

Oma kehityskin on useimmiten ulkoa hankittua ohjelmistokehitystä, käytännössä ketterän tiimin kilpailutus. Omana osaamisena on kuitenkin välttämättä oltava tuoteomistaja, joilla on kykyä ohjata kehitystä ja käydä jatkuvaa vuoropuhelua toimintatapojen ja kehitystyön ristipaineessa. Yleistäen voisi sanoa, että ulkoistetussa kehityksessä onnistuvat sellaiset organisaatiot, jotka kykenisivät tekemään saman kehitystyön myös sisäisesti. Voidakseen hankkia koodausta, pitää myös ymmärtää jonkin verran koodausta.

Strategisen kumppanuuden merkitys on suuri

Strateginen kumppani on ulkopuolinen firma, joka kehittää omaa ohjelmistotuotettaan, mutta tiiviissä yhteistyössä kanssamme, niin että meidän tarpeemme ohjaavat osittain heidän tuotekehitystään. Näin saadaan osa oman kehityksen joustavuudesta ja mahdollisesti osa valmistuotteen kustannusedusta, mutta haasteena on tiivis sitoutuminen yhteen toimijaan ja sen tuleviin ratkaisuihin. Onnistunut suhde vaatii kumppanin tavotteiden ja insentiivien ymmärtämistä sekä molemminpuolisen luottamuksen kehittämistä.

Strateginen kumppanuus on enemmän kuin hankinta, se on molemminpuolinen pitkäaikainen sitoumus yhteisiin tavoitteisiin. Yritysten välillä tällaiset kumppanuudet ovat kohtuullisen yleisiä, julkisella sektorilla sen sijaan hankintalaki tekee onnistuneen kumppanuuden erittäin vaikeaksi ja riski tulla hyväksikäytetyksi on merkittävä.

Hankintastrategiaa kannattaa harkita huolella

Hankintastrategian valinta ei ole suoraviivainen kysymys. Ratkaisun tekeminen vaatii samaan aikaan riittävää ymmärrystä omista tarpeista ja kyvyistä ja toisaalta markkinoilla tarjolla olevista ratkaisuista. Usein kannattaa aloittaa omien tarpeiden analyysistä ja sen rinnalla selvittää markkinalla tarjolla olevia vaihtoehtoja, jotta voi vertailla niiden sopivuutta omiin tarpeisiin.

Hyvin usein toimintatapa valitaan heti alkuun, eikä vaihtoehtoja sille mietitä oikeastaan missään vaiheessa. Tämä on monen epäonnistuneen hankinnan taustalla. Toinen virhe on ajatella, että aloitetaan vaan hankinta ja antaa markkinan ratkaista, millaisia esityksiä tulee. On kuitenkin käytännössä mahdotonta tehdä tarjouspyyntöä, johon voi vastata yhtä hyvin ketterällä kehitystiimillä kuin valmisjärjestelmällä. Monet keskeisimmät valintakriteerit strategioiden välillä ovat myös organisaation sisäisiä: muutoskyvykkyys, ohjelmistoprojektin hallintaosaaminen, ymmärrys omista prosesseista.

Varsinaista hankintaosaamista on mahdollista ostaa ulkoa, mutta strategista valintaa konsultti ei voi tehdä organisaation puolesta. Siihenkin toki voi hankkia apua, mutta sisäinen panos on merkittävä, koska ymmärryksen mitä ollaan tekemässä ja miksi täytyy syntyä organisaation sisälle.

Yhteenveto

Tässä vielä hankintastrategiasanoma tiivistetysti:

Jos hankintaan ryhtyessä ei tiedetä mitä ollaan hankkimassa ja miksi, hankinta todennäköisesti epäonnistuu.
Hankintastrategian valinnassa käsitellään samaan aikaan tavoitteita, organisaation muutoskyvykkyyksiä ja osaamista sekä markkinoilla olevaa tarjontaa. Mikään näistä irrallaan toisista ei riitä ratkaisuun.
Sellaista strategiaa ei ole, jolla voisi onnistua ilman, että ymmärtää mitä on tekemässä. Oman osaamisen lisääminen on aina osa hanketta.

Teksti on julkaistu alun perin Withmoren blogissa. Withmore auttaa tämäntyypisissä haasteissa mielellään.

Avoin rajapinta

Julkisissa järjestelmähankinnoissa on herätty vaatimaan avoimia rajapintoja, mikä on erittäin hyvä. Avoimet rajapinnat ovat modulaarisen arkkitehtuurin perusasioita, ja yksi keskeinen keino toimittajaloukun välttämisessä.

Mutta aika usein jää epäselväksi, mitä avoimilla rajapinnoilla tarkalleen ottaen tarkoitetaan. Ja siksi niiden hyödytkin saattavat jäädä saamatta. Siksi luonnostelimme Poikolan Antin kanssa määritelmää avoimelle rajapinnalle. Määritelmä on kommentoitavissa tässä, ja keskustelua aiheesta myös täällä ja jatkokehitetty ehdotus täällä. Tarkoitus on tämän pohjalta rakentaa virallinen määritelmä, jota esim Open Knowledge Finland ja Avointen tietojärjestelmien keskus COSS voisivat käyttää. Ja useammassakin kunnassa on myös moista määritelmää kaivattu.

Joten, tässä siis ehdotus kommentoitavaksi.

Spiidnesuolun saari kokonaisheijastuu veden ja ilman välisestä rajapinnasta Bugoynesin edustalla. Kuvan rajapinta ei liity asiaan. Kuva Hannu Oskala

Mikä on avoin rajapinta?

Tämän dokumentin tavoitteena on määritellä selkeästi, mikä on avoin rajapinta. Täsmällistä määrittelyä tarvitaan esimerkiksi julkisissa järjestelmähankinnoissa, joissa usein vaaditaan avoimia rajapintoja. Ilman määritelmää järjestelmätoimittaja saattaa väittää, että järjestelmässä on avoin rajapinta, mutta käytännössä rajapinnan dokumentaation saa vain maksamalla tai se on saatavilla vain muutamille valituille alihankkijoille.

Perusajatuksena rajapinta on avoin, jos kuka vain voi kehittää sitä käyttävän (uuden) sovelluksen. Tähän ei riitä pelkkä dokumentaatio, vaan itse rajapintaan pitää päästä käsiksi, ja sitä vasten pitää pystyä testaamaan sovellustaan. Kehittäminen pitää voida tehdä kysymättä lupaa rajapinnan tekijältä tai haltijalta ja kertomatta etukäteen mitä on tekemässä.

Monilla julkishallinnon organisaatioilla on vahva intressi saada kaikkiin tuleviin tietojärjestelmiin kattavat rajapinnat, joilla tieto saadaan liikkumaan järjestelmien välillä nykyistä joustavammin. Rajapintojen käyttö ei sinänällään ota kantaa siihen, mikä osa tiedoista on julkisia ja mikä osa sisäisiä, mutta niiden avulla tieto on halutessa vaivattomasti saatavissa ulos järjestelmästä.

Rajapinta

Rajapinta (Application programming interface, API) on määritelmä, jonka mukaan eri ohjelmat voivat tehdä pyyntöjä ja vaihtaa tietoja eli keskustella keskenään. Käytännössä tämän dokumentin kannalta mielenkiintoiset rajapinnat ovat usein Internetin yli käytettäviä Web Service-rajapintoja. Samat periaatteet pätevät kuitenkin muunkinlaisiin toteutuksiin.

Rajapinta voi olla pelkkä datarajapinta (esim. kansalaisaloite.fi:n rajapinta) tai toiminnallinen rajapinta (esim. Helsingin Palauteytimen Open311-rajapinta, jonka kautta voi tehdä vikailmoituksia). Jos järjestelmässä on erikseen datarajapinta ja toiminnallinen rajapinta, on syytä täsmentää, minkä kaiken on tarkoitus olla avointa.

Avoin rajapinta

Jotta rajapinnan voi sanoa olevan avoin, sen täytyy täyttä seuraavat ehdot:

1. Dokumentoitu: Rajapinta on määritelty ja sen dokumentaatio on verkon kautta avoimesti saatavilla. Järjestelmän sisältämät tiedot, niiden rakenne ja rajapinnat tulee dokumentoida riittävällä tarkkuudella, jotta rajapinnan käyttöönotto ja hyödyntäminen on vaivatonta.

2. Käyttöönotettava: Avoin rajapinta on mahdollista ottaa käyttöön ilman ylläpitäjän tai järjestelmätoimittajan toimia (myös virka-ajan ulkopuolella). Mahdolliset rekisteröitymiset ym ovat automaattisia.

3. Testattava: Rajapintaa voi koekäyttää, eli tarjolla on vähintään testiaineisto.

Testattavuuden ehto voi täyttyä jollain seuraavista tavoista:

avoin pääsy tuotantojärjestelmään, jota käyttäen palveluun voi integroitua, tai
avoin pääsy testijärjestelmään, jossa on realistista esimerkkidataa, tai
testijärjestelmä on ladattavissa vapaasti omaan käyttöön

Avoimen rajapinnan kautta saatava data on usein avointa, mutta sen ei tarvitse olla avointa dataa. Esimerkiksi potilastietojärjestelmä voi sisältää avoimen rajapinnan, mutta potilastiedot eivät ole avoimia.

Jos järjestelmä tarjoaa avoimen rajapinnan, se ei tarkoita, että tuotantojärjestelmään tai sen sisältämään tietoon pääsisi kuka vain käsiksi. Rajapinta voi olla avoin, vaikka tuotantojärjestelmä olisi kokonaan irti internetistä ja pääsy siihen vain hyvin rajatulla joukolla. Tällöin tarjolla pitää kuitenkin olla jonkinlainen testiympäristö.

Esimerkkejä

Palveluun A on rajapinta tarjolla, ja palvelun toimittaja on sitoutunut tarjoamaan sen asiakkaidensa osoittamille kolmansille osapuolille -> SULJETTU
Palvelun B datarajapintaan pääsee vapaasti käsiksi, mutta toiminnalliseen rajapintaan ei. Rajapinta on julkisesti netissä, ja esimerkkikoodia löytyy googlella -> AVOIN, mutta vain datarajapinnan osalta
Palveluun C on olemassa toiminnallinen rajapinta. Päästäkseen siihen käsiksi täytyy pyytää käyttöavain palvelun tarjoajalta, koska palvelu ei kestäisi vapaan käytön kuormitusta. Käytännössä lupa myönnetään aina. -> SULJETTU Jos palvelusta tarjottaisiin testiversio vapaasti käytettäväksi, se olisi avoin
Palveluun D on rajapinta, jonka määrittelyt ja dokumentaatio ovat vapaasti saatavilla. Itse palveluun ei pääse vapaasti käsiksi, koska se sisältää ihmisten henkilötietoja. Palveluntarjoaja pitää kuitenkin yllä testipalvelinta, jossa on esimerkkidataa, ja testipalvelimeen pääsee käsiksi luomalla itselleen tunnuksen palveluntarjoajan järjestelmään. -> AVOIN

Tilaajan hallitsema rajapinta

Toisinaan avoimella rajapinnalla tarkoitetaan rajapintaa, jota järjestelmän tilaajalla on oikeus käyttää ja levittää haluamallaan tavalla, mutta joka ei välttämättä ole avoimesti kenenkään muun saatavilla. Tällöin kyse ei ole avoimesta rajapinnasta, vaan olisi syytä puhua ennemmin tilaajan hallitsemasta rajapinnasta.

Tilaajan hallitsema rajapinta tarkoittaa siis rajapintaa, jonka järjestelmän tilaaja voi halutessaan avata ilman, että tähän tarvitaan järjestelmän toimittajan lupaa.

Tilaajan hallitsemalla rajapinnalla saavutetaan joitakin avoimen rajapinnan hyödyistä (erityisesti toimittajaloukun välttämäinen), mutta ei niitä kaikkia.

Huomiota ja hyviä käytäntöjä

Sopimusehdot: Tekeillä olevat JIT ehdot määrittelevät, että ostajalla pitää olla mahdollisuus halutessaan avata rajapinta (laittaa dokumentaatio ja testiaineisto verkkoon yms.) ilman, että toimittaja puuttuu siihen. JIT-ehdot eivät kuitenkaan vaadi, että kaikissa julkishallinnon ostamissa ohjelmistoissa rajapinnat olisi pakko avata, vaan tämä jää ostajan harkintaan. Käytännössä ehtoihin siis kirjataan, että rajapinta on tilaajan hallinnassa.

Standardointi: Rajapintojen toteutuksessa kannattaa suosia yleisesti käytettyjä standardeja, protokollia sekä formaatteja. Käytännössä rajapinta voidaan toteuttaa esimerkiksi REST-arkkitehtuurin mukaisesti siten, että sen kautta järjestelmän tiedot saadaan koneluettavana XML-muodossa sekä selainpohjaisia sovelluksia varten JSON-muodossa. Tässä kiteytyksessä ei oteta kantaa harmonisointiin. Harmonisointi on kuitenkin looginen kehityskulku, jotta kaikki avoimet rajapinnat eivät olisi keskenään erilaisia, vaan syntyisi ainakin toimialakohtaisesti yhteisiä käytänteitä. Open311.org on hyvä esimerkki avoimien rajapintojen standardoinnista.

Rajapinnan käyttö ilman rekisteröitymistä: Rajapinnan avoimuus ei velvoita tarjoamaan pääsyä tuotantojärjestelmään tai tuotantodataan vapaasti, vaan sen osalta voidaan vaatia esim. SLA. Jos itse tuotantojärjestelmään ei pääsyä, täytyy tarjota testijärjestelmä avoimesti kehittämistä varten.

Kuormitusrajoitukset: Avoin rajapinta kannattaa toteuttaa siten, että sitä kuormittamalla ei voi (ainakaan vahingossa) aiheuttaa uhkaa tai haittaa tietojärjestelmän muulle käytölle. Eli esimerkiksi rajapinnassa teknisesti rajattu kutsujen määrää per aikayksikkö. Tämä saattaa aiheuttaa tarpeita kahdentaa osia tietojärjestelmästä (vrt. Reittiopas).

Tietoteknistä autonomiaa etsimässä

”Jos ikinä joudumme kybersotaan, on parasta pitää huolta, että olemme Yhdysvaltojen kanssa samalla puolella”, kirjoittaa Otso Kivekäs. Onko todellista tietoturvaa mahdollista rakentaa Suomen tai Euroopan unionin sisällä? Teksti on alkujaan julkaistu Vihreän sivistysliiton Vihreä tuuma -verkkolehdessä.

NSA:n urkintaan liittyvät paljastukset ovat saanet muutkin kuin nörtit kysymään, paljonko meitä oikeastaan vakoillaan. Mitä on mahdollista tehdä tietokoneella ilman, että joku lukee joka sanan? Tietojen leviäminen huolettaa yksityisyysaktivistien lisäksi viranomaisia, joilla on lakisääteinen velvollisuus turvata tietonsa, yrityksiä, joilla on liikesalaisuutensa, sekä tietenkin turvallisuuspalveluita.

Yhdysvaltain lainsäädäntö ja Patriot Act -laki velvoittaa amerikkalaisyritykset luovuttamaan tietoja tiedusteluviranomaisille. Viranomaiset pääsevät käsiksi varsinkin ulkomaalaisten – eli ihmisten enemmistön – tietoihin ilman oikeuden päätöstä, ja perusteet voivat olla esimerkiksi poliittisia. Edward Snowdenin vuotamien asiakirjojen mukaan NSA on tehnyt suoraan yhteistyötä yritysten kanssa esimerkiksi suojausten kiertämiseksi.

Urkinta on pelin henki

Käytännössä tilanne on se, että Yhdysvalloissa tuotettavissa palveluissa – Gmail, Facebook, Dropbox, Google Drive jne. – liikkuva tieto saattaa miltä tahansa osin päätyä turvallisuusviranomaisten käsiin. Koska viranomaisetkin ovat vain ihmisiä, suomalaisten yrityssalaisuudet voivat vaikka päätyä amerikkalaisille kilpailijoille. Myös diplomaattisalaisuudet voivat vuotaa julkisuuteen.

Kuva: marsmet472, Flickr (cc).

Ja kun tällä tiellä jatketaan, onko oikeastaan mitään syytä olettaa, että Windows ei sisältäisi takaportteja, joista NSA pääsee tarvittaessa sisään tutkimaan epäillyn terroristin tiedostot? Tai kenen tahansa muun tietoihin, jotka sattuvat heitä jostain syystä kiinnostamaan. Epäilyksiä moisesta takaportista löytyy.

Vastaavaa verkkotiedustelua harjoittavat toki muutkin maat, kuten Venäjä, Kiina, Ranska ja jopa Ruotsi. Yhdysvallat on kuitenkin erityistapaus, koska sillä on käytännön mahdollisuudet päästä käsiksi valtaosaan maailman tietoliikenteestä ja tiedostoista: amerikkalaisten yritysten hallussa oleviin tietoihin.

Suosituimmat internetpalvelut toimivat Yhdysvalloista käsin. Valtaosa maailman yritysten kriittisistä ohjelmista tulee Amerikasta, kuten todennäköisesti myös Suomen tulevat potilastietojärjestelmät. Toimistotietokoneet ja älypuhelimet toimivat lähes kaikki amerikkalaisilla käyttöjärjestelmillä.

Maailmanlaajuinen verkko

Jos mihinkään amerikkalaiseen ei voi luottaa, niin onko tietoturvaan enää mitään mahdollisuuksia? Olisiko mahdollista rakentaa kotimainen tietotekniikan infrastruktuuri, joka toimisi ilman riskiä ulkomaisesta vakoilusta ja jonka kehitys olisi suomalaisissa käsissä?

Suomen valtion kriittiset palvelut pyörivät nykyäänkin kotimaan kamaralla. Puolustusvoimilla on omat verkkonsa. Tältä osin itsenäinen turvallisuus on suhteellisen helppo saavuttaa, jos luotetaan koneissa pyöriviin amerikkalaisohjelmistoihin.

Kansalaisten verkkopalveluiden tarjonta on sitten jo vaikeampi kysymys. Facebookille ei kotimaista korviketta tule, mutta onnistuisiko edes yrityssovellusten tarjonta? Ei ole kotimaista Google Driveä eikä Skypeä. Saako edes jaettua kalenteria helposti pilvipalveluna?

Ja työpöytäohjelmistojen kohdalla peli on täysin menetetty. Valtavirran käyttöjärjestelmät ovat kaikki amerikkalaisia, kuten se ”ainoa” toimisto-ohjelmistokin.

Jotta voisi kohtuudella luottaa siihen, ettei tietokoneessa ole takaportteja, joutuu käytännössä siirtymään täysin avoimen lähdekoodin ohjelmiin. Se olisi kansallisena strategiana periaatteessa mahdollista. Mutta jos haluamme pitää kiinni jonkinlaisesta valinnanvapaudesta, tämä ei tule tapahtumaan lähiaikoina.

Kriittisimmät valtion ja yritysten järjestelmät voidaan suojata ja perustaa pelkälle avoimelle koodille, mutta muilta osin riippuvaisuus on syvä. Tietotekniikassa olemme peruuttamattomasti ja kiinteästi sidoksissa kansainväliseen verkkoon, ulkomaisiin ohjelmistoihin ja nettipalveluihin.

Jos ikinä joudumme kybersotaan, on parasta pitää huolta, että olemme Yhdysvaltojen kanssa samalla puolella.

Eurooppalainen autonomia?

Mikäli kysymys tietoteknisestä autonomiasta asetetaan koko Euroopan tasolla, vastaus muuttuu.

Suomen tapaan Euroopan unioni ei voi irrottautua verkkoyhteyksistä tai ohjelmistoista, mutta Euroopassa myytäviltä kuluttajapalveluilta voidaan vaatia, ettei tietoja vuodeta alueen ulkopuolelle. Jos kriteeriksi otetaan palvelua pyörittävän yhtiön kotipaikka, Euroopasta löytyy pilvipalveluita, kuten Otto Kekäläinen toisessa artikkelissa esittää.

Käyttöjärjestelmien ja ohjelmistojen osalta tilanne on vaikeampi. Jos jokainen Windows, OS X tai Office on riski, ei muista toimista ole kovin paljoa hyötyä. EU voi kyllä asettaa ehtoja ohjelmistojen myynnille ja vaatia turvaselvityksiä, testejä ja muuta byrokratiaa. Mutta voisiko EU oikeasti kieltää Windowsin tai Mac-tietokoneiden myynnin alueellaan? Teoriassa kyllä, mutta tässä maailmassa jossa elämme epäilen että ei.

Euroopan unionikaan ei nykyisellään ole tietotekniikassa riippumaton, mutta sen autonomiaa voidaan vahvistaa.

Jos halutaan varautua tuleviin yritysvakoiluihin, kauppasotiin ja muihin mahdollisiin skenaarioihin, ei ehkä olisi huono idea vahvistaa eurooppalaista ohjelmistoteollisuutta. Myös Euroopassa kehitettyjen yritys- ja kuluttajapalveluiden tarjontaa tulisi lisätä. Yhteisen teollisuuden syntyä voisi auttaa avoimen lähdekoodin käyttö, kun kehitetyt ratkaisut eivät jäisi totuttuihin kansallisiin kuvioihin, ja yhdessä maassa tehty kehitys poikisi uusia avauksia toisaalla.

Käytännössä vahvempi eurooppalainen teollisuus tarkoittaisi alueellista keskittymistä muutamiin maihin tai kaupunkeihin, samaan tapaan kuin USA:n ohjelmistoteollisuus toimii San Franciscossa, Seattlessa ja New Yorkissa. Mikäli jokainen maassa yritetään ylläpitää erillistä kotimaista ohjelmistoteollisuutta, niistä kukin vuorollaan korvautuu pääosin amerikkalaisilla kilpailijoilla, koska kriittistä massaa ei synny.

Ja ilman omaa vahvaa ohjelmistoteollisuutta ei tietoteknistä autonomiaa ole, eikä siis lopulta tietoturvaakaan. Toinen vaihtoehto onkin hyväksyä nykyinen tilanne.

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:

Miksi tätä ei havaittu aiemmin, ja
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:

Pitää perustetaa Tanskan Medcomia vastaava organisaatio THL:n tai Sosiaali- ja terveysministeriön yhteyteen vastaamaan terveys-IT:n kokonaisarkkitehtuurista.
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.
Jokaiseen IT-hankkeeseen pitää palkata yksi ihminen, joka ymmärtää mitä siinä ollaan tekemässä. Kokemukseni mukaan se parantaa merkittävästi hankkeen onnistumismahdollisuuksia.

Teksti on julkaistu alunperin työpaikkani Codenton blogissa

Toimittajaloukku ja kuinka se vältetään

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

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

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

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

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

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

Mutta tässä ne kolme optiota HUS:lle

Optio 1) sorsat käteen

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

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

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

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

Optio 2) open source

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

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

Optio 3) pilkonta, rajapinnat ja vahva yhteistyö

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

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

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

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

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

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

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

Johtopäätökset

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

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

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

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

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

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

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

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

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

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

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

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

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

Ensin vuorossa menneiden IT-hankkeiden aave.

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

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

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

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

Sitten kuvaan astuu nykyisten IT-hankkeiden aave

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

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

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

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

Ja kerrontavastuu siirtyy nyt tulevien IT-hankkeiden aaveelle

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

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

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

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

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

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

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

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

Ratkaisun avain onkin tilata toisin.

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

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

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

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

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

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

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

11 syytä miksi valtion laitosten kannattaa avata koodinsa

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

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

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

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

Mutta ne argumentit…

A) Virasto hyötyy itse:

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

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

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

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

B) Yhteiskunta kokonaisuudessaan hyötyy:

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

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

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

C. Muut argumentit:

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

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

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

Lopuksi

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

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

My last Nokia

Tänään vietetään kansallista epäonnistumisen päivää. Ostin sen kunniaksi Nokia N9:n.

Se ei ollut rationaalinen valinta. Se oli kunnianosoitus kaikille niille, jotka tekivät työtä Meegon onnistumisen eteen. Epäonnistuitte, mutta työnne ei ollut turhaa.

Rationaalista olisi ollut ostaa jokin android. Esimerkiksi Xperia Ray (Bradbury?). Niissä on tulevaisuus, niissä on Google. Nykyään kun ei oikeastaan osteta puhelinta, vaan pääsy ekosysteemiin, universumilliseen sovelluksia, käyttökohteita ja kulttuurisia merkityksiä. Sitä N9 ei tarjoa.

Kaikki puhelimeni ovat olleet Nokioita. Ensin 5110, sitten 9900i, sitten 6210, 6600, 6680, sekalaisia muita ja E51, joka nyt viimeisimpänä sanoi irti sopimuksensa kahden ja puolen vuoden käytön jälkeen. Olin jo asennoitunut siihen, etten enää osta Nokiaa, vaan niin sanotusti siirryn eteenpäin, johonkin tulevaisuuden puhelimeen.

Mutta tänään vietetään kansallista epäonnistumispäivää. Tänään katsotaan taaksepäin, tutkitaan tehtyjä virheitä niistä oppien, ja valmistaudutaan tuleviin epäonnistumisiin. Ei koira noin vain pääse karvoistaan, vaan vasta kovasti rapsuttaen.

Tähän sopii N9. Tulevaisuuden sijasta se tarjoaa oivan tilaisuuden tarkastella, miten softaprojektit voivat epäonnistua massiivisessa mittakaavassa. Kuinka vuoskymmenen ajan tehty uudistus ei vaan koskaan pääse tapahtumaan.

N9 on se puhelin, joka Nokian olisi pitänyt tehdä vuosia sitten. Julkaisemalla jotain tälläistä vaikka vain kaksi vuotta sitten Nokia olisi pysynyt kisassa älypuhelimista, ja saanut jalansijan käyttöjärjestelmäkisaan. Eikä se ole huono puhelin. Itse asiassa se on oikein hyvä. Se vaan on lajinsa viimeinen.

Tilanne antaa tietysti kaikupohjaa salaliittoteorioille. Itse en antaisi niille paljoa painoa. Nokia teki mitä pystyi; se vaan ei riittänyt. Puhelinkäyttöjärjestelmän tekeminen on oikeasti vaikeaa. Fortune 500 -firman pyörittäminen on todella vaikeaa. Vielä vaikeampaa on korvata käytössä olevaa softaa uudella. 80 miljoonaa puhelinta vuodessa myyvän käyttöjärjestelmän korvaaminen on aivan saatanallisen vaikeaa. Ja ne jotka eivät koskaan yritä muuttua, keittävät edelleen sellua.

Epäonnistumista ei pidä hävetä. Epäonnistuminen on kaiken edistyksen edellytys ja virheistä oppiminen vaatii virheitä. Tieteen kehityskin perustuu sille, että hylätään vääräksi osoittautuneita hypoteeseja. Kauppakorkean pojat ovat tässä ihan oikeassa. Itsekin puhuin taannoin siitä, miten pieleen menee kuitenkin, ja pitäisi vaan osata epäonnistua nopeasti ja murehtimatta, jotta pääsee siitä oppimaan.

Henkilökohtaisesti olen siinä huono. Hankkeet joihin ryhdyn, tuppaavat menemään aivan liian hyvin. Se tarkoittaa, että satsaan aivan liikaa aikaa ja vaivaa asioihin joita teen. Se tarkoittaa, että ryhdyn uusiin asioihin liian varovaisesti, en ota riskejä. Jatkuva onnistuminen on epäonnistumista jo itsessään.

Mutta N9 on varmasti epäonistunut ostos. Kahden vuoden päästä ärsyttää, kun softaa ei päivitetä, vaan siinä on yhä kaikki samat bugit. Uudet sovelluksetkin tulevat Androidille ja iPhonelle, vaan eivät Meegoon. Ehkä opin siitä jotain.

Voidaakseen onnistua, täytyy ensin epäonnistua. Yhä uudelleen ja uudelleen. Ja oppia siitä.

Kaikille, jotka kehittävät Nokian tulevia tuotteita, onnea ja menestystä yhä uusiin epäonnistumisiin. Minun osaltani tämä taisi olla tässä. Tai eihän sitä koskaan tiedä…

Ohjelmassasi on virhe

Johdantona teemaan: Therac 25. Jos olet softa-alalla, kannattaa lukea tuo. Ja ehkä muutoinkin.

Tiivistelmä niille, jotka eivät jaksaneet lukea: lääketieteellisessä hoitolaitteessa oli rinnakkaisuusbugi, jota ei löydetty huolimmatta tiukoista laatustandardeista, jotka vahtivat vääriä asioita. Seurauksena 6 ihmistä kuoli vuosina 85-87 koneen säteilytettyä heitä tappavilla annoksilla. Virheen löytäminen tai edes myöntäminen kesti absurdin kauan.

Tarinan opetus: no, niitä on monia. Laatustandardien ylläpidosta teoreettisen koulutuksen tärkeyteen ja ohjelmistoprosessien merkitykseen. Tällä kertaa kiinnostava on kuitenkin yksi tietty opetus.

Jokaisessa ohjelmassa on bugeja. Ja osa niistä on täysin käsittämättömiä.

Hyvin tehtyjen ohjelmien toiminta näyttää loogiselta ja systemaattiselta. Ohjelman käyttämät metaforat voi ymmärtää, ja sen toimintaa ennakoida. Lisäksi tiedetään, että ohjelman suoritus on tiukan deterministinen prosessi yksinkertaisetn loogisten operaatioiden suoritusta. Seutrauksena onkin helppo kuvitella, että softa olisi loogista myös käyttäytyessään väärin. Se on virhe, pahimmillaan tappava virhe, kuten Therac-25:n kohdalla huomattiin.

Ohjelman pinta on ammattilaisten huolellinen luomus, joka on suunniteltu toimimaan loogisesti ja systemaattisesti. Ohjelman sisäisen toiminnan kanssa sillä on vähän jos juuri mitään tekemistä. Kun ohjelmassa on bugi, se toimii vastoin tekijöidensä suunnitelmia. Tällöin se ei noudata mitään käyttöliittymän vihjaamaa logiikkaa. Softan näennäisen rationaalinen toiminta on rakennettu tyhjän päälle. Se on vuotava abstraktio, ja sen alta ryömii esiin Nyarlathotep.

Ihmiset, ja etenkin luonnontieteen tai tekniikan parissa puuhailevat ihmiset, ovat tottuneet ajattelemaan, että loogiselta vaikuttavan ilmiön taustalla on looginen ja systemaattinen prosessi, jota se ilmentää. Linnut laulavat saadakseen pariutumisseuraa, joet virtaavat alamäkeen ja syöpäriski kasvaa lineaarisesti suhteessa säteilykuormaan, ainakin suurilla annoksilla. Nämä ovat kaikki luonnon ilmiötä, ja luonto on rationaalinen. Softa ei ole, se on ihmisen luoma järjestelmä, jonka näennäisen loogisuuden on ihminen varta vasten (ja suurella vaivalla) rakentanut toisen ihmisen iloksi.

Mikä tahansa softa voi käyttäytyä väärin millä tavalla tahansa. Ja tämä koskee myös kaikkia koneita, jotka sisältävät softaa: puhelimia, GPS:iä, kameroita, autoja, sähkölukkoja… Virheille ei saa olettaa loogista mallia siitä, miten softan pitäisi käyttäytyä.

Virheillä on kyllä logiikkansa, mutta se on eri logiikka. Parhaat testaajat ymmärtävät sen, ja arvaavat siksi, mistä etsiä virheitä. Tuo logiikka ei liity softan tarkoitukseen, vaan sen tekijöihin. Se on inhimillisen lyhytnäköisyyden ja omahyväisyyden logiikka, jonka seuraukset ovat pohjimmiltaan pateettisuudessaan arvattavia. Ja noista ensimmäinen on huonojen ja toinen hyvien koodereiden helmasynti, joten testattavaa kyllä riittää niin kauan kun hyvän ja pahan koodin puu vaan kasvaa inhimillisessä mullassa.

ps. testatkaa se helvetin koodinne. Hommatkaa joku ammattilainen testaamaan se, ei kooderi. Ihan oikeasti, toivoo käyttäjä.

Suoja aika ja IT-ala, sekä tekijänoikeustyöryhmän kuulumisia

En ole hetkeen kirjotellut IPR:stä, joten tässä vähän tekijänoikeustyöryhmän kuulumisia. Maaliskuussa esitettiin kommentteja vihreiden poliittiseen ohjelmaan. Kommentit piti tehdä aika kiireellä, joten lopulta pidettiin vaan ärsyttävä äänestysrumba kaikenlaisista sanamuotonyansseista. Siitä jäi lähinnä paskan maku suuhun, mutta itse ohjelmasta tuli lopulta aika hyvä. Ei mitenkään erityisen spesifi, mutta se ei kai ollut tarkoituskaan. Omaa kynänjälkeäni tunnistan sieltä yhden lauseen: ”Sananvapaus ja yksityisyyden suoja on turvattava kaikille myös Internetissä”, muitakin hiukan tutun oloisia kohtia näkyi kyllä.

Nyt työryhmän varsinainen työ jatkuu taas tavoitteena rakentaa linjapaperi, tällä kertaa vähän paremmalla ajalla kuin tuon ohjelman kommentointi. Tänään olisi kokous, jossa Ville Oksanen (Effi, Turre legal, jne) alustaa tekijänoikeuksien suoja-ajoista. En valitettavasti pääse itse paikalle, joten kirjoitin allaolevan hahmotelman tekijänoikeuksien roolista IT-alalla muille työryhmäläisille, joista enemmistö on tutumpi kulttuurialan kanssa (koen olevani jonkinlaisessa virallisen nörtin roolissa, joten edustan sitten sitä parhaani mukaan). Tässä siis hiukan pohdintaa suoja-ajoista IT-alan näkökulmasta, ja vain siitä.

Tietokoneohjelmat ovat käytännössä aina tekijänoikeuden suojaamia. En tiedä oikeuden päätöksiä teoskynnyksestä, mutta käytännön oletuksena alalla on, että jokainen koodirivi on suojattu. Tekijänoikeuksiin perustuvan ohjelmistobisneksen arvo on Suomessa laskutavasta riippuen puolesta miljardista runsaaseen kahteen miljardiin euroa. Tämä tekee siitä rahassa mitattuna saman kokoluokan alan kuin musiikkiala.

Tekijänoikeuden merkitykseen IT-alalla liittyy muutama erityispiirre, joita koitan avata alla.

Lähes kaikilla mainittavilla ohjelmalla on useita tekijöitä. Pienemmillä ohjelmilla 3-10 hengen tiimi, suurimmilla jopa kymmeniä tuhansia tekijöitä. Lähinnä pienillä harrasteprojekteilla ja oppilastöillä voi olla yksi tekijä. Kaupallisessa tuotannossa tekijöiden nimiä ei yleensä kerrota (poikkeuksena avoimen koodin projektit, s.o. open source). Alan käytäntönä on, että kaikki tekijänoikeudet siirtyvät aina työnantajalle osana työsuhdetta siinä laajuudessa kuin laki vain suinkin sallii. Usein myös yritykset muodostavat alihankintaketjun, niin että tekijänoikeudet siirtyvät saman tien jopa 6 kertaa eri yritykselle sopimusten perusteella.

Tekijän kuolinvuoteen sidottu tekijänoikeuden suoja-aika on IT-alalla ongelmallinen, koska tekijöitä on yllä kuvatun seurauksena yleensä mahdoton selvittää. Teoksen julkaisuhetki sen sijaan on yleensä tiedossa, joten siihen sidottu suoja-aika toimii paremmin.

Toinen IT:n erityispiirre on, että teokset vanhenevat nopeasti, ja niitä päivitetään koko ajan. Vuoden vanha peli on vanha, ja 5 vuotta vanha esihistoriaa. Toimisto-ohjelmatkin vanhenevat viidessä vuodessa, ja sitä vanhempia ohjelmajulkaisuja on hyvin vaikea löytää kuluttajille myynnissä.

Ohjelmien ydin on toki pitkäikäisempi. Esimerkiksi nykyiset windowsit perustuvat Windows NT:hen, joka julkaistiin 1993, mutta ei kukaan enää halua tuota versiota käyttää. Sen jälkeen on tullut 14 uutta pääversiota, ainakin 32 service pack -päivitystä ja satoja ellei tuhansia pieniä korjauspäivityksiä.

Suosituista ohjelmista tuleekin yleensä uusia päivitysversioita muutaman kuukauden tai vuoden välein, ja pieniä korjauspäivityksiä jopa viikottain. Jos ohjelmasta ei tule uusia versioita, se johtuu luultavasti siitä että kukaan ei käytä sitä.

Yli 10 vuotta vanhoja ohjelmajulkaisuja käytetään lähinnä historiaharrastuksena: erityisesti vanhoilla peleillä, mutta myös vanhoilla käyttöjärjestelmillä on omat harrastajansa, jotka rakentavat emulaattoreita ja näkevät suurta vaivaa kyetäkseen edes ajamaan niitä.

Julkisten laitosten ja suurten yritysten tietojärjestelmät ovat toisinaan selvästi vanhempia, mutta niitäkin on varmasti päivitetty ajan myötä, ehkä muutaman vuoden välein. jos jossain on käytössä yli 10 vuotta vanha järjestelmä, jota ei ole päivitetty, se johtuu luultavasti siitä, että päivitystä ei ole saatavilla, koska tekijänoikeudet omistava yhtiö on mennyt nurin tai muutoin lopettanut tuotteen.

IT-alalla siis järkevä suoja-aika olisi selvästi nykyistä lyhyempi. Yli 5 vuotta vanhojen ohjelmajulkaisujen kaupallinen merkitys on hyvin lähellä nollaa, ja esimerkiksi 15 vuoden suoja-aika vastaa käytännössä jo ikuista. Alkuperäiset tekijät eivät juuri koskaan saa tekijänoikeustuloja, vaan heille maksetaan palkan muodossa. Heidän vanhuuden turvaansa suoja-aika vaikuttaa siis vain, jos se tekee ohjelmistobisneksen ylipäätään kannattamattomaksi.

Tiivistetysti:

IT-alalla tekijän kuolemaan sidottu suoja-aika ei toimi.
Suoja-ajan kestona esimerkiksi 15 vuotta ei haittaisi tekijöitä tai teoksiin perustuvaa nykyistä liiketoimintaa käytännössä lainkaan.
Jos erilaisille teoksille harkitaan eri mittaisia suoja-aikoja, tietokoneohjelmille kannattaa harkita lyhyempiä aikoja kuin esim. kulttuurituotteille.

Sivumennen sanoen, se, että esim. Piraattipuolue kannattaa suunnilleen tämän pituisia suoja-aikoja sidottuna juuri teoksen julkaisuun ei liene sattumaa. Heistä useimmille teoksen prototyyppi lienee tietokoneohjelma.