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

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.

Kuinka suomalainen tietoyhteiskunta korjataan?

Perustimme blogin Hyvä renki, joka käsittelee suomalaista tietoyhteiskuntaa, sen ongelmia ja keinoja miten sen voisi korjata. Alla blogiin kirjoittamani avauspostaus. Alkuperäinen julkaisu tässä.

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

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

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

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

Rengit viettävät pihalla hyvin ansaittua lepohetkeään Eero Järnfeltin maalauksessa.

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

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

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

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

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

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

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

Pyydämme, että:

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

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

Mitä lääkkeeksi eReseptille?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Teksti on julkaistu alunperin työpaikkani Codenton blogissa

Avoin data ja miten sillä mitataan ratikoiden luotettavuutta

News at eleven: Helsinki palkkasi kooderin.  ”Avoimen datan ammattilainen Juha Yrjölä pestattiin töihin uudenlaiseksi it-asiantuntijaksi. Hän katsoo Helsingin tietojärjestelmiä tiedonjanoisen kaupunkilaisen silmin.” sanoo tiedote. Kyse on Code for Europe hankkeen yhdestä sivujuonteesta.

Tapasin Yrjölän maanantaina. Hänen missionsa on avata julkishallinnon datoja, luoda niiden päälle kevyitä sovelluksia kaupunkilaisten ja virkamiesten hyödyksi ja innostaa muitakin samaan. OIkein kannatettavaa, ja kaikki tuki projektiin.

Varsinaisesti puhuimme kunnan päätöksentekojärjestelmän (Ahjo) avaamisesta. Palaan siihen myöhemmin, koska juuri nyt kiinnostavampi on Juhan ja kollegansa Tuukan suunnitteilla oleva tilastolliseen analyysiin perustuva reittiopas ja sitä sivuten HSL:n datat.

Kaupunginkooderit saivat näet reittiopastaan varten HSL:ltä datapaketin, jossa on bussien ja ratikoiden kaikki pysähtymiset pysäkeillä alku ja loppuaikoineen. Tarkoitus on työstää dataa, tilastoja ja applikaatioita perjantaina alkavassa OKF Conventionissa Tuusulassa.

OKF Convention on suomalaisen avoimen datan yhteisön kokoontuminen, jossa sata nörttiä, tilastotieteilijää, visualisoijaa ja ties ketä kokoontuu osoittamaan, mitä avoimella datalla voi tehdä. Ja yksi noista dataseteistä on siis joukkoliikenteen matka-aikoja.

Sillä datalla voi tehdä paljon muutakin kuin reittioppaan. Sillä voi vaikka seurata joukkoliikenteen luotettavuutta.

Nykyään luotettavuutta mitataan sillä, mikä osuus vuoroista jää lähtemättä päätepysäkeiltä, tai myöhästyy yli vuorovälin verran (tai yli 15min). Siis jos bussi lähtee päättäriltä 14min myöhässä ja juuttuu heti ruuhkaan, se on tilaston mukaan edelleen ajoissa. Sekä HSL että HKL ovatkin ymmärrettävästi kiinnostuneita paremmista metriikoista.

Tässä seistessä lohduttaakin, että bussi kyllä lähti päättäriltä ajoissa
Tässä seistessä lohduttaakin, että bussi kyllä lähti päättäriltä ajoissa

Vaan mikä olisi hyvä metriikka joukkoliikenteen (bussien ja ratikoiden) luotettavuudelle? Sitä voi nyt ehdotella. Juha lupaili, että jos ehdotan jotain metriikkaa, perjantaina, joku tilastoscriptaukseen tottunut saattaa sen hyvinkin toteuttaa. Sitten sen voisi järjestä ensin kokeiluun HKL:ssä/HSL:ssä ja ehkä myöhemmin sopimusten osaksikin.

Spesifisti siis kysyn mittaria jolla arvioida yksittäisen linjan, joukon linjoja tai koko joukkoliikennejärjestelmän luotettavuutta.

Hyvä metriikka on 1) eksakti, 2) mittaa oikeaa asiaa ja 3) on kommunikoitavissa helposti. Tässä pari hahmotelmaa:

  • Ehdotus 1) Ajallaan lähtöjen osuus kaikilla pysäkeillä, eli niiden pysäkiltälähtöjen osuus, jotka ovat korkeintaan minuutin ennen aikataulua ja korkeintaan kolme minuuttia aikataulun jälkeen.
  • Ehdotus 1b) Sama kuin edellinen, mutta suhteessa pysäkiltälähtöajan tilastolliseen odotusarvoon eikä aikatauluun.
  • Ehdotus 2) vaihdon luotettavuus pysäkkikohtaisesti: Se osuus liikennevälineistä, joka lähtee tarkoitetussa järjestyksessä. Ideana, että kaksi minuuttia myöhässä saapuminen ei haittaa, jos ratikka johon on vaihtamassa on myös samat kaksi minuuttia myöhässä. Tarkoitettu järjestys saadaan aikatauluista.

