Valtio päästää liian helpolla: vaalijärjestelmä

Olin vaalilautakunnan 47D puheenjohta EU-vaaleissa. Vaalilautakuntamme osallistui sähköisen äänestysluettelon testaukseen. Järjestelmä on sama kuin ennakkoäänestyksessä käytetty. Järjestelmän avulla vaalivirkailija tarkistaa onko äänestäjällä äänioikeus. Jos äänioikeus on, virkailija kirjaa äänen annetuksi. Järjestelmällä voi myös tarkistaa missä äänestyspaikassa kunkin äänestäjän sopii äänestää. Lisäksi järjestelmä pitää kirjaa äänestäneiden määrästä.

Meidän lautakunnassamme järjestelmä oli koekäytössä, ja sitä käyttivät lautakunnasta riippumattomat henkilöt. Mikäli järjestelmä olisi kaatunut, se ei olisi vaikuttanut äänestykseen mitenkään. Onneksi.

Järjestelmä toimi hyvin: äänestäjät kirjautuivat lähes oikein. Järjestelmän mukaan äänestäjiä oli yhteensä 672. Uurnasta löytyi 673 äänestyslippua. Äänestysluettelon mukaan äänestäneitä oli 673. Sähköinen järjestelmä oli siis lähes yhtä tarkka kuin manuaalinen.

Järjetelmässä oli kuitenkin muutamia kummallisuuksia. Ensinnäkin, järjestelmän käynnistäminen kestää noin 15 minuuttia. Osasyynä tähän oli luonnollisesti Windows, joka nyt vaan on hidas. Windowsin lisäksi käynnistämistä hidastivat ilmeisen epämääräiset ohjeet ja eri tavoin tallessa olevat tunnukset: tarvittiin puhelimessa tekstiviestinä olevia salasanoja, paperilla olevia ja vielä pankkitunnuksia. Järjestelmän käyttäjille oli epäselvää mihin mikäkin salasana oli tarkoitus syöttää. Vasta sitten ja juuri ennen vaalihuoneiston avautumista järjestelmät käynnistyivät. Tietoturvasta en uskaltaisi käynnistyshässäkän jälkeen panna päätäni tai edes palkkaani pantiksi.

Järjestelmän käyttöliittymä on kummallinen. Vaalivirkailijan pitää syöttää äänestäjän henkilötunnus käsin kenttään, jossa kirjainten koko on alle sentti. Sen jälkeen hänen on klikattava hiirellä pienen pientä nappulaa ruudun alareunassa (siis noin 10 senttiä syöttöruutua alempana), minkä jälkeen ruudulle ilmestyvät äänestäjän tiedot noin kahden sentin fontilla. Taas on klikattava hiirellä ja vielä kerran varmuuden vuoksi.

Käyttöliittymä on siis sekä vanhanaikainen (viivakoodintunnistusta ei ole) että käyttökelvoton (fontit ovat niin pieniä, ettei keski-ikäinen virkailija voi käyttää järjestelmää – vaikka ruudusta 80% on tyhjää!).  Lisäksi on merkillistä, miksi ainoaa mahdollista nappulaa pitää klikkailla hiirellä: miksi enter ei riitä.

Miksi valtio päästää toimittajansa näin helpolla? Miksi valtio totuttaa toimittajansa huonoille tavoille: aivan kuin käyttöliittymä- ja käytettävyyssuunnittelu ja -testaus eivät olisi olleet osa tilausta ja toimittaja niin vailla ammattiylpeyttä, että on ne jättänyt tekemättä?

Miten Suomesta voi ikinä tulla virallisten strategioiden mukaisesti johtava IT-maa, jos tämmöistä huonoa suunnittelua ja toteutusta pääsee läpi niinkin tärkeässä asiassa kuin vaaleissa?

Ai niin: järjestelmä ei muuten tiedä reaaliaikaisesti äänestäneiden määrää. Äänestyksen jälkeen kesti noin 5 minuuttia ennen kuin järjestelmä pääsi tilanteen tasalle ja näytti lukua 672. Sitä ennen puuttui muutamia. Mistähän moinen viive?

Edit: mitä ilmeisimmin järjestelmä tukee viikakoodin lukijaa. Jostain syystä lukijat eivät olleet Helsingissä käytössä. Vantaalla olivat.

Vanhaa ei voi korvata uudella

