Hyvää jatkoa, toivottaa renki

Hyvä renki -blogin toiminta on päättynyt. Kiitokset kaikille osallistuneille.

Toiminta paremman tietoyhteiskunnan infrastruktuurin puolesta ei sen sijaan ole loppunut. Päin vastoin, näiden kahden vuoden aikana moni julkinen hanke on ottanut parempaa suuntaa ja julkinen keskustelu asiasta on ainakin lisääntynyt selvästi. Pikemminkin on niin, että tämä blogi yksittäisenä kanavana on jäänyt yleisen muutoksen jalkoihin ja turhaksi. Ja on myös niin, ettei tänne ole tullut kirjoitettua niin paljon kuin oli suunnitelmana.

Siksi siis hyvää joulua, hyvää jatkoa ja tavataan taas.

toivottaa,
Hyvä renki

ps. saman aihepiirin keskustelua löytyy ainakin

• Codenton blogista
• Otson blogista

Julkisten hankintojen todellinen ongelma

Moni yritys kokee kuntien hankintojen kohdistuvan suuriin toimittajiin, ja hankintojen nähdään painottavan hintaa laadun kustannuksella. Perttu Ahvenainen kirjoittaa Digitalist Networkin blogissa osuvasti kuntien hankinnoista ja nykyisen hankintamallin puuttuvasta dynaamisuudesta. Pertun artikkelin taustalla on erinomainen  Soile Kuitusen ja Ville Valovirran Hesarin pääkirjoitus samasta aiheesta. Julkishallinnon hankintatoimen haukkuminen on pop myös sosiaalisessa mediassa.

Mistä julkisten hankintojen kitka sitten oikein johtuu?

Vastaus löytyy historiasta. Julkishallinnon hankinnat olivat pitkään lähes yksinomaan suorittavan portaan hankintoja. Julkishallinnossa suunniteltiin, ja yksityiseltä puolelta hankittiin materiaalit toteutukseen, ehkä myös työmiehet.

Tällaisia hankintoja kutsutaan usein suoriksi hankinnoiksi, hankinnnan kohde tuottaa suoraan jotain, jolla on arvoa. (Julkishallinnon ilmaus suorahankinta viittaa toki aivan eri suoruuteen, joka on  tulevan blogipostauksen aihe.)

Yli- vai alilaatua?

Asiansa osaavissa yksiköissä suorien hankintojen laadulle on selvät kriteerit. Vielä tarkemmin sahattu koolinki ei taloa rakennettaessa ole kenenkään etu, kunhan ollaan mittatarkkuuden rajoissa. Tärkeää on löytää halvin luotettava toimittaja kunkin bulkkituotteen kategoriasta sillä kertaa. Usein tämä toimittaja on suuri ja toiminut alalla pitkään. Ylilaatu voi olla jopa pahasta, sillä jos siihen totutaan, ei kilpailutus jatkossa ehkä olisikaan mahdollista.

Reklamointi on julkisella puolella työlästä ja toimittajan vaihtaminen kesken projektin lähes mahdotonta. Ei lainsäädännön, vaan totuttujen tapojen vuoksi. Tavaksi on helposti tullut valita sellainen kumppani, jonka kanssa voidaan varmasti neuvotella, jos ongelmia syntyy. Usein tämä on ainakin se suuri, tuttu, entinen valtion tai kuntien omistama yritys.

Pienet digitaalistet yritykset tekevät hankkeita, jotka ovat epäsuoria hankintoja asiakkailleen. Työn tuloksena voi olla vaikkapa arkkitehtuurisuunnitelmia tai esimerkiksi uudet verkkosivut virastolle.  Suorien hankintojen parhaat käytännöt sopivat huonosti epäsuoriin hankintoihin, mikä yllättää kokeneet suorien hankintojen tekijät.

Ostajat hakevat samalla laatua ja halvempaa hankintahintaa, kuten Baswaren hankintatutkimus 2013 osoittaa.

Erinomaisesti suunniteltu koulu on vielä parempi kuin hyvin suunniteltu koulu ja keskinkertaisesti suunniteltu tietojärjestelmä voi olla hukkainvestointi hyvin suunniteltuun verrattuna. Epäsuorissa hankinnoissa on harvoin ylilaatua. Halvimmalla tehty suunnitelma harvoin tuottaa halvimman ja parhaan lopputuloksen. Epäsuorien hankintojen laatu vaikuttaa helposti hankintahintaa paljon suurempiin rahavirtoihin.

Kannattaako korkeammasta laadusta maksaa?

Hankintalaki ei sinänsä estä epäsuorien hankintojen laillista toteuttamista, mutta laillinen laadukas hankinta edellyttää viitseliäisyyttä. Parhaan valitsemisesta laillisesti on tehty ostajalle vaikeaa.  Hyvä hankintatoimi on osa hyvää johtamista. Jos johtaminen ei muutenkaan ole lapasessa, ei epäsuorissa hankinnoissa voida onnistua.

Hinnan ja laadun ymmärtäminen, riittävän hyvän valitseminen, mutta ei hinnalla millä hyvänsä, on epäsuorien hankintojen ydin. Julkisessa hankinnassa pitää luoda hankintakehikko siitä, kuinka paljon enemmän ollaan valmiita maksamaan keskinkertaista paremmasta laadusta. Ei mikään helppo homma.

Näin merkittävän hankintamuutoksen läpivienti on vaikeaa missä tahansa organisaatiossa, ja julkishallinnossa erityisesti. Itsenäisiä ostajia on julkishallinnossa tuhansia, ilman yksityiseltä puolelta tuttua konserniohjausta.