Muita ideoita?

Espoo, Epic ja Apotti

Tilanne nyt, 30.1.2013:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It-hankintaprojekti sairastaa

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

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

Debattikirjoituksemme Kauppalehdessä 24.9.2012

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

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

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

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

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

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

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

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

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

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

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

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

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

Otso Kivekäs, asiantuntija, Codento

Petri Aukia, toimitusjohtaja, Codento

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

Joka tietoa lisää

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

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

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

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

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

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

Asian ydin on tässä Ari Järvelän (Tieto) lausumassaVR: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.

KIITOS 1997-2011

Tänään, kuultuani Stephen Elopin strategiajulkistuksen, olin pettynyt. Kuten varmasti kaikki muutkin suomen IT-insinöörit. Nokia oli meidät pettänyt. Pettänyt ne ylimitoitetut ja messiaaniset odotukset, joita koko 90-luvun nousukauden luoma sukupolveni oli siihen ladannut.

Kaikkihan tiedämme mitä käy Microsoftin kumppaneille. Ja Osakkeenomistajatkin tietävät, mikä arvo on yhtiöllä, joka ei hallitse ekosysteemiä, vaan ainoastaan tuottaa rautaa. Useimmat meistä uskoivat Meegoon, ja jotkut uiskoivat Symbianiinkin. Kaikki tuo usko tulevaan vedettiin tänään vessasta alas.

En kuitenkaan reagoinut riipasemalla kunnon kännejä, vaan vetäydyin pohtimaan tilannetta Nokian entisen johdon kanssa. Klassisen sikaripöydän ääressä, jäistä Pohjoissatamaa katsellessa totesimme, ettei nyt kannata ripotella tuhkaa päälleen tai polttaa barikkaadeja, vaan todeta tilanne ja katsoa eteenpäin.

Tietty jakso Suomen historiassa on nyt päättynyt. Siinä oli paljon hyvää, mutta sen oli aika viimein loppua.

Global domination

Älypuhelinten, tablettien, tietokoneiden, sovelluskauppojen ja sensellaisten uusilla (konvergoituneilla) markkinoilla asian ytimessä on hallinta. Ekosysteemin hallinta ja kuluttajien hallinta. Nokian vahvuus on aina ollut tehokas elektroniikan tuotanto ja myynti. Se on ihan eri peli.

Uutta kenttää hallitsevat Apple ja Google, haastajana Microsoft. Elektroniikkafirmalla joka yritti muuttua softafirmaksi ja sitten palvelufirmaksi eivät enää riittäneet rahkeet. Ei pystynyt, liian hapokasta. Viiden miljardin R&D-budjettia ei ylläpidetä pelkillä laitemyynnin madaltuvilla katteilla. Eikä omaa platformia ja tuotekauppaa kehitetä halvalla, ainakaan halvaantuneessa organisaatiossa jossa asiat juuttuvat sisäiseen politikointiin.

Jotain radikaalia pitää siis tehdä, etsiä uusia liittoja.

Apple ei Nokiaa halua. Steve ei ylipäänsä tee kenenkään kanssa yhteistyötä, se ei olisi stevemäistä.

Google taas on liian vahva. Nokia olisi sille vain yet another rautavalmistaja. Google on palvelufirma, joka ei tule koskaan sitoutumaan rautaan. Ja rautaahan Nokia on. Erityisasemaa ei olisi luvassa. Android-puhelinten tekeminen voisi olla ihan kannattavaa pikkubisnestä, mutta pientä, ja ylpeys ei anna myöten. Pakko olla vielä asiaa isoihin pöytiin.

Jäljelle jää Redmond. Siellä osataan solmia strategisia kumppanuuksia. Microsoftin kumppaneille käy toki aina huonosti, mutta se ei haittaa, jos olet itse Microsoft. Looginen lopputulos on, että Microsoft ostaa lopulta koko Nokian mobiilidivisioonakseen. Se on myös ainoa selitys, jonka kautta Elopin strategiassa on Nokian, eli sen omistajien, kannalta jotain järkeä. Jos kauppa tapahtuu vaikka hintaan 10€/osake, se on parasta mitä yrityksestä nyt voi enää saada.