Tuomioistuinten IT-järjestelmien  uudistus meni mönkään. Uusi järjestelmä on hitaampi kuin vanha. Uudella ei pysty hoitamaan monimutkaisia rikosvyyhtejä. Käyttäjät eivät osaa käyttää uutta. Virheitä syntyy ja roistot kulkevat vapaalla jalalla.

Vuosi pari sitten VR:n lippujärjestelmien uudistus epäonnistui samaan tapaaan. Uusi järjestelmä oli hidas, toimi virheellisesti ja sitä oli vaikea käyttää. Sittemmin järjestelmä on saatu korjatuksi, mutta sitä on yhä vaikea käyttää. Autorekisterikeskuksen järjestelmien kanssa oli taannoin samanlaisia ongelmia. Myös tulli on kärsinyt järjestelmiensä uudistamisesta merkittävästi.

Vanhan järjestelmän korvaaminen uudella vaikuttaa olevan vaikeaa ja virhealtista. Syitä uudistusten epäonnistumiseen ovat ainakin seuraavat.

Ensinnäkin, vanhojen järjestelmien toiminnallisuudet eivät ole täysin tiedossa. Järjestelmät ovat pitkäikäisiä. Kun järjestelmä on ollut käytössä 10 vuotta, siihen on väistämättä tehty lukemattomia muutoksia. Muutoksista harvemmin on dokumentaatiota. On vaikeaa korvata vanhaa uudella, kun ei tiedä millainen vanha tarkalleen on. Järjestelmä on elänyt ja muuttunut poliittisen prosessin mukana; usein järjestelmän täytyy toteuttaa nykyinen laki ja osa entisestäkin.

Toiseksi, järjestelmään kuuluvat myös käyttäjät ja heidän toimintatapansa. Usein käyttäjät käyttävät vanhan järjestelmän puutteita paikatakseen erilaisia apujärjestelmiä. Yleisin näistä järjestelmistä lienee MS Excel. Mikäli näitä apujärjestelmiä ei oteta huomioon järjestelmää korvatessa, osa järjestelmästä jaa uusimatta. Tai toisin sanoen: työprosessi on yleensä laajempi kuin korvattava tietojärjestelmiä. Työprosessin selvittäminen on hyvin vaikeaa, koska se vaatii järjetelmän käytön pitkäaikaista havainnointia. Lisäksi puutteellisen järjestelmän luoman työprosessin uudelleenluominen on turhaa.

Kolmanneksi, vanhat järjestelmät on yleensä toteutettu olettaen, että käyttäjä korjaa järjestelmän virheet. Osa vaatimuksista – eli lakien ja asetusten määräyksistä – on ristiriitaisia keskenään tai vähintäänkin tulkinnanvaraisia. Siksi järjestelmät eivät edes pyri olemaan täydellisiä, vaan odottavat käyttäjien – virkamiesten – korjaavan virheet. Virheellisen järjestelmän toteuttaminen uudelleen on vaikeampaa kuin virheettömän.

Neljänneksi, teknologia muuttuu. Kymmenen vuotta vanha järjestelmä perustuu yli 10 vuotta vanhaan teknologiaan. Karttakäyttöliittymän sijaan käytössä on todennäköisesti lomakkeisto. Automaattisten rajapintojen sijaan on käytössä kuukausittaiset perustietoeräajot. Käyttäjien keskinäinen yhteistyö on hankalaa; samaa dokumenttia ei voi käsitellä kuin yksi käyttäjä kerrallaan. Tämänkaltaisten vanhojen teknologioiden toteuttaminen uudestaan ei ole mielekästä.

Viidenneksi, sekä järjestelmän käyttäjien että loppukäyttäjien (asiakkaiden) tietotekniset valmiudet ovat muuttuneet ja muuttuvat jatkossakin. Yhä suurempi osa tehtävistä on mahdollista antaa loppukäyttäjien (asiakkaiden) tehtäväksi ja näin välttää tietojen kopiointia, virheitä ja ylimääräistä työtä. Loppukäyttäjät myös tietävät, että teknologia on muuttunut, eivätkä suostu käyttämään vanhentunutta teknologiaa, vaikka se olisikin kiedottu uuden järjestelmän valekaapuun.

Mikä siis neuvoksi?

