VR otti käyttöön uuden lipunmyyntijärjestelmänsä vaiheittain keskiviikon 14.9. ja perjantain 16.9. välillä. Nettikauppa lakkasi toimimasta heti keskiviikkona, eikä ole alkanut toimia kunnolla tähän mennessä. Sunnuntaina oli pieniä häiriöitä muussakin lipunmyynnissä. Lippuautomaatit tippuivat pelistä maanantaina, ja pian niiden perässä myös asemien lipunmyynti.
VR on tietysti tullut viime aikoina tunnetuksi kyvyttömyydestään liikennöidä junia, joten sikäli tämä ei yllättänyt ketään. Tällä kertaa syypää ei kuitenkaan ole yksin junayhtiö, joka ei saa junia liikkeelle, vaan myös ohjelmistoyhtiöt, jotka eivät saa ohjelmistoja toimimaan: parivaljakko Tieto ja Accenture.
Ongelmana on näet VR:n uusi tietojärjestelmä. Verkkokauppa, asemajärjestelmä ja automaatit käyttävät samaa taustajärjestelmää. Ja taustajärjestelmää ei ilmeisesti oltu tehty kestämään tätä käyttöä. Uudet lipputyypit ja integroinnit lisäsivät kuormaa: ”Emme osanneet ennakoida tällaista. Meillä oli 20-kertainen kysyntäpiikki normaaliin verrattuna” kommentoi hankkeen vastaava. Alalla toimivat lukijat ymmärtävät varmasti, että uudistukset aiheuttavat piikkejä, ja niiden suuruutta on mahdollista arvioida. On aivan normaali käytäntö varautua merkittäviin kysyntäpiikkeihin järjestelmäuudistuksissa, varsinkin jos käyttömalli muuttuu, kuten tässä tapahtui.
Tämä ei ole mitenkään ainutkertaista. Etenkin Tieto on surullisen kuuluisa suurista ohjelmistohankkeista, jotka menevät täysin penkin alle. On kyse sitten eduskunnan äänestysjärjestelmästä, Oulun päiväkotijärjestelmästä, yhteishausta tai ajoneuvorekisteristä.
Eikä tässä nyt ole kyse vain Tiedosta. Samanlaisia kauhutarinoita löytää muidenkin suurten IT-talojen toimittamista projekteista. Taas eilen kuului paljon ideoita, kuinka voitaisiin säätää laki, ettei niiltä saa ostaa mitään, koskaan, ikinä. Vaikka tulisi EU:lta sakot. Tai ehkä moista tuhoa tekevät organisaatiot voisi kieltää EU:n terroristijärjestösäädösten perusteella?
Eiväthän tälläiset fantastiset ehdotukset tietenkään ratkaisisi ongelmaa, vaikka olisivat mahdollisiakin, mitä ne eivät ole. Jos maan kymmenen suurinta IT-toimittajaa lakkaisivat tänään olemasta, olisi meillä muutamassa vuodessa tilalla uudet aivan samanlaiset. Ongelma ei ole yksittäisen yrittyksen huonous tai pahuus, se on syvemmällä.
Asian ydin on tässä Ari Järvelän (Tieto) lausumassa ”VR:n tietojärjestelmä on arkkitehtuuriltaan hyvin monimutkainen järjestelmäkokonaisuus.”
Lippujärjestelmä ei toki ole mikään javakurssin harjoitustyö. Siinä on useammanlaisia lippuja, useita eri tapoja ostaa niitä, ja junavuorojakin on 1200 joka päivä. Junamatkoja tehdään 44 miljoonaa vuodessa, eli ehkä 150 000 arkipäivänä. Ei tätä koodaa iltapäivässä.
Vertailun vuoksi: yksi yhteistyökumppani rakensi lippuvarausjärjestelmän, jolla voi ostaa kaikki maailmassa myytävät elokuvaliput, 230 miljoonaa lippua kuussa. Ihan vaan demotakseen fancy-fancy-bling-bling-ui-systeemiään. Kai sitä joku viikon pari koodasi, satakertaista kapasiteettia. Toki paljon yksinkertaisempaa ratkaisua, ei yhtä monimutkaista kuin VR:llä.
Mutta juuri siitähän tässä on kyse: yksinkertaisista ratkaisuista. Ei VR:n lipunmyynnin olisi mikään pakko olla arkkitehtuuriltaan hyvin monimutkainen. Näin alan ammattilaisena voin sanoa, että jos haluaa toimivaa, systeemistä kannattaa sen sijaan tehdä melko yksinkertainen, ja hyväksyä monimutkaisuutta vain se minimimäärä, joka on ihan pakko. Ei tässä olla mitään ydinvoimalaa tekemässä, vaan ihan tavallista lipunmyyntijärjestelmää.
Yksinkertaisemmat arkkitehtuurit, joissa voidaan asioita muuttaa pala kerrallaan, ratkaisisivat monta ongelmaa. Itse asiassa juuri siihen VR:nkin uudistuksessakin pyrittiin. 15 miljoonaa euroa ja yksi katastrofaalinen käyttöönotto myöhemmin voidaan todeta, että jokin meni vikaan. Se jokin ei ole tekniikkaa. Jokaisen teknisen ongelman takana on aina organisatorinen ongelma, josta johtuu, ettei teknistä ongelmaa ole ratkaistu.
Eli miksi VR:n lipunmyyntijärjestelmä on arkkitehtuuriltaan hyvin monimutkainen? Miksi sen koodaaminen on jättiläishanke, johon tarvitaan toista sataa työntekijää? Miksei sitä tehty pienempänä, helpommin ja pala kerrallaan?
Vastauksia on tietenkin monenlaisia, ja jokaisella virheellä on ainutkertainen historiansa. Tälläisessä löysäranteisessa tarkastelussa riittänee todeta: on sekä myyjän että ostajan intressissä, että hanke on suuri ja monimutkainen.
Ohjelmistohankkeet tehdään monessa vaiheessa alkaen alustavasta määrittelystä, määrittelyn ja erilaisten suunnittelujen kautta toteutukseen. Samat IT-talot tekevät kaikkia vaiheita, ja kilpailevat sitten itse määrittelemiensä järjestelmien toteutusprojekteista.
Jos ohjelmistohankkeeseen tarvitaan 200 henkeä, Suomesta löytyy noin kaksi IT-taloa, jotka voivat sen toimittaa. Aivan, Tieto ja Accenture. Sata henkeä saisi penkkiä lämmittämään jo muutama muukin yritys, ja 20 vaikka kuinka moni. Suuren IT-talon konsultin kannattaa tietenkin määritellä järjestelmä, jonka lähinnä oma talo voi toteuttaa.
Ostajan kannalta – ja puhun nyt ihmisestä, en organisaatiosta – suuri hanke on tietenkin suurempi. Ajatelkaa katumaastureita, kyllä sillä koolla on väliä. Ja jos hankkeita pilkkoo, joutuu koordinoimaan eri projekteja, kun ”kokonaistoimituksen” ongelmia voi aina turvallisesti olla havaitsematta. Sitäpaitsi vakiotoimittajalt ostaminen on turvallista. Kukaan ei ole saanut potkuja siksi, että osti Tiedolta. Jos pikkufirma mokaa, vika on ostajan joka luotti siihen, mutta jotunnettu toimittaja mokaa, niin eihän se voi olla ostajan vika.
 |
