Britanniassa on määritelty tarkat ohjeet, joita kaikkien valtion nettipalveluhankkeiden tulee noudattaa. Ajatus on, että kun kansalaisille tehdään palveluita, heillä on oikeus odottaa jotain perustason toimivuutta ja viranomaisilla velvollisuus se tarjota. Myös USA:ssa on käytössä vastaavat ohjeet.
Suomessa sen sijaan ei toistaiseksi ole kattavia ohjeistuksia julkisten digitaalisten palveluiden suunnitteluun. Koska ainakin Helsingissä sellaisia suunnitellaan, tässä lähtökohdaksi suomennos brittien ohjeistuksesta.
Digital by Default
Tunne käyttäjäsi. Selvitä keitä palvelun käyttäjät ovat ja perehdy heidän tarpeisiinsa. Selvitä, miten tämän pitäisi näkyä digitaalisten palveluiden suunnittelussa.
Perusta pysyvä, monialainen ryhmä, joka vastaa palvelun suunnittelusta, rakentamisesta ja käytöstä. Ryhmän johtajalla tulee olla riittävä asiantuntemus sekä valtuudet päättää palvelun toimintatavasta.
Selvitä, mitä käyttäjien tietoja palvelu tallentaa tai käsittelee ja mitä turvallisuusvaatimuksia tai muita juridisia vaatimuksia ja riskejä tähän liittyy, esim. henkilörekisterisäädöksistä johtuen. Konsultoi tarvittaessa asiantuntijoita.
Arvioi riskit yksityisyydelle ja varmista että henkilötietojen käsittelyä koskevat vaatimukset täyttyvät.
Arvioi, mitä työkaluja ja järjestelmiä tarvitaan palvelun kehittämiseen, ylläpitoon sekä toiminnan mittaamiseen, ja kuinka nämä työkalut ja järjestelmät kannattaa hankkia.
Rakenna palvelu käyttäen ketteriä, iteratiivisia ja käyttäjäkeskeisiä menetelmiä.
Laadi palvelulle laatukriteerit ja -mittarit (kohdat 21–24), joiden mukaan sen toimivuutta arvioidaan.
Analysoi prototyyppipalvelun menestystä. Suunnittele uudet ominaisuudet ja muu jatkokehitys käyttäjiltä saadun palautteen perusteella.
Luo palvelu, joka on niin yksinkertainen ja intuitiivinen, ettei ensikertalainenkaan tarvitse apua sen käyttämisessä.
Tarjoa avustettua sähköistä tukea niille, jotka tarvitsevat apua voidakseen käyttää palvelua
Integroi digitaalinen palvelu ja mahdolliset ei-digitaaliset osat yhdeksi yhtenäiseksi palvelukokemukseksi.
Tee palvelun käyttäjäkokemuksesta, -tyylistä ja ohjeistuksesta yhteensopivia muun julkisen palvelutarjonnan kanssa.
Varmista että sinulla on riittävä kapasiteetti ja tekniset edellytykset palvelun jatkuvaan päivittämiseen ja parantamiseen.
Tee kaikki syntyvä lähdekoodi mahdollisimman uudelleenkäytettäväksi ja julkaise se avoimella lisenssillä (tai perustele vakuuttavasti, miksi jotakin osaa koodista ei voida julkaista).
Käytä avoimia standardeja ja valtion yhteisiä palveluja silloin kun niitä on saatavilla.
Testaa palvelua ympäristössä, joka on identtinen lopullisen käyttöympäristön kanssa. Testaa sitä kaikilla yleisillä selaimilla ja laitteilla. Käytä testitunnuksia ja edustavaa otosta käyttäjistä.
Käytä analytiikkatyökaluja palvelun toiminnan seuraamiseen.
Rakenna palvelua jatkuvasti iteroiden, ja varmista että koko organisaatiolla on siihen tarvittavat edellytykset.
Luo suunnitelma myös käyttöönoton jälkeen jatkuvalle käyttäjätutkimukselle ja käytettävyystestaukselle ja kannusta käyttäjiä antamaan palautetta.
Aseta käyttäjätyytyväisyyden tavoitetaso kaikille palvelun osille erikseen ja seuraa tuloksia systemaattisesti.
Aseta tavoitetaso tehtävien onnistumisasteelle ja seuraa tuloksia systemaattisesti.
Tee (faktojen tukema) suunnitelma saavuttaaksesi matalat yksikkökustannukset ja seuraa tuloksia systemaattisesti.
Tee (faktojen tukema) suunnitelma, jotta mahdollisimman suuri osa kohderyhmästä ottaisi palvelun käyttöön, ja seuraa tuloksia systemaattisesti.
Tee suunnitelmat sen varalle, että palvelu otetaan väliaikaisesti pois käytöstä. Kuinka käyttäjiä palvellaan?
Testaa palvelua kokonaisuudessaan siitä vastaavan ministerin kanssa.
Ohjeet ovat lyhyitä ja selkeitä. Ne eivät määrittele täsmälleen mitä pitää tehdä, mutta ammattitaitoinen verkkopalvelun suunnittelija osaa soveltaa niitä hetken mietittyään googlattuaan omaan tilanteeseensa. Ne ovat sitä, mistä nykyään käytetään sanaa lean.
Tietojärjestelmähankinnat menevät Suomessa yleensä pieleen. Etenkin julkisella sektorilla. Koska olen vuosien varrella useaankertaankertonut miten tietojärjestelmiä ei pidä ostaa ja millaisia virheitä hankinnassa on tehty, koen velvollisuudekseni myös kertoa, miten niitä sitten pitää hankkia.
Tietojärjestelmiä voi julkisella sektorilla ostaa onnistuneesti kolmella tavalla:
Ostamalla palveluna (pilvestä)
Ostamalla valmiin standardituotteen
Teettämällä järjestelmän avoimena
Jos julkiset järjestelmät hankittaisiin näillä tavoin, ongelmia olisi paljon vähemmän.
Perinteisesti tietojärjestelmiä on ostettu niin, että tilaava organisaatio määrittelee (konsultin avulla) mitä tarvitsee, lähettää tästä tarjouspyynnön tarjoajille ja valitsee parhaalta kuulostavan järjestelmän halvimmalla hinnalla. Sen jälkeen seuraa pitkä ja hyvin kallis projekti, jonka myöhästyneen toimituksen jälkeen asiakkaalla on huono järjestelmä, jonka korjailusta ja jatkokehittelystä maksetaan seuraavat kymmenen vuotta, kunnes se päätetään heittää romukoppaan ja palataan toistamaan sama virhe. Useimmat julkiset tietojärjestelmähankinnat on tehty näin.
Se ei ole toimiva tapa. Mutta sen mukaisesti toimitaan, ellei nimenomaisesti pidetä huolta että toimitaan toisin.
Se siitä, takaisin niihin toimiviin tapoihin.
1. Osta palveluna
Ensinnäkin, et oikeasti halua ohjelmistoa. Haluat palvelun, jonka ohjelmisto sinulle tuottaa. Se ohjelmisto on vain tapa tehdä se.
Haluatko extranetin? Ota vaikka Basecamp. Tarvitsetko CRM:ää? Miten olisi SugarCRM? Dokumentinhallintaa? Riittäisikö Google Drive?
Pilvipalvelut eli valmiit online-ratkaisut eivät yleensä ole täsmälleen sitä, mitä sinulla oli mielessä. Mutta vaiva ja kustannus on ehkä tuhannesosa täsmälleen oikeanlaisen järjestelmän hankkimisesta. Kannattaa selvittää, onko sopivia online-tuotteita tarjolla, ja vakavasti miettiä, voitaisiinko toiminta sovittaa toimimaan niillä. Digitalisaation [6] suuret hyödyt tulevat töissä, joissa se yli satakertaistaa tehokkuuden, ja niitä kannattaa hiukan etsiäkin.
Pilvipalvelut sopivat käytettäviksi etenkin tukitoimissa, joissa 1) muillakin lienee suunnilleen samanlaisia tarpeita, ja 2) täsmälleen oikeanlainen toimintatapa ei ole keskeiwtä, vaan voidaan sopeutua siihen mitä palvelu tarjoaa. Koska muuttaahan palvelua ei voi.
Siis esimerkiksi tavanomaisen taloushallinnan tai varastoseurannan ohjelman voi yleensä hankkia palveluna, koska aika lailla samanlaisia tarpeita on muillakin. Laissa tarkkaan määrätyn palvelun toteutusta sen sijaan yleensä ei voi.
Pilvipalveluunkin voi jäädä jonkinlaiseen toimittajaloukkuun. Jos rakennat prosessisi toimimaan nimenomaan vaikkapa Google Driven kanssa, siirtymä siitä toiseen tarjoajaan on ylimääräinen vaiva. Tai palvelu saatetaan lopettaa lyhyelläkin varoitusajalla. Mutta koska kyse oli toiminnoista, joissa asiakkaalla on joustovaraa prosesseissa, tämä ei ole yleensä kovin suuri ongelma.
2. Osta standardituote
Jos jotain ratkaisua ei saa palveluna netistä, sen saattaa silti saada valmiina tuotteena. Tai jos lainsäädäntö ei mahdollista nettipalvelun käyttöä, niin tietojärjestelmän voisi ehkä kuitenkin hankkia valmiina omiin tiloihin.
Tämä on noin kymmenen kertaa työläämpää kuin nettipalvelu, ja ehkä kymmenen tai sata kertaa kalliimpaa. Mutta muutoin kyse on samasta asiasta, ja se siis joskus kannattaa.
Valmis tuote on sellainen, joka on olemassa ja käyttöön otettavissa sinä päivänä kun ostat sen. ”Tuote”, josta näet powerpointin ja toimitus luvataan ensi vuonna, ei ole valmis tuote, vaan myyntipuhe, jonka jäljiltä olet toimittajaloukussa. Se on se perinteinen tapa, jota piti välttää. Jos tuote ei sovi sellaisenaan käyttöön, et ole ostamassa tuotetta. Tai ainakaan pelkästään tuotetta, katso seuraava kohta.
MS Sharepoint on valmis tuote ja Photoshop on valmis tuote. Yksikään Suomessa myyty potilastietojärjestelmä ei ole valmis tuote.
3. Teetä avointa
Jos markkinoilta ei kerta kaikkiaan löydy sellaista järjestelmää jota tarvitset, on se sitten jonkun pakko koodata. Tähän liittyy aina suurin toimittajaloukun riski.
Kun järjestelmä kehitetään yhtä asiakasta varten, asiakkaan siis täytyy maksaa sen kehityskulut. Ja kaikkea koodia täytyy jatkokehittää, mikään järjestelmä ei koskaan ole lopullisesti valmis. Sen jatkokehityksenkin maksaa sama asiakas (sinä), ja siinä vaiheessa jos olet loukussa, sinulla on vain yksi tarjoaja, ja maksat mitä pyydetään.
Toimittajaloukku vältetään sillä, että kaikki koodi on avointa. Tämä on perusperiaate, josta on hyvin harvoin syytä poiketa. Ja yleensä poikettaessa tehdään virhe. Kun koodi on avointa, toimittajaa voidaan vaihtaa tarvittaessa, eikä toimittajaloukkua synny, tai ainakin siitä pääsee pois helpommin.
Koodin avoimuus on lähes välttämätön, mutta ei riittävä ehto kehityshankkeen onnistumiselle. Tässä muutama muu periaate, joita yleensä on syytä noudattaa
Ketterä kehitys, esim Scrum-mallilla.
Kaikki koodi heti avoimena julkiseen repositoryyn (esim: Github, Bitbucket). Siis joka päivä sitä tahtia kun se syntyy
Hyvin dokumentoidut julkiset rajapinnat (usein REST)
Standardien käyttö
Modernit kehitystyökalut
Valmiiden komponenttien käyttö
Prototyypit ja käyttöliittymä edellä työskentely
Vaiheittainen julkaisu ja pilotointi koko ajan käyttäjien kanssa
Modulaarinen arkkitehtuuri ja hankinta osakokonaisuuksina
Kilpailutuksessa arvioidaan osaamista ja toteutustapaa, ei tuotetta
Nämä eri käytännöt tukevat toisiaan, ja ovat tavallaan yhtenäinen paketti modernin ohjelmistokehityksen menetelmiä. Lisää ohjeita käytännön hankintaan muun muassa tässä ja tässä.
Jos järjestelmää pitääkin koodata, se ei missään tapauksessa tarkoita, että kaikkea pitäisi koodata tyhjästä. Päin vastoin, suurin osa siitä mitä tarvitaan, voi löytyä valmiina, ja koodataan vain se mitä ei löydy.
Projektin pohjana toimiva alusta voi olla avointa koodia tai suljettu tuote. Yleensä sen kannattaa olla avointa koodia, koska suljetun tuotteen kanssa on helpompi mokata ja päätyä taas toimittajaloukkuun.
Jos halutaan ostaa valmis järjestelmä ja kehittää sen päälle, siihen on syytä suhtautua kahtena eri hankintana: 1) hankitaan perusjärjestelmä, 2) kilpailutetaan erikseen sen päälle uuden laajennoksen kehitys. Perusjärjestelmän pitää siis tarjota riittävät avoimet rajapinnat, että muutkin kuin sen perusjärjestelmän tekijä tai kumppanit voivat aidosti kilpailla kehitysprojektista. Itse asiassa perusjärjestelmän tekijätaho olisi syytä sulkea ulos toisen projektin tarjoajien joukosta. Samaan tapaan ylläpito ja käyttötuki pitää pystyä kilpailuttamaan erikseen.
Jos järjestelmä ei tähän taivu, sen varaan ei voi jatkokehittää mitään jäämättä toimittajaloukkuun. Täytyy valita jokin muu perusjärjestelmä. Avoimen perusjärjestelmän kanssa tällaisia riskejä ei ole, siksi niitä yleensä kannattaa suosia.
Näillä samoilla periaatteilla järjestelmän voi kasata myös omana työnä, jos palkkalistoilla on siihen pystyviä ihmisiä. Työn määrä ei välttämättä ole kovinkaan suuri, mikäli lähes kaikki tarvittava löytyy valmiina avoimen lähdekoodin ratkaisuina. Jos tarve kehittää tietojärjestelmiä omaan käyttöön on jatkuva, ei välttämättä ole huono idea rakentaa jonkinlainen kyvykkyys siihen omaan organisaatioon.
Suuri osa avoimen koodin kehityksen hyödyistä saavutetaan periaatteessa silläkin, että asiakkaalla on omistusoikeus koodiin. Käytännössä se ei kuitenkaan riitä. Avoimeen koodiin kilpailevat yritykset voivat aidosti tehdä tarjouksia jatkokehityksestä, kun taas koodiin, jonka ne periaatteessa saavat, mutta jota ne eivät näe, on vaikea tarjota. Lisäksi toteuttajayritys pystyy sumuttamaan piilossa olevan koodin kanssa paljon paremmin, miten asiat tehdään. Ja olen nähnyt enemmän kuin yhden hankkeen, jossa asiakas ei lopulta ole ihan varma, mitä oikeuksia koodiin itse asiassa onkaan. Selkeän avoimuuden kanssa näitä ongelmia ei tule
Pakko valita
Hankintatapa on strateginen valinta, joka on pakko tehdä heti hankinnan alussa, ennen kun tarjouspyyntöjä lähdetään edes luonnostelemaan. Epävarmempi ostaja saattaa ajatella, että eikö kannattaisi antaa tarjoajien ratkaista? Että tehdään väljä tarjouspyyntö ja katsotaan millainen ratkaisu voittaa. Valitettavasti se on kuitenkin mahdotonta.
Tämä liittyy ennen kaikkea hankintalakiin, joka vaatii määrittelemään tarkasti hankinnan kohteen ja valintakriteerit. Jokainen hankintatapa vaatii oman, erilaisen tarjouspyyntönsä. Kilpailuun, jonka voi voittaa pilvipalvelulla, ei ole järkeä tarjota koodausprojektia, ja koodausprojektia pyydettäessä pilvipalvelu ei täytä ehtoja.
Jos tarjouksen kriteerit määritellään niin väljiksi, että mikä vaan tapa käy, silloin käy myös tapa, jossa ostaja sidotaan toimittajaloukkuun ja se jää tarjoajan vangiksi. Ja silloin tämä tapa tulee myös valituksi. Toimittaja hyötyy aina asiakkaan sitomisesta toimittajaloukkuun, siitä kannattaa jopa maksaa alihintaisen tarjouksen muodossa. Siksi toimittaja, jonka aie on lypsää asiakasta myöhemmin, voi aina tehdä halvimman tarjouksen. Tarjouspyynnön täytyy nimenomaisesti estää toimittajaloukku.
Julkisessa tietojärjestelmähankinnassa yksi tärkeimpiä tehtäviä on välttää joutuminen toimittajaloukkuun, ainakaan yhtään pahemmin kuin on pakko. Nämä kolme strategiaa ovat suhteellisen tunnettuja keinoja minimoida toimittajaloukku. Ne eivät ole omaa keksintöäni, vaan valtaamassa alaa Suomenkin julkisella sektorilla.
Avoimen ja suljetun lähdekoodin eroja IT-projektissa
Jälkikirjoitus luotetuista kumppaneista
Yksityisillä yrityksillä on käytössään vielä neljäskin hyvä vaihtoehto: kumppanuus luotetun toimittajan kanssa, jonka tuotetta käytetään.
Jos yrityksen oma toimiala ei ole koodaaminen, sen ei yleensä kannata lähteä teettämään koodia itselleen, vaan antaa pätevämpien hoitaa kehitys. Ja vaikka itsekin koodattaisiiin, erikoispalikat tekee tehokkaammin joku joka on niihin erikoistunut.
Kumppanuus toimii niin, että etsitään johonkin tiettyyn asiaan keskittyneistä firmoista se, jonka tyypit tuntuvat luotettavimmilta ja joiden kanssa tulee hyvin juttuun (ja joilla on näyttöä että osaavat työnsä). Jatkossa sitten ostetaan heidän tuotteensa ja pysytään siinä. Ja usein annetaan myyjän kertoa, että mitä oikeastaan kannattaisi ostaa, koska hehän alan parhaiten tuntevat. Ja jos ei yhteistyö suju tai jos alkaa tuntua että myyjä vedättää, lempataan myyjä niskaperseotteella pihalle ja haetaan seuraavaksi paras kilpailija tilalle. Luottamusta joko on tai ei ole.
Julkisella sektorilla tätä ei pidä tehdä. Se menee yleensä pieleen. Jos sidot itsesi yhteen tuotteeseen, sidot itsesi loukkuun.
Hankintalaki kieltää suosimasta yhtä toimittajaa. Julkinen toimija ei siis voi laillisesti luvata luottotoimittajalle, että he saavat jatkossakin projektit. Eikä valita luottotoimittajaansa, jos joku muu onkin tarjouskilpailun kriteereillä parempi.
Tätä voi tietenkin kiertää, ja hyvin yleisesti kierretäänkin. Ehkä kolmannes julkisista softahankinnoista on viritetty tietyn toimittajan voitettaviksi rakentamalla ehtoja, jotka ovat yhdelle toimittajalle mahdollisia ja muille vaikeita tai jopa mahdottomia. Se on tietenkin laitonta, mutta yleistä.
Jos kumppania onnistuukin suosimaan, se ei kuitenkaan riitä. Kun kumppani muuttuu hyvästä rengistä huonoksi vedättäjäksi, siitä pitäisi vielä päästä eroon. Luotettavan kumppanin pitää luotettavana se, että kumppani tietää tulevan bisneksen olevan kiinni luottamuksesta. Jos luottokumppani alkaa vedättää, se on entinen luottokumppani, ja menettää tämän asiakkaan lisäksi muitakin, joille sana leviää.
Hankintalaki kieltää tämänkin. Tarjoajia pitää kohdella tasapuolisesti, eikä huono maine tai yleinen epäluotettavuus ole pätevä peruste syrjinnälle (ja aiemman kokemuksenkin pohjalta se on vaikeaa). Tässä kohti lain kiertäminen on vaikeampaa. Talossa pitkään toiminut ja asiat tunteva kumppani, jonka tuote on tähän asti ollut paras, osaa kyllä tarvittavat asiat, ja tuntee tarpeeksi sisältöä viedäkseen markkinaoikeuteen selvästi itseään syrjivät tarjouskilpailut.
Julkisessa hankinnassa voi siis vähän laittomasti valita itselleen hovitoimittajan, jolta ostaa jatkossakin. Mutta mitään tapaa saada hovitoimittaja toimittamaan laatua jatkossakin ei ole. Tarjoavat yritykset tietenkin yrittävät rakentaa tällaisen ”luottamussuhteen”, mutta siihen suhteeseen ei valitettavasti voi luottaa.
Se, ettei tätä sääntöä ymmärretä, on suurimpia syitä siihen miksi julkiset tietojärjestelmät ovat niin huonoja.
Helsingin kaupungin tietotekniikkaohjelman luonnos on kommentoitavana Otakantaa.fi:ssä tänään viimeistä päivää. Tämä näkökulma ei näy siinä vielä riittävästi.
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.
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.
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.
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ä?
Joku torspo oli sitten mennyt poistamaan uuden ubuntun sound-konffista mahdollisuuden säätää läppäri niin ettei kaiuttimista tule koskaan ääntä, mutta kuulokkeista tulee.
Läppärin kaiuttimillahan ei yleisesti ottaen tee mitään, mutta pienellä tuurilla kuulokkeisiin saa kelvollisen laatuista musiikkia. Ja skype-puheluita. Siksi konffi, jossa kuulokkeisiin kyllä tulee ääntä, mutta kajareista ei koskaan, on ainoa jolle olen keksinyt käyttöä.
Mutta tokihan se on nyt parempi aina erikseen kliksuttaa mute päälle kun irrottaa koneen telakasta (jossa on kuulokkeet) ja taas pois kun haluaa kuunnella musiikkia. Pakko se on, koska ei sekään käy, että joku mainosurpon suunnittelema nettibanneri aloittaa älämölön OnMouseOverista kesken palaverin. Eikä siihen voi luottaa, että jokaisen softan on varmasti saanut konffattua erikseen olemaan hiljaa. Yksin Skypessä on kymmeniä ääniefektejä, jotka pitää kaikki sulkea yksitellen.
Vähän yleistäen tätä ärtymystä, ymmärrän että hyvien käytettävyysratkaisujen keksiminen helppoonkin ongelmaan on aidosti vaikeaa. Jälkikäteen ratkaisu voi tuntua ilmeiseltä, mutta se ei todellakaan ollut sitä etukäteen. Ja joku wysiwyg-editorin tai kalenterisoftan kaltainen monimutkainen systeemi voi olla mahdotonkin tehdä niin ettei siihen jäisi jotain typeryyksiä, kun on pitänyt tehdä kompromisseja eri tarpeiden välillä.
Mutta miten se voi olla niin saatanan vaikeaa osata säilyttää toimivat ratkaisut sen sijaan että yritetään keksiä kaikki tyhjästä uusiksi yhä uudelleen? Näppituntumalla sanoisin että etenkin Gnomelle tuntuu olevan aivan ylivoimaista pitää mitään toimivaa käytössä. Screensaverit, ikkunamanagerit, konffidialogit ja äänienginet tehdään säännöllisesti yhä uudestaan ja uudestaan vähnä eri tavalla yrittämättäkään oppia mitään vanhojen hyvistä ja huonoista puolista.
Oliko Linus sittenkin oikeassa, pitääkö tässä ryhtyä KDE-käyttäjäksi? Ehkä kymmenen vuoden desktop-sodan voisi kohta viheltää loppuneeksi? Yritystoiminnassa Gnomen kyvyttömyys oppia olisi varma indikaattori häämöttävästä tuhosta, mutta vapaa koodi on eri maailma, ja G on toistaiseksi pärjännyt vanhoilla moraalisilla pisteillään. Nykyäänhän KDE:ssä ei edes ole mitään lisenssiongelmaa.
Olin tiistaina taas eduskunnassa, ja Jyrki Kasvi puhui taas. Tällä kertaa kyseessä oli Tieken aamiaistilaisuus ”avoin ja ketterä julkinen hankinta”. Jyrki käsitteli joustavien ja tuottavuutta oikeasti parantavien tietojärjestelmähankkeiden hankaluudesta ja mistä se johtuu. Hänen pääajatuksensa olivat, että pitää miettiä kunnolla etukäteen mitä oikeastaan halutaan, ja lähteä prosessimuutoksista eikä it-järjestelmästä. Keskustelussa myös korostettiin ketterämpää menttelyä, että etukäteen ei voi tietää mitä täsmälleen tarvitsee, ja hankkeet pitää märitellä niin, että korjauksia voidaan tehdä projektin aikana.
Hyviä huomioita, mutta eivät riittäviä parantamaan julkisten it-hankkeiden karmeaa tilaa. On kuitenkin olemassa yksinkertainen (osa)ratkaisu, joka sysäisi liikkeelle kehityksen oikeaan suuntaan. Sitä ei tuotu esiin, enkä itsekään sitä iljennyt sanoa – idea on ehkä hieman liian poliittinen työnantajan nimissä sanottavaksi.
Sanon sen tässä: kaikki julkisten tahojen ostamat ohjelmistot pitäisi lailla pakottaa avoimiksi. Esimerkiksi cc-by-sa-lisenssillä.
Tällä ratkaistaisiin kaksi keskeistä julkisten hankintojen ongelmaa:
Vanhoihin järjestelmiin integroituminen on yleensä raskasta, jopa mahdotonta, koska vanhojen järjestelmien rajapinnat ovat riittämättömiä. Jos vanha järjestemä on avoimesti muokattavissa, sinne voidaan lisätä tarvittavat rajapinnat. Ratkaisu ”tehdään jatkossa riittävät rajapinnat” ei tuo samaa, koska tulevia tarpeita on mahdoton tietää nyt, ja niiden arvailu tulee kalliiksi.
Hankkeissa syntyy yleensä vahva vendor lock in: kun alkuoperäisen hankkeen tekee vaikkapa Tieto, jonka omaisuutta koodi on, ei muutoksia ja jatkotarpeita voi oikeastaan ostaa muualta. Monien IT-talojen ydinosaamista on tämän lock innin rahastaminen siten, että kilpailutukseen tarjotaan ohjelmisto tappiolla, ja voitot rahastetaan sitten muutoksilla.
Lisäksi avoimuudesta syntyisi vahva verkostovaikutus. Jos vaikka PSHT on hankkinut hyvän potilastietojärjestelmän, miksei HUS saisi ottaa sitä käyttöön myös? Miksi heidän pitäisi tuotaa omansa? Tai jos HUS haluaa tehdä omansa, ainakin PSHTltä voisi omaksua rajapinnat ja soveltuvat osat.
Ratkaisu on pakko tehdä lailla, koska muutoin oligopolimaisessa asemassa olevat isot IT-talot voivat kustannusnostoilla pelotella suuren osan ostajista olemaan vaatimatta avoimuutta. Ja ostajat eivät välttämättä ymmärrä, miksi avoimuus hyödyttä heitä, vaikka ensimmäisen oston hinta nousisikin.
Demarisoituna mallina tuosta voisi olla, että kaikki ohjelmakoodi on kaikkien julkisen puolen toimijoiden vapaassa käytössä, ja sitä voidaan luovuttaa alihankkijoille julkisia hankkeita varten (mutta ei muuhun käyttöön). Tällä saataisiin varmasti kohtuullinen osa avoimuuden hyödyistä, eikä se olisi ihan niin pelottavan kuuloista 70-luvun kommunistikammoonsa juuttuneille.
Moraaliselta kannalta voidaa myös kysyä, miksi meidän kaikkien verovaroilla ostettu ohjelmisto ei olisi meidän kaikkien vapaassa käytössä?
Kysyin tuosta ideasta kommenttia Kasvilta tilaisuudne jälkeen, ja kuulema ei riittäisi muuttaa hankintalakia, vaan myös kilpailulainsäädäntöä pitäisi rukata (en tosin aivan tajunnut miksi). Kuulema ongelmana on edes mahdollistaa avoimena koodina tilaamine suljetun rinnalla, saati että sitä suosittaisiin.
Idea ei ole alkujaan omani, vaan jatkojalostin sen Mikon kirjoituksen pohjalta
Hiukan kärjistäen designia voi tehdä kahdella tavalla.
Stefan Lindfors suunnittelee meille tuotteen ylivertaisten designerinlahjojensa avulla, huomioiden toki teollisen valmistuksen rajoitteet, tuotteen käyttöön liittyvät tutkimukset ja varmaan taiteen uusimmat trenditkin. Huippudesigneri on toki hyvä tuyössään, ja jos ei olisi, joku muu brändätty designeri korvaisi hänet nopeasti.
No-name designer tai joukko heitä hahmottelee tuotteet sellaisiksi mitä itse haluaisi käyttää. Mikä luultavasti siis tarkoittaa suurelta osin sellaista mihin ovat tottuneet. Näin toimii Ikea.
Kummassakin menetelmässä on huonot puolensa.
Stefanin bravuuri on tietenkin dildo joka ei värise tyydyttävästi. Ehkä Steffe ei tunkenut prototyyppiä perseeseensä, tai kenties hänen mieltymyksensä poikkesivat naisista joille dildo kuitenkin lähinnä suunnattiin. Designerin täytyy kyetä ymmärtämään käyttäjien tarpeita jotka poikkeavat hänen omistaan, mikä on kallista ammattitaitoa, ja parhaimmillaankin voi aina mennä pieleen.
Ikean kalusteet taas yleisesti ovat käytettävyydeltään parempia kuin kilpailijoiden kalliimmat vastineet, mutta poikkeus on tiskikaappi, jonka hyllyt ovat liian pieniä ja typerän mallisia (sanon yhden keittiön rakennettuani ihan omakohtaisesta kokemuksesta). Koska ruotsalaiset eivät käytä tiskikaappeja, design-tiimiltä on puuttunut se intuitiivinen omakohtainen näkemys jonka varassa ikea-design lepää. Parempaa olisi tullut kopioimalla orjallisesti mitä tahansa suomalaista valmistajaa.
Ruotsalaisen huonekalufirman lisäksi ikea-designiin prustuu myös avoin ohjelmistokehitys. Avoimessa kehityksessä ei yleensä ole minkäänlaisia formaaleja suunnitelmia, vaan kooderit kirjoittavat softaa oman, mitä ilmeisimmin ilmeisimmin jaetun, intuitionsa varassa. Kun softaa kehitetään etenkin omia tarpeita silmällä pitäen, on selvästikin mahdollista luoda yhteinen näkemys siitä mitä ja miten softan olisi syytä tehdä niin, että tuo näkemys riittää korvaamaan kirjoitetut suunnitelmat.
Rajoitus onkin sitten että malli toimii huonosti, jos softaa ei kehitetä omaan käyttöön, tai jos ei ole kaikille yhteistä vertailukohtaa. Siksi suuri osa varsinkin isommista avoimista projekteista keskittyy korvaamaan tai kopioimaan jo olemassa olevia suljettuja järjestelmiä. Merkittävät käytettävyysinnovaatiot tulevat yleensä ensin johonkin suljettuun tuotteeseen, josta ne sitten kopioidaan avoimiin versioihin.
– Nimeni on Rappaport Digby, ja te kuuntelette ’Lasten tiedetuntia’. Tänään aiheenamme on avoin koodi ja sen historiallinen väistämättömyys.
Kuulitte oikein, sanoin avoin koodi, enkä vapaa. Nyt on nimittäin niin, että pitkällä aikajänteellä, kun extrapoloidaan tilannetta yli vaihtelevien juridisten järjestelmien, avoimuus on vapauden sekä välttämätön että riittävä ehto. Jos koodi on fyysisesti saatavilla, sen käyttö on ennemmin tai myöhemmin myös juridisesti sallittua. Siksi päivän aiheen osalta olennaista on nimenomaan koodin avoimuus.
Mutta nyt päästän ääneen Brentin, joka kertoo meille avoimen koodin historiasta ja sen merkityksestä Queng Holle
– Kiitos Rappaport. Avoimen koodin esihistoria ei ole kovin hyvin tunnettua, mutta se on lähtöisin jo vanhasta maasta. Ilmeisesti ensimmäisillä tähtialuksilla käytettiin vielä ei-kriittisissä sovelluksissa myös suljettuja järjestelmiä, mutta Queng Hon syntyyn mennessä kaikken aluksille huolittavan koodin avoimuudesta oli tullut ehdoton vaatimus, muu olisi yksinkertaisesti liian suuri riski.
Kun Pham Nuwen muokkasi satojen vuosien takaista paikallistajien koodia valovuosien päässä lähimmältä ihmisten asuttamalta planeetalta, kuinka hän olisi tehnyt sen, jos lähdekoodi ei olisi ollut mukana paikallistajissa? Yleisemminkin, varustettaessa avaruusalusta tähtien väliselle lennolle, mikään muu vaihtoehto kuin kaiken koodin ottaminen mukaan avoimessa muodossa ei ole mahdollinen.
Avaruuslento on tietenkin äärimmäinen esimerkki, mutta sama ilmiö, että avoimuus on yksinkertaisesti tehokkaampaa kuin suljetut järjestelmät esiintyy planeetoillakin. Suljetun järjestelmän toimittaja voi lopettaa toimintansa, tai kieltäytyä juuri siitä laajennoksesta jota käyttäjä tarvitsee. Ja vaikka kaikki onnistuisi täydellisesti, muutosten ja uuden käytön neuvotteluista tulee aina ylimääräistä kitkaa.
Tietenkin suljettujen järjestelmien varaan rakennettu talous tuottaa kaupallisia intensiivejä, jotka edistävät softan tuotantoa, mutta tämän tuomat hyödyt taloudelle häviävät suljettuuden haitoille jo verrattain pienissä järjestelmissä.
Tuon avoimuuden rajan approksimaation kaava on pohjimmiltaan melko yksinkertainen, perustuen käyttäjämäärään,muutostahtiin, käyttöönoton transaktiohintaan,muutospyynnön transaktiohintaan ja…