Vanhan korvaaminen uudella ei siis ole hyvä ajatus. Mikäli vanha toimii, käytettäköön sitä. Jos vanhan järjestelmän alustana olevat teknologiat ovat katoamassa, vanhan korvaaminen uudella kannattaa tehdä paloittain. Teknologioiden katoaminen on hyvin harvinaista eikä koskaan tule yllättäen. Siksi vanhaa ei juuri koskaan ole tarvetta korvata päistikkaa uudella.

Mikäli vanhasta on pakko päästä eroon, tehtäköön uusi järjestelmä alusta alkaen uudestaan. Järjestelmien tekemisessä käytettäköön mahdollisimman moderneja teknologioita ja työvälineitä. Varmistettakoon, että järjestelmää on jatkossa mahdollista laajentaa vielä uusien teknologioiden kypsyessä. Pidettäköön huoli uuden toteuttamisen ketteryydestä ja lopputuloksen avoimuudesta. Avointa järjestelmää on jatkossa helpompaa ylläpitää eikä sitä tarvitse koskaan korvata kertarysäyksellä uudellla.

Mikäli uuden tekeminen vaikuttaa mahdottomalta liiallisen monimutkaisuuden vuoksi, yksinkertaistettakoon lakeja, säädöksiä ja muita järjestelmään kohdistuvia vaatimuksia. Vanhaa sanontaa mukaillaksemme:

mikä on liian monimutkaista ollakseen tietojärjestelmä, ei voi olla lakikaan.

JHS-179 ja arvo

 Olettakaamme, että tehtävänämme on suunnitella uusi tietojärjestelmä. Järjestelmän omistaja – tai rakennuttaja – on jokin Suomen valtion ministeriö tai virasto. Mitä meidän pitäisi tehdä aivan ensiksi? Virallinen vastaus on, että meidän pitäisi etsiä käsiimme kyseisen ministeriön tai viraston kokonaisarkkitehtuurikuvaus. Kuvaus auttaa meitä alkuu ja ohjaa hellästi loppuun asti. Emme voi epäonnistua. Hienoa.

Kokonaisarkkitehtuurikuvaukset on määräysten mukaan kirjoitettava – tai oikeammin kokonaisarkkitehtuuri on suunniteltava – JHS-179 -suosituksen mukaan. Tutkikaamme pikaisesti miten hyvin JHS-179:n mukainen kuvaus auttaisi meitä työssämme.

Taannoin opiskelin järjestelmäarkkitehtuuria MIT:ssä. Opin, että mitä tahansa järjestelmää suunniteltaessa on aivan ensiksi selvitettävä kenelle järjestelmä tuottaa arvoa ja miten. Vasta kun on selvää, että järjestelmä tuottaa arvoa ja että arvoa saavilla on kykyä maksaa arvosta, voi järjestelmän suunnittelu varsinaisesti alkaa.

Mitä arvo sitten on? Mikä on arvon määritelmä? MIT:n yksinkertainen vastaus

arvo = hyöty – kustannus (1)

Yhtälöä ei pidä ottaa liian kirjaimellisesti. Hyöty ja kustannus voivat olla eri tyyppisiä, niiden ei välttämättä tarvitse olla rahassa suoraan mitattavissa. Joka tapauksessa ennen suunnitteluun ryhtymistä on selvitettävä, ketkä uudesta järjestelmästä hyötyvät ja millaisia kustannuksia heille hyödyn saamisesta syntyy. Usein kyseessä on arvoketju, jossa arvo liikkuu eri henkilöiden välillä.  Arvon saajia voi olla myös useita. Jos järjestelmä ei luo arvoa kaikille osapuolille, järjestelmää ei kannata rakentaa.

Ottakaamme esimerkiksi Ollilan työryhmän esittämä satelliittiperustainen liikennehinnoittelu. Valtion kannalta arvon määrittely on helppoa: mikäli järjestelmä tuottaa enemmän kuin sen rakentamiseen ja ylläpitämiseen menee, järjestelmä tuottaa arvoa ja järjestelmä kannattaa rakentaa.

Autoilijan kannalta tilanne on toinen. Autoilija joutuu maksamaan enemmän tai tuntuvammin (joka kerran ajaessaan versus kerran vuodessa). Autoilijan saama hyöty sen sijaan on olematon. Järjestelmä ei tuota autoilijalle mitään hyötyä. Ihmekös, että autoilijat vastustavat järjestelmää. Jos autoilijoista on kiinni, järjestelmä epäonnistuu.

Takaisin JHS-179:n pariin. Mitä se sanoo arvosta? EI yhtään mitään. Ohje ei kerro edes tämän bloggauksen vertaa arvosta. Aika arvoton ohje!