Kyse on loppujen lopuksi yksinkertaisista asioista. Tärkeää on ymmärtää millainen hankinta on kyseessä ja millaisin hankintaehdoin saavutetaan haluttu lopputulos. Helppoa periaatteessa, vaikeaa arjen kiireessä kokemattomalle.

Halvimman määrämuotoisen tuotteen ostajalle laadun arviointi on pelottavaa, työlästä ja uutta. Ilman onnistunutta laadun arviointia epäsuoran hankinnan voittaa paras toimittaja vain sattumalta, jos silloinkaan.

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.

Kuinka kansallinen palveluväylä tulisi tehdä

Kansallinen palveluväylä on ehkä merkittävin IT-projekti tällä hetkellä Suomessa, Apottiakin tärkeämpi. Se on luonteeltaan ristiriitainen: toisaalta siinä pyritään uudistamaan koko se tapa, jolla julkisia tietojärjestelmiä Suomessa tehdään. Toisaalta siinä saatetaan vain kaataa 120 miljoonaa sille jolla on syvimmät taskut. Ratkaisut hankkeen ja ehkä koko suomalaisen IT-palvelualan suunnasta tehdään lähikuukausina.

Kun olen seuraillut projektia vuoden verran melko läheltä, koen että minun täytyy kertoa mistä siinä nähdäkseni on kyse, ja mitä sille pitäisi tehdä.

Optimistin tarina

Tekniikkana palveluväylä on itse asiassa suhteellisen yksinkertaista: sovittu toimintatapa ja sovitut rajapinnat siihen, miten toisiin järjestelmiin otetaan yhteyttä. Yhteinen tapa tunnistaa käyttäjät ja tapa selvittää järjestelmien osoitteet. Useimmilla isoilla yrityksillä on jonkinlainen palveluväylä, mutta se on vain osalla pakollista perusinfraa, vähän kuin serverihallit tai nettikaapelointi. Se ei sinänsä ole mitään kauhean ihmeellistä, vaikka toki tarpeellista.

Kansallinen palveluväylä ei ratkaise järjestelmien yhteentoimintaa eikä sinänsä tuo kovin dramaattisia säästöjä. Suurin osa palveluväylään kohdistetuista odotuksista onkin täysin ylimitoitettuja, jos ajatellaan pelkkää väylää.

Mutta kyse on enemmästä kuin vain tietojärjestelmästä. Palveluväylähankkeen – tai kansallinen palveluarkkitehtuurin, kuten sitä nyttemmin kutsutaan – tavoitteena on mullistaa tapa, jolla suomalaisia tietojärjestelmiä tehdään. Hallituksen rakennepoliittisessa ohjelmassa marraskuussa kirjattiin:

”Toteutetaan viipymättä kansallinen sähköinen palveluväylä ja sähköinen tunnistautuminen kustannustehokkaasti sekä Viron yhteistyömahdollisuudet täysimääräisesti hyödyntäen.”

Kremlologian parhaiden perinteiden mukaisesti ”viipymättä” ja ”kustannustehokkaasti” tarkoittavat tässä, että hanke tehdään ketterästi eikä perinteisenä julkishallinnon mammuttiprojektina. ”Viron yhteistyömahdollisuudet täysimääräisesti hyödyntäen” taas tarkoittaa avointa lähdekoodia. Voisihan sen sanoa paljon selvemminkin, mutta ei ole ollut tapana.

Rakennepaketin perustelumuistiossa (s. 71) asiaa selitetään lisää.

”Palveluväylä mahdollistaa tiedon välityksen organisaatioiden välillä yhdenmukaisesti sovituilla tavoilla (yhtenäiset tiedon kuvaukset, rajapintakuvaukset ja standardit) perustuen avoimiin rajapintoihin ja keskeisten osien osalta avoimeen lähdekoodiin. […]

Yhteentoimivuuden lisäksi Palveluarkkitehtuuri luo aiempaa paremmat liiketoimintaedellytykset yrityksille ja erityisesti PK-sektorille, sillä uusi toimintamalli ja avoimet rajapinnat parantavat niiden edellytyksiä osallistua julkisiin ICT-hankintoihin sekä mahdollisuuksia luoda uusia innovatiivisia palveluja julkista tietoa hyödyntäen.”

Tarkoitus on siis toteuttaa suuri julkinen softahanke kevyesti ja nopeasti ja siirtyä integraatioissa käytäntöön, jossa ne tehdään helposti ja toimivat sen sijaan, että niitä jarrutellaan ja rahastetaan niiden avulla toimittajaloukkua. Samalla avataan kaikki mahdollinen data ja rajapinnat ja siirrytään malliin, jossa strategiset julkiset tietojärjestelmät ovat avointa koodia, jotta niitä voidaan hyödyntää tehokkaammin.

Ja tämä toimivien tietojärjestelmien kulttuuri on tietenkin tarkoitus laajentaa koskemaan julkista sektoria yleisestikin – kuten on tehty Virossa. Rakennepaketissa ennakoidaan tästä saatavan kansantalouden tasolla puolen miljardin vuotuiset hyödyt. Siis 500 000 000 euroa joka vuosi.

Tässä vaiheessa varmaan ymmärrätte, miksi olen innoissani hankkeesta. Tässä yritetään tehdä monia niistä asioista, joista olen puhunut viime vuosina. Toisaalta tämä ei ole ainoa totuus hankkeesta, sillä on myös synkempi puoli.

Viron palveluarkkitehtuurin yleisarkkitehtuuri. Keskellä on väylä (X-Road), joka yhdistää tietojärjestelmiä. Tämän tarkkuuden kaaviosta ei tietenkään näe, mitä oikeasti tehdään.