Tämä on arvaus, mutta oikea semmoinen. 2012 loppuun mennessä Nokia julkistaa fuusion Microsoftiin; ehkä jo tänä vuonna.

Suomi ilman Nokiaa

Kyllähän kaikki ymmärrämme, ettei Suomen hyvinvointi voi pitkän päälle perustua siihen, että kiinalaiset tehdasduunarit ja intialaiset insinöörit ahertavat kolmessa vuorossa sen eteen, että juuri me saisimme särvintä leivälle. Se on korkeintaan tuulen tuoma hetken voitto – pitkän päälle työt täytyy tehdä itse.

Ja itse tekemiseen meillä on samat resurssit tänään kuin eilenkin. Jos Nokia irtisanoo tuhansia, se tarkoittaa tuhansia, jotka etsivät uusia tapoja olla hyödyksi. Nokian tähän maahan käytännössä luoma vahva IT-vientisektori pelasti meidät liian yksipuoliselta raskaalta teollisuudelta. Nyt on aika irtautua yhteen yhtiöön nojaavasta taloudesta. Suomen etu ei enää tarkoita samaa kuin minkään tietyn yhtiön etu, eikä lakeja enää säädetä Keilaniemessä.

Suo, kuokka ja kooderi

Suomen muutama tuhat Meego-kehittäjää vapautuu nyt muihin tehtäviin. Siinä joukossa on valtava määrä lahjakkaita ihmisiä, jotka kyllä löytävät itselleen paljon tekemistä. Luultavasti ensimmäinen täällä suunniteltu Android-puhelin julkaistaan vielä tänä vuonna. Ja sillä platformilla on tulevaisuutta. Saattaa myös olla, että turhan krääsänmyynti-orientoitunut IT-alamme alkaa avautua enemmän myös teknologian hyödyntämisen suuntaan. Siinä kun olemme toistaiseksi takapajula.

Myös Symbian-kooderien elämänlaatu paranee. Voin sanoa kokemuksesta, että kun siitä kerran päästää irti, ei kyllä tule ikävä. Kansan brutto-onnellisuus epäilemättä kasvaa.

Kiitos 1997 – 2011

Muistakaamme siis Nokiaa, joka kehitti helppokäyttöisiä kännyköitä jo 90-luvulla. Yritystä, joka toi samaan kuvaan Neuvostoliiton ja maailman ensimmäisen kännykkäpuhelun. Käsittämätöntä talousihmettä, joka pelasti meidän lamasta ja metsäteollisuuden banaanitasavallan ikeestä. Noita vuosia, jolloin IT-insinööri oli kansallinen sankari ja joka toisen nuoren toiveammatti. Kohottakaamme malja Nokialle, joka paransi kehitysmaiden köyhien elämää enemmän, kuin kaikki maailman kehitysapu yhteenlaskettuna.

Kaikesta siitä muusta sen sijaan ei nyt sanota mitään, sillä vainajista ei sovi puhua pahaa. Nyt ei ole aikaa vanhoille kaunoille, nyt on aika rakentaa uusi Suomi.

Paita saatavissa täältä

Hihittävät nörtit

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

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

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

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

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

  1. Ongelmat ostamisessa. Osa ongelmista johtuu direktiiveistä ja hankintalaista, mutta lähinnä kyse on osaamisen puutteesta. Projektien ja järjestelmien ostaminen on aidosti vaikeaa, varsinkin kun siihen liittyy sekavia säädöksiä ja raskas organisaatio, jossa on paljon intressitahoja. Kun ostoja tekeviä instansseja on sadoittain, ja jokainen ostaa isoja järjestelmiä harvoin, on selvää, että useimpiin niistä ei mitenkään voi kertyä riittävää osaamista.
  2. Joukko palveluntarjoajia on oppinut hyödyntämään tätä osaamattomuutta ja säädösten kiemuraisuutta. Ei nyt mennä nimiin, mutta niitä on sekä isoja että pieniä. Alalla on kuvionsa, miten myyjä vedättää prosessia: vendor lock-in on niistä vain yksi, tosin ehkä merkittävin.

    Vedättämisen tekee myyjä, ei nörtti. Se kuuluu myyjän ammattitaitoon, eikä liity IT-alaan sinänsä mitenkään. Osataan sitä muillakin aloilla.

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

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

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