Avoimuutta ja pitkää ikää

Penn Stationilla New Yorkissa vuonna 2009 havahduin kuulutukseen. Ymmärsin vasta kuulutuksen lopussa, että jossakin oli ikivanha järjestelmä, joka oli nyt tarkoitus vaihtaa uuteen. Onneksi kuulutus toistui muutaman minuutin välein, ja lopulta ymmärsin tarinan.

Kyseessä oli Long Islandin ratapihan vuonna 1935 käyttöönotettu asetinlaite. Se toimi yhä moitteettomasti, mutta releiden saatavuus oli käynyt huonoksi. Asetinlaitteen huoltaminen oli jo pitkään ollut vaikeaa ja vähitellen se olisi mahdotonta. Laite oli uusittava, mikä pysäyttäisi junaliikenteen ratapihalla muutamaksi päiväksi. Uusi asetinlaite – eli siis tietokone – olisi myös entistä fiksumpi ja lisäisi Long Islandin ratapihan kapasiteettia.

Asetinlaite

Vuoden 1935 asetinlaite oli hallinnut ratapihan liikennettä jo 74 vuoden ajan. Tekniselle laitteeelle 74 vuotta on kunnioitettavan korkea ikä. Kukaan laitteen suunnitelleista ja rakentaneista tuskin oli enää elossa. Dokumentaatiokin saattoi olla hukassa. Tämä ei kuitenkaan ollut estänyt laitteen huoltamista, koska mekaanisten laitteiden ymmärtäminen on melko helppoa. Mekaaniset laitteet ovat tavallaan avoimia; kuka tahansa tekniikan perusteet ymmärtävä ymmärtää laitteet ja osaa niitä huoltaa ja korjata.

Nykyisin täysin mekaanisia järjestelmiä on tuskin lainkaan. Liki kaikki järjestelmät sisältävät tietotekniikkaa. On oikeastaan turhaa enää sanoa jonkin järjestelmän olevan sulautettu järjestelmä, koska kaikki ovat. Mikään triviaalia monimutkaisempi järjestelmä ei toimi ilman sähköä eikä ilman jonkun ohjelmoimaa logiikkaa.

Tietoteknisiä järjestelmiä on hankala huoltaa ja korjata, jos niiden suunnittelijat ja toteuttajat ovat manan mailla, dokumentaatiota ei ole eikä lähdekoodia ole saatavilla. Prosessorin sisään on vaikeata nähdä ja siellä mahdollisesti piileskelevää bugia – joka on ehkäpä aktivoitunut toimintaympäristön muutoksesta – ei saa millään pois. Kun järjestelmä hajoaa tai ei enää sovi yhteen vaatimusten ja toimintaympäristön kanssa, tilanne on vaikea: järjestelmä on korvattava kiireesti uudella. Kiire on aina kallista.

Aina asiat eivät ole näin huonosti. Järjestelmän toteuttajat ovat yhä elossa, heillä on lähdekoodi hallussaan ja osaamisensa on yhä niin hyvä, että järjestelmää on mahdollista kehittää ja vikoja korjata. Järjestelmää ei tarvitse vaihtaa kiireesti. Ongelmat eivät katoa vaan muuttavat muotoaan. Ongelmat eivät olekaan teknisiä vaan kaupallisia: osaaminen on vain yhdellä porukalla – järjestelmän alun alkaen rakentaneella -, joten heillä on monopoli ja hinnat sen mukaiset. Kalliiksi käy ylläpitäminen, korjaamisesta puhumattakaan.

Ikääntyvän tietoteknisen järjestelmän ylläpitäminen kallistuu jatkuvasti, jos järjestelmän rakenne ja lähdekoodi ovat suljettuja. Mitä vanhempi suljettu järjestelmä, sitä monopolisoituneempaa sen ylläpito ja korjaaminen on. Järjestelmän omistaja – ja käyttäjät eli maksajat – kärsivät, ylläpitäjät rikastuvat.

Mitä voimme oppia Long Islandin asetinlaitteesta? Yksinkertaisen ohjeen: jos järjestelmä on varmasti lyhytikäinen, se voi olla suljettu. Jos taas järjestelmä saattaa jäädä elämään vuosikymmeniksi, sen lähdekoodin, suunnitteludokumentaation ja toteutustyökalujen on oltava avoimia.