Pessimistin tarina

Taloussanomat kertoi tammikuussa, kuinka palveluarkkitehtuurihanke on ”120 miljoonan euron ontto kuori” ja rahojen käytölle ei ole olemassa suunnitelmaa. IT-hankkeiden tunnettu kriitikko, Professori Tomi Voutilainen taas epäilee, että siitä on tulossa teknologiavetoinen uudistus, jossa unohdetaan loppukäyttäjien tarpeet. Valitun teknologiankin järkevyyttä kyseenalaistetaan, eikä luvattujen puolen miljardin hyötyjen toteutumisesta ole vielä mitään näyttöä.

Vastaavia tietojärjestelmien yhteentoimivuuteen tähtääviä hankkeitahan on tehty Suomessa ennenkin, ks esim. Julkishallinnon perustietovarantojen rajapinnat (PERA)  tai Valtion yhteinen integraatiopalvelu (VIA). Molemmissa on varmasti tehty paljon sinänsä tarpeellista työtä, mutta kumpikaan ei ole ratkaissut yhteentoimivuuden ongelmia, vaan integraatio on edelleen ihan yhtä jähmeää.

Epäilyksille on siis perusteita. Isoissa julkisissa IT-hankkeissa yleensä päädytään tekemään raskas mammutti, myöhässä ja yli budjetin, tuottaen samalla toimittajaloukku, joka hidastaa kehitystä ja maksaa jatkossakin. Pitäisi olla vahvat perustelut, miksi tällä kertaa kävisi eri tavalla.

Koodin avoimuus hankkeessa on myös hiukan epäselvää. Sitran Mirjami Laitinen sanoi Sitran Real Time Economy-seminaarissa että palveluväylä ei ole avointa koodia, eikä jaettavissa muille. Että se on väärinkäsitys. Sittemmin tosin olen kuullut, että Laitisen esittämä käsitys olisi väärinkäsitys.

Internet-huhun mukaan koodi olisi avointa vain osittain, eikä kaikkea lähdekoodia saataisi. Vahvistusta ei ole, mutta näiden huhujen uskottavuutta lisää se, että Suomen ja Viron välisessä sopimuksessa ei mainita avoimuudesta tai ylipäänsä lähdekoodista mitään.

Kaiken tämän kruunaa, että hankkeessa on nyt onnistuttu käyttämään ensimmäinen vuosi saamatta aikaan paljoakaan. On toki kirjoitettu kokonaisarkkitehtuuri ja pidetty seminaareja. Kumpikaan ei varsinainen ketterän hankkeen avauspaukku. Kehitysympäristökin on tiettävästi pystytetty, mutta kenellekään ei anneta pääsyä siihen.

Palveluväylä näyttääkin tällä hetkellä avoimen koodin hankkeelta, jonka koodiin ei pääse käsiksi; ketterältä hankkeelta, jossa tehdään kaikkea paitsi koodataan ja kehittäjäyhteisönrakentamishankkeelta, jossa kehitysympäristöihin ei pääse kukaan käsiksi. Ja 120 miljoonaa olisi tarkoitus käyttää toistaiseksi tuntemattomaan kohteeseen.

Kumpi kuvaus tilanteesta sitten on totta? Molemmat, ja vain aika näyttää, kumpi perii voiton.

Todellisuudella on vielä tällä hetkellä edellytykset kummankin toteutumiselle. Palveluväylästä voi tulla se käännekohta, jossa jälkikäteen huomataan julkiset IT-hankkeiden kurssin kääntyneen kohti toimivaa ja järjellistä. Tai siitä voi tulla yksi pahimpia esimerkkejä siitä, miten IT:n varjolla vedetään rahat yksityiseen taskuun saamatta mitään toimivaa aikaiseksi. Lähikuukaudet ratkaisevat, kummasta tarinasta tulee totuus.

Tässä siis hahmotelma, mitä nähdäkseni pitää tehdä, jotta optimistin tarina voittaa.

Suuntaviivoja hankkeelle

Hankkeelle tarvitaan täsmälliset tavoitteet. Abstrakteista visioista pitää päästä yksi askel alaspäin konkreettisesti mitattavalle tasolle. Tällaisia täsmällisiä suuria tavoitteita näen hankkeella kolme:

1. Jokainen tieto on yhdessä ja vain yhdessä paikassa (master data). Muut tiedon tarvitsijat hakevat sen tästä tunnetusta paikasta, mahdollisesti käyttäen välikopioita, mutta säilyttämättä koskaan omaa rekisteriä.
2. Kansalaisille tarjotaan mahdollisuus nähdä omat tietonsa ja tarkistaa kuka niitä on katsellut. Tämä toteutetaan kaikelle väylään kytkettävälle tiedolle.
3. Projektissa ei luoda uusia toimittajaloukkuja. Olemassa olevat toimittajaloukut tunnistetaan ja joko rajataan vaikutuksiltaan tai puretaan.

Ensimmäinen tavoite on se mitä julkishallinto saa: selkeämmän ja toimivamman arkkitehtuurin kaikelle tiedolle ja siten toiminnalleen. Ministerienkin visioiman reaaliaikaisen verotuksen tai kuntien tuottavuusharppauksen.

Toinen tavoite on se mitä kansalaiset saavat: vahvemman hallinnan omaan dataansa, ensimmäisen askeleen kohti digitaalista kansalaisuutta eikä vain kuluttajuutta.

Kolmas tavoite taas on se mitä alan yritykset saavat: uudenlaisen lähtökohdan siihen, miten tietojärjestelmiä ostetaan, askeleita kohti toimivaa ja tehokasta markkinataloutta.