| Hyvän ja pahan tiedon puu |
Taisin lupailla jotain ratkaisujakin. Otsikko on vihje: lisää tietoa.
Nimittäin avointa tietoa. Kaikki julkisten tahojen tilaamat ohjelmat pitäisi julkaista avoimen koodin lisenssillä. Avaaminen helpottaisi pienempien yritysten mahdollisuutta osallistua tarjouskilpailuihin, kun omien rahkeiden riittävyyttä voisi tutkia etukäteen. Avaaminen helpottaisi järjestelmien integraatiota, kun rikkinäisen rajapinnan voisi korjata tai ainakin ymmärtää sen toimintaa. Ja avaaminen poistaisi vendor-lock-inneistä suurimman osan.
Kaiken julkisen koodin avaaminen toisi vähitelleen kustannussäästöjä, kun asioita ei tarvitsisi tehdä uudestaan niin monta kertaa, ja kun yritykset uskaltaisivat tarjota projekteja halvemmalla. Vielä merkittävämpi potentiaalinen hyöty tulisi epäsuorasti, jos ja kun ohjelmien laatu alkaisi pikkuhiljaa parantua.
Ja kun yksikään julkinen taho ei tee ohjelmistobisnestä, eivät oikein tehdyt ohjelmat voi sisältää liikesalaisuuksia tai mitään niihin verratavaa salattavaa tietoa. Merkittäviä haittoja ei siis ole.
Monimutkaisuuden ongelmaa avoimuus ei suoraan ratkaisisi. Mutta se olisi osa kulttuurista muutosta kohti parempia ohjelmistoja, pois tästä murheen laaksosta, jossa tavoite on vain saada paljon perseitä tuoleja lämmittämään, ei mitään valmista.
Itse asiassa koodin avaaminenhan on vain virallisten dokumenttien julkisuuden looginen laajennos. Ei mitään radikaalia, ei mitään vallankumouksellista. Paitsi että avaaminen parantaisi radikaalisti julkisia ohjelmistohankintoja. Parhaat ratkaisut ovat yksinkertaisia.
Kirjoittaja on töissä yrityksessä, joka hyötyisi merkittävästi, jos Tiedolta ja Accenturelta ostettaisiin vähemmän softahankkeita sekä kansalainen valtiossa, joka hyötyisi merkittävästi, jos Tiedolta ja Accenturelta ostettaisiin vähemmän softahankkeita.