Nämä tavoitteet on oikeastaan kirjattu muodossa tai toisessa hankkeen asiakirjoihin, tiivistin ne vaan konkreettisemmiksi. Nämä tavoitteet on syytä pitää kirkkaana mielessä kaikessa toiminnassa, sillä kaiken toiminnan tulee niitä edistää. Eikä ole poissuljettua, että tavoitteita voisi olla muutama lisääkin, nämä olivat vain ne mitä minä näen.

Konkreettisesti projekti on syytä rakentaa mahdollisimman ketteräksi ja avoimeksi.

Ketteryys tarkoittaa tässä etenkin nopeita konkreettisia käyttöönottoja ja pieniä osaprojekteja. Ei vuoden mittaista suunnitteluhanketta, vaan pieniä kokeiluhankkeita, ja niiden pohjalta seuraavia pienehköjä hankkeita.

Avoimuus taas tarkoittaa mukaan ottamista. Palveluväylään on tarkoitus integroida aluksi kymmeniä, sitten satoja tietojärjestelmiä ja myös sitä käyttäviä järjestelmiä on potentiaalisesti vähintään satoja. Kaiken tämän tekeminen keskusjohdetusti ja erilaisilla kahdenvälisillä sopimuksilla veisi vuoskymmenen. Siksi pitää tehdä kaikki mahdollinen, jotta kukin virasto, kunta tai yritys voi toteuttaa omia integraatioitaan mahdollisimman itsenäisesti ja helposti.

Sitä varten tarvitaan avoimet testi- ja kehitysjärjestelmät, joilla integraatioita voi kokeilla, vapaasti käytettäviä esimerkkikoodeja, ohjeita, jne. Vielä enemmän tarvitaan väylä käyttävien ja kehittävien ihmisten yhteydenpitoa.

Palveluväylän kehittämiselle ja käytön tueksi pitää rakentaa avoimia keskustelun ja yhteistyön alustoja. Siis esimerkiksi ottaa käyttöön Github, pitää säännöllisiä avoimia seminaareja, tehdä metadatan standardointi avoimesti ja julkisesti, kutsuen kaikki kiinnostuneet mukaan jne. Petri Aukia luonnostelee joitakin hyviä käytäntöjä blogauksessaan.

Kaikki palveluväylän koodi ja mahdollisimman suuri osa integrointikoodista on syytä julkaista netissä avoimella lähdekoodilla. Ei niinkään mistään periaatteellisesta syystä, vaan koska se helpottaa uusien tahojen mukaantuloa ja nopeuttaa uusia integrointeja, kun jo tehdystä työstä voi oppia. Ei ole ollut kerta eikä kaksi, kun avoimen koodin bugi on korjattu sitä käsittelevän palaverin aikana, tai sen myöhästyessä. Avoimuus myös estää palveluväylä-integraatiota muodostumasta taas uudeksi toimittajaloukuksi.

Ja koska rahaa on jonkin verran käytettävissä, projekti voi kannustaa sillä virastoja mukaan toimintaan – ja toimintatapoihin.

Yhteistyösopimus, joka Suomessa salattiin ja Virossa laitettiin nettiin.
Tässä toimintatapojen maahantuonnissa on vielä vähän työtä tehtävänä.

Yllä kuvaamani tavoitteet ja toimintatavat tarkoittavat vallankumousta siinä, miten tietojärjestelmähankkeita Suomessa tehdään. Ne ovat totta kai paras tapa saada palveluväylä nopeasti toimintaan ja käyttöön. Mutta softa on tässä viime kädessä sivuroolissa, tärkeintä onnistumisen kannalta on muuttaa toimintatapoja ja ajattelutapoja.

Ja siksi tärkein yksittäinen ratkaisu on, millaisia ihmisiä hanketta vetämään palkataan. Sellaisen tuloksen saa, millaiset tekijät palkkaa.

Ensinnäkin, pitää palkata osaavia.

Pätevyyttä on monenlaista, ja montaa erilaista osaamista tässä tarvitaankin: poliitista, teknistä, byrokratiaa, muutosjohtamista… Ei tule olemaan helppo homma. Mutta on helppoa keksiä yksi minimiehto, jonka onnistuminen edellyttää: hankkeeseen tarvitaan ihmisiä, jotka ymmärtävät miten ohjelmistoja tehdään.

Vielä konkreettisemmin: jotta hanke voisi onnistua pitää palkata ihmisiä, jotka ovat joskus tehneet työkseen ohjelmointia, mieluiten vielä muualla kuin julkisen sektorin hovihankkijoilla. Kaikkien ei tarvitse vanhoja koodereita, mutta puolet porukasta olisi syytä olla.

Hankkeessa on tarkoitus levittää toimintatapoja, joilla softaprojektit voivat onnistua (sen sijaan että muuttuvat tahmeiksi mammuteiksi). Ja näiden tapojen levittämisessä auttaa paljon, jos oikeasti ymmärtää miten ja miksi ne toimivat.

Toisekseen, pitää palkata muutosta haluavia.

Tehtäessä muutoshanketta avain on totuttujen toimintatapojen muuttamisessa. Tarkoitus on tehdä asiat eri tavalla kuin ennen, ja siksi olisi hyvä palkata ihmisiä, jotka haluavat tehdä asiat paremmin kuin ennen. Haluavat sitä niin paljon, että ovat valmiita näkemään vähän vaivaakin, jotta hanke onnistuisi. Jos näin ei tehdä, hanke tuskin voi onnistua.

Kolmannekseen, pitää palkata ihmisiä, jotka uskaltavat rikkoa totuttuja toimintatapoja.

Kun tarkoitus on muuttaa toimintatavat, halun lisäksi tarvitaan valmiutta rikkoa vakiintuneet käytännöt. Vallankumousta ei tehdä pelkästään kabineteissa pullaa syömällä.

Näillä eväin lähtisin itse liikkeelle.

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.

Miten kansallisesta palveluväylästä tehdään menestys?

Suomeen on päätetty rakentaa kansallinen palveluväylä Viron X-Road-esimerkin ja lähdekoodin pohjalta. Aiheesta on puhuttu paljon, mutta paljon on jäänyt myös avoimia kysymyksiä.

Mikä ihmeen palveluväylä?

Mikä oikein on kansallinen palveluväylä? Verkko, laite, sovellus vai jotain muuta? Kansallinen palveluväylä on joukko yhteisiä protokollamäärityksiä, joiden ansiosta palvelujen liittäminen toisiinsa on helpompaa. Palveluväylässä on sama idea kuin sähköpostissa: posti menee suoraan lähettäjältä vastaanottajalle, ilman keskitettyä palvelinta. Kaikki järjestelmät käyttävät yhteisiä teknologioita sähköpostin lähettämiseen ja vastaanottamiseen.

Palveluväylä ei siis ole joukko palvelimia, joiden kautta kyselyt kulkevat, erillinen tietoliikenneverkko tai edes käyttäjille näkyvä joukko palveluita, vaan yhteenliittymisen toteuttamista helpottava toimintatapa ja siihen liittyvä ohjelmisto. Palveluväylä on tapa luoda palveluja verkkoon ja käyttää niitä.

Miksi palveluväylä?

Palveluväylä ei itsellän ratkaise valtion IT-ongelmia. Jokainen vanha ohjelmisto on liitettävä palveluväylään erikseen. Kunkin ohjelmiston osalta pitää löytää, mitä sen tiedosta voi jakaa muille ja mitä muiden jakamaa tietoa kannattaisi käyttää ohjelmistossa hyväksi. Määrittely-, suunnittelu- ja toteutustyön hinta voi olla varsin kallis.

Useimmat valtion virastot ja muut julkishallinnon toimijat keskittyvät hankinnoissaan uushankintahintaan. IT-hankkeille ominaiset lisätyön kustannukset ja oikeudet hankkeessa tehtävään ohjelmistokoodiin eivät ole olleet kriittisen huomion kohteena. Näin toimien on jätetty jatkokehitystyön monopoli sopimuksellisellisesti sovelluksen alun perin myyneelle taholle. Osa toimittajista hinnoittelee sovellustensa palveluväylään liittämisen erittäin kalliiksi.

Palveluväylän suurimmat hyödyt muodostuvat niistä sovelluksista, joiden tekeminen on nykyisin käytännössä mahdotonta. Vuosikymmenien aikana kukin siilovirasto on jo luonut tärkeimmät niistä sovelluksista, jotka voi tehdä riippumatta  toisen viraston siilossa tuotetusta tiedosta. Tästä johtuen käyttäjä joutuu kertomaan kullekin virastolle osoitteensa ja muut tietonsa. Kun ei luoteta muihin, joudutaan samat tiedot kysymään yhä uudestaan.

Tietomassat, jotka on liitetty palveluväylään, on helppo liittää uusiin sovelluksiin. Jos Viron esimerkit toteutuvat myös Suomessa, on lopputuloksena tästä tilanne, jossa tietoja ei tarvitse enää syöttää erilaisiin julkishallinnon moolokin kitoihin. Sovellukset selvittävät toisiltaan lisätiedot, kunhan vain perustiedot on oikein syötetty.

Jos oikein hyvin käy, palveluväylän ansiosta osaan virastoista muodostuu modulaarisempi arkkitehtuuri, jossa viraston eri tehtävät ovat erillisissä, toistensa kanssa hyvin kommunikoivissa sovelluksissa.

Vanhanaikaisia sovelluksia, kukin omassa siilossaan

Entä jo olemassaolevat sovellukset?

Ei tarvitse olla kovin kaksinen ennustaja arvatakseen, että suuri osa olemassaolevista sovelluksista ei helpolla taivu palveluväylään. Tähän on monia syitä:

1. Sovellus tekee jo sen mitä siltä odotettiin. Monilta sovelluksilta ei odotetakaan laajempaa toiminnalisuutta, eikä niiden liittämistä väylään edes harkita.
2. Sovellus on muutenkin vanhentunut. Ei kannata laajentaa jo korvauslistalla olevia sovelluksia juuri ennen kuin niistä päästään eroon.
3. Sovelluksen päivittäminen olisi liian kallista. Sovellukselle on löytynyt mielekäs liittymä palveluväylän kautta, mutta sovelluksen tehnyt toimittaja pyytää liian kovaa hintaa päivityksen suunnittelusta ja toteutuksesta.
4. Muna – kana -ongelma. Ne sovellukset, joihin olisi mukava liittyä eivät ole vielä valmiita, joten palveluväylähanke haudataan toistaiseksi, eikä siten tulla jakaneeksi omiakaan tietoja väylään.

Onko hanke siis turha? Kannattaako moista edes harkita? 

Yrityspuolen esimerkit palveluväylistä ovat kannustavia. Suuret yritykset, jotka saavat omat sovelluksensa liitettyä toisiinsa, ovat löytäneet yllättäviä etuja siilojen rikkomisesta. Toisissa yrityksissä talouden kokonaiskuva on osoittautunut aivan erilaiseksi kuin eräajona tehtävien vuosikoosteiden perusteella oltiin luultu. Amazonin ja Netflixin kaltaiset verkkopalvelut eivät olisi mahdollisia ilman satojen sovellusten saumatonta liimaamista toisiinsa.

Eikä pidä unohtaa, mitä kaikkea Viro on saanut kustannustehokkaasti aikaiseksi oman palveluväylänsä päälle.

Miten palveluväylästä tehdään menestys?

Palveluväylään avatun tiedon lähestyttävyys on kaiken a ja o. Pitää jakaa tietoa, jota muut tarvitsevat, muodossa, joka on luonteva. Esimerkiksi kansallinen tilasto hevosten määrästä voi olla tiedon jakajalle luonteva, mutta palvelun käyttäjä oli ehkä ajatellut kaupallisten hevostallien näyttämistä kartalla. Jos tarjolla on vain hyvin koostettua tietoa, ei sen päälle saa rakennettua palveluita.

Toinen selvä kokemus on, että rajapintoja tulee käytettyä paljon enemmän silloin, kun käyttö on riskitöntä ja onnistuu keneltä tahansa. Sen sijaan vaikeasti käytettävät rajapinnat jäävät helposti kuolleeksi kirjaimeksi.

Onneksi kansallinen palveluväylä ei ole ainutlaatuinen hanke. Programmable web -verkkopalvelun Six Ways to Make Your Developer Portal More Intuitive -artikkeli on erinomainen suositus niin Valtiovarainministeriölle kuin muillekin palveluväylään tietoja avaaville tahoille siitä, kuinka palveluväylästä ja siihen liitetystä palvelusta tehdään menestys.

Ohjeet lähelle tietoa

Kansallisen palveluväylän kehittäjätiedot on syytä kerätä helposti löytyviin paikkoihin. Joskus 90-luvulla luonteva tapa olisi ollut käyttää paljon työaikaa kansallisten portaalin ylläpitoon, nykyaikaisempaa olisi sopia kaikkien palveluväylän asiakkaiden käyttämä yhteinen nimeämiskäytäntö. Itse kannattaisin /api -tyyppisen hakemiston käyttöä kussakin tietoa jakavassa virastossa. Eli esimerkiksi vero.fi/api, vm.fi/api.

Tee kokeilu helpoksi

Hyvällä rajapinnalla on oltava selkeä dokumentaatio verkossa. Parhailla palveluilla on oma verkkosivunsa, jolla palvelua voi itse saman tien kokeilla. ”Onko Y-tunnuksessa väliviiva tämän kutsun kautta kutsuttuna?” ”Mikä on oikea formaatti osoitteelle?” Helppoja kysymyksiä, jos niitä voi kokeilla saman tien verkkopalvelun kautta.

Hyvät esimerkit rajapinnan käytöstä ovat todella tärkeitä. Esimerkki on sitä parempi, mitä lähempänä se on käyttäjän tarvetta. YTJ-järjestelmälle se voisi olla vaikkapa Y-tunnuksen haku yrityksen nimen perusteella.

Verkkoesimerkin lisäksi tarvitaan ohjelmanpätkiä, joilla näytetään kädestä pitäen, miten palvelua käytetään. Esimerkkikoodia tarvitaan monella eri ohjelmointikielellä. Parhaat kehittäjät osaavat lukea esimerkkejä yhdellä kielellä ja päätellä mitä toisessa ympäristössä tarvitaan, mutta muille tuo on turha kivi kengässä.

Kunnon kirjastot valmiiksi

Kaikilla kehittäjillä on samantyyppisiä tarpeita palveluväylän käytössä. Kirjastoksi kutsutaan ohjelmoinnissa valmista koodia, joka voidaan lliittää toiseen sovellukseen ja joka tarjoaa korkeamman abstraktion sitä kutsuvalle ohjelmalle.

Valtiovarainministeriön kannattaisi varmistaa, että yleisesti käytetyille ohjelmointikielille olisi vahva kirjasto, joiden kehitys on VM:n näpeissä – yksi kirjasto, jonka kautta kutsutaan kaikkia palveluväylän kautta saavutettavia palveuita.

Jos jokaiselle palveluväylän takaa saatavalle palvelulle tulee oma kirjastonsa, ei hankkeella ole saatu vähennettyä monimutkaisuutta nykyiseen verrattuna.

Monilla organisaatioilla on kiusaus kirjoittaa kirjasto vain heille tärkeimmälle ohjelmointikielelle. Kansallisesti kriittisessä hankkeessa tämä olisi vaarallista. Useimmille kielille muodostuisi omat harrastelijoiden kehittämät kirjastonsa, jotka voivat muodostua yhteensopivuus-, päivitettävyys-, lisensointi- tai jopa tietoturvariskeiksi laajalti käytettyinä.

Käytä tuttuja toteutustapoja

Parhaita rajapintoja ovat ne, jotka ovat täysin itsestäänselviä. Niissä on käytetty alan yleisiä käytäntöjä tutuilla tavoilla, ja niiden käyttöä ei tarvitse erikseen oppia. Luovuudelle ei ole tässä tilaa.

Neuvosta voi ottaa vaarin sekä kansallisen palveluväylän suunnittelutiimi Valtiovarainministeriössä että kunkin rajapinnan kehittäjät. Vaikka palvelu olisi helpompi tehdä käyttäen tavallisesta poikkeavia kirjasimia, kutsuja tai autentikointeja, palveluväylästä tulee suositumpi, kun kaikki pitäytyvät tutuissa tavoissa toteuttaa palvelut.

Mitä tutummalta palveluväylä tuntuu, sen parempi se on käytössä.

10

Moderni tietojärjestelmähankinnan valmistelu

Hyvin suunniteltu on puoliksi tehty ketteränkin kehityksen aikakaudella. Tietojärjestelmähankinnan valmistelussa on ymmärrettävä, mistä uuden järjestelmän arvo syntyy ja mikä sen toteuttamista rajoittaa. Millainen on nykypäivän vaatimusmäärittely?

Ketterä kehitys vaatii kurinalaista valmistelua

Nyt intoillaan ketteristä menetelmistä, ja hyvä niin. Ketteryydessä painottuu asiakkaan visio, vastuu ja priorisointikyky hankkeen ohjauksessa, ja toisaalta jatkuva keskustelu toteuttajan kanssa. Molemmat tekevät hankkeen onnistumisesta todennäköisempää.

Ketterät menetelmät eivät vähennä suunnittelutyön merkitystä ennen hankintaa, oikeastaan päinvastoin. Ketterä kehitys on tiukkaa paneutumista kehitystyöhön. Kehityssprintin numero yksi koittaessa tavoitteiden on syytä olla kirkkaasti selvillä ja avointen kysymysten hyvin rajattuja, jotta kalliita kehityspäiviä ei kulu hukkaan.

Vesiputousvalmistelussa jätettävä tilaa teknologian tehokkaalle käytölle

Ketterien menetelmien rinnalla kulkee edelleenkin se projektimaailma, jossa organisaatiokulttuurin, hyvin rajatun ongelman tai ohjausresurssien rajallisuuden vuoksi ei haluta lähteä ketterään malliin. Silloin hankinnan valmistelussa määritellään kehitystyön tavoitteet ja rajat, ja annetaan hankinnalla kehitystyö toimittajan prosessikoneen huolehdittavaksi.

Tässäkään tapauksessa viisas asiakas ei halua määritellä toteutustyötä tukkoon. Sen sijaan tilaaja antaa kirkkaan kuvan tulevan järjestelmän liiketoiminta- ja käyttötavoitteista, piirtää hyvin näkyviin taustajärjestelmien luomat reunaehdot ja tunnistaa ehdottomat vaatimukset ominaisuuksille. Loppu jää toimittajan ratkaistavaksi tehokkaimmalla ja laadukkaimmalla mahdollisella tavalla valittujen teknologioiden näkökulmasta.

Millainen sitten on moderni hankinnan valmistelu? Tässä malli, jolla esim. Codento niitä asiakkailleen tekee:

Esiselvityksen perusteella voidaan käynnistää hanke

Esiselvityksessä muodostetaan kehitysprojektin liiketoimintatavoitteet ja visio, hahmotetaan järjestelmän taustaprosessit ja niiden muutokset sekä kartoitetaan karkeasti taustajärjestelmät. Mikäli kehityshankkeen teknologiat eivät ole ostajalle tuttuja, osana esiselvitystä tehdään markkinakatsaus tai tekninen vuoropuhelu. Prototyyppien tekeminen osana esitutkimusta voi mutkikkaammissa kokonaisuuksissa olla järkevää. Oleellista on tunnistaa hankkeen omistaja ja tärkeimmät muut vaikuttajat.

Esiselvityksen lopputuloksena saadaan muodostettua hankkeelle ohjausryhmä tai muu tarpeellisella vallalla varustettu päätöksentekotiimi, tehtyä  periaatepäätös hankkeeseen lähtemisestä sekä hahmotettua projektimalli, budjetti ja aikataulu. Kun nämä päätökset ovat taskussa, hankinnan valmistelu voi alkaa.

Mieti hankintamalli, järjestelmän arvo ja onnistumisen reunaehdot

Varsinainen hankinta valmistellaan sitten näiden avulla:

• Visio. Hankitaan kuva siitä, mitä käyttäjät järjestelmältä tarvitsevat. Tämän äärellä kannattaa viettää aikaa, sillä jos käyttäjät eivät hyödy järjestelmästä, sitä ei käytä kukaan. Silloin kehitystyö menee väistämättä hukkaan.Käyttäjätarpeen lisäksi visiossa kuvataan, miten järjestelmän onnistuminen muuttaa liiketoimintaa ja organisaation päivittäisissä käytännöissä, sekä asetetaan onnistumiselle yksinkertaiset indikaattorit. Vision osana on myös palvelun alustava konsepti eli toteutuksen perusidea ja sitä hahmottava visuaalinen mallinnus tai prototyyppi.
• Käyttäjäpersoonat. Palvelukehityksen suurille ja pienille päätöksille tarvitaan konkreettinen peilipinta. Tällaisena toimii käyttäjäpersoonat, jotka tehdään käyttäjätutkimuksen tai vaikkapa asiakaspalvelun ja analytiikan tuoman ymmärryksen perusteella. Jo persoonia tehtäessä kannattaa priorisoida: kuka persoonista on kehityksen kannalta ensisijainen? Kenen tarpeet pystytään toteuttamaan vasta järjestelmän seuraavassa versiossa?
• Kuvaus taustajärjestelmistä. Kuvataan järjestelmät, joita vasten järjestelmä toteutetaan. Keskitytään erityisesti niiden lähiaikojen kehitykseen ja rajapintoihin.
• Vaatimusmäärittely tai alustava kehitysjono. Jos toteutetaan vesiputosmallilla, tarvitaan vaatimusmäärittely. Siinä keskitytään kuvaamaan järjestelmän hahmotetut funktiot ja niiltä vaaditut ominaisuudet. Varotaan kuvaamasta sellaisia asioita, jotka on viisainta jättää toimittajan ratkaistavaksi valitun teknologian ja toimittajan työtapojen perusteella.Jos taas tehdään ketterästi, muodostetaan jo hankintavaiheessa asiakkaan näkemys alustavasta kehitysjonosta. Sitä voidaan jalostaa yhdessä valitun toimittajan kanssa, kun toteutustyö alkaa. Kehitysjonon vaatimukset kuvataan ylätasolla, käyttäjän näkökulmasta ja mahdollisimman visuaalisesti.
• Tarjouspyyntö ja sopimusluonnos. Tarjouspyynnössä kuvataan käytettävä hankintamalli, hankittavan kokonaisuuden osat ja eteneminen, ja mikäli kyse on julkishallinnon hankkeesta, kilpailutuksessa vertailtavat asiat ja vertailun kriteerit. Sopimusluonnoksessa naulataan kiinni ostajan kannalta oleelliset reunaehdot ja jätetään neuvottelun varaa niihin kohtiin, joissa sitä on.

Hankintaa valmistellesasi mieti jo projektin aloitusta

Jo hankintavalmistelua aloitettaessa on hyvä varmistaa kolme käytännön asiaa, jotta projekti pääsee alkamaan ajoissa ja sillä on onnistumisen mahdollisuudet:

1. Hankkeella on sitoutunut ohjausryhmä, joka on valmis ryhtymään töihin hankkeen hyväksi heti hankintapäätöksen syntyessä, sekä resurssit projektin päivittäiseen pyörittämiseen (esim. ketterässä hankkeessa neljän hengen kehitystiimille täysipäiväinen tuoteomistaja)
2. Tarjousten vertailuun on käytettävissä tarvittava asiantuntemus, myös kyseessä olevasta teknologiasta, ja
3. Kehitystyöhön tarvittavat palvelimet ja työtilat on mahdollista saada kasaan toteutustyön aloittamiseen mennessä.

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.

7 askelta käyttäjien saamiseen

Oletko ollut tilanteessa, jossa uusi sähköinen palvelu on ollut tekeillä mutta on tuntuu siltä että kukaan ei kiinnostu? Mikä silloin neuvoksi? J. Boye Aarhus 13 -seminaarissa moni puheenvuoro pohti, mikä takaa sähköisen palvelun käyttöönoton onnistumisen. Tässä siis vinkit eurooppalaisilta asiantuntijoilta:

1. Bjørn Guldager, J. Boye:
Ratkaise palvelulla oikeaa ongelmaa.

Jos palvelu ei tuota arvoa (liike)toiminnalle, ei ole toivoa. Toisaalta, jos käyttäjät eivät tunnista, minkä ongelman palvelu heille ratkaisee nyt paremmin, tuota arvoa ei voi syntyä. Mikä on käyttäjien isoin ongelma, entä liiketoimintasi? Miten voisit lyödä nämä kaksi kärpästä yhdellä iskulla?

2. Laura Invenius, ABB:
Ymmärrä osto- tai asiointipolut.

Sähköinen palvelu on onnistunut, jos se löytää ne epäjatkuvuuskohdat jotka tällä hetkellä ovat ostamisessa tai asioinnissa asiakkaille vaikeita. Ratkaise ne digitaalisesti ja palvelun lisäarvon perään ei tarvitse enää kysellä.

3. Anne Louise Grønnebæk Hansen, Designit:
Julkaise aluksi pienin mahdollinen tuote.

Käyttäjille on annettava aikaa tottua peruskonseptiin, ennen kuin ryhdytään lisäämään hienouksia. Ja jos et tiedä, miten käyttäjät käyttävät perusominaisuuksia arjessa ja millaisia ongelmia he kohtaavat, miten tiedät millaisia lisätoiminnallisuuksia kannattaa kehittää? Aloita siis 20 %:lla suunnitelluista toiminnallisuuksista.

4. Harry Brignull, UK:
Varo ettei palvelu toimi vastoin arvojasi.

Jos organisaatiosi pyrkii olemaan reilu ja asiakaslähtöinen ja tuottamaan hyvää mieltä, uutiskirjeen tilausruudun ei ehkä kannata olla oletuksena valittu. Kitke käytettävyystutkimuksella pois juonikkaat polut, jotka manipuloivat tai ohjaavat harhaan. (Lisää “dark patterns” –ilmiöstä.)

5. Christina Rahtgens, Roland Berger:
Käyttöönotto on tärkeämpi kuin itse palvelu.

Priimoinkin koodi menee hukkaan ilman käyttäjien tuomaa arvoa. Tee siis käyttäjien saamisesta projektisi isoin ponnistus.

6. Bjørn Guldager, J. Boye:
Analysoi valta-/kiinnostus-nelikenttäsi.

Ketkä ovat ne, joilla on vähän valtaa ja vähän kiinnostusta palveluasi kohtaan? Entä paljon valtaa ja vähän kiinnostusta? – Älä keskity heihin, mutta pidä informoituina. Paljon valtaa ja paljon kiinnostusta? – Kultatuoli esiin. Vähän valtaa ja paljon kiinnostusta? – Siinä ovat tulenkantajasi.

7. Christina Rahtgens, Roland Berger:
Hanki tulenkantajia houkuttelemaan käyttäjiä.

Käyttäjien saaminen mukaan vaatii kärkijoukkojen esimerkkiä ja näyttöjä tuloksesta, helppoudesta ja hauskuudesta. Hanki edelläkävijöitä palvelun taakse, pidä meteliä saaduista hyödyistä. Houkuttele käyttäjät kilpailemaan keskenään.

Kuva: http://instagram.com/jboyedk