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 palveluväylän (X-Road) yleisarkkitehtuuri. Keskellä on väylä, joka yhdistää tietojärjestelmiä. Tämän tarkkuuden kaaviosta ei tietenkään näe, mitä oikeasti tehdään.

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.

mahdollisuudet-ja-uhat

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

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.

Teksti on lakujaan julkaistu Hyvä renki -blogissa, joka käsittelee suomalaisen tietoyhteiskunnan ongelmia ja ratkaisuja

Miksi IT-jaostoa tarvitaan

Sain käsiini erään viraston sisäisen muistion heidän uudesta tietojärjestelmästään. Tässä  yhteenveto-osa hiukan anonymisoituna:

  • Nykyisellään järjestelmän haitat ovat huomattavasti sen tarjoamia hyötyjä suuremmat.

  • Järjestelmä on keskeneräinen: hidas, epäselvä ja epävakaa.

  • Järjestelmä pitää saada toimimaan niin, että [sisältöä] ei häviä.

  • Järjestelmän käyttöönoton myötä […] asiakaspalvelu on hidastunut ja vaikeutunut merkittävästi.

  • […] käsittely kestää nyt moninkertaisen ajan aiempaan verrattuna.

  • Kehittäminen sitoo kohtuuttomasti työaikaa ja resursseja

  • Lomakkeiden määrää ja sisältöä tulisi voida muokata joustavasti.

Ja muutama muu lainaus:

”Ongelmia on ollut mm. sellaisten [sisältöjen] kanssa, jossa on käytetty ”ääkkösiä”, eli ä- ja ö-kirjaimia. Myös muita [sisältöjä] on hävinnyt järjestelmästä ilman selkeää syytä.”

 

”Informaation kulku korjaavalle taholle on hidasta. Tukipyyntöhakemukset tehdään sähköpostitse, eikä varmuutta korjauksen toteutumisajankohdasta. Korjauspyyntöjen lähettämistä hidastaa, että ei ole täyttä selvyyttä, kuka minkäkin ongelman korjaamisesta vastaa. […] Esimerkiksi lomakemuutokset ehdotettiin lokakuussa 2012, ne toteutuivat kesäkuussa 2013.”

Kyse ei nyt ole mistään 80-luvun perinnejärjestelmästä, vaan koko systeemi on tehty tällä vuoskymmenellä korvaamaan vanhaa.

Itse järjestelmää tuntematta syntyy aika vahvasti vaikutelma pieleen menneestä softahankkeesta. Uudistuksen tavoitteet ovat olleet epäselviä, eikä järjestelmä vastaa käyttäjien tarpeita. Lisäksi systeemi on selvästi keskeneräinen, mutta ketterää ongelmiin reagoimista ei ilmeisesti tehdä, mahdollisesti sekavista vastuusuhteista ja hankalista sopimuksista johtuen.

Valitettavasti kyseessä ei ole yksittäistapaus. Tämä on jo kolmas kaupungin asiakaspalvelujärjestelmä, josta tänä syksynä kuulen että se on hidastanut työntekoa. Softajärjestelmiä kehitetään sadoilla tuhansilla tai miljoonilla, jotta säästettäisiin toimintaprosesseissa ja saataisiin parempia tuloksia. Mutta jos järjestelmät hukkaavat dataa ja vaativat ylimääräisiä kliksuttelukierroksia, ei niistä mitään säästöjä tule.

Tämä on suurin syy, miksi halusimme perustaa kaupunkiin IT-jaoston. Tälle tilanteelle on vaan pakko tehdä jotain, ja asioiden julkisempi käsittely voisi olla ensimmäinen askel parempaan suuntaan.

Kaupunginhallituksen tietotekniikkajaoston ensimmäinen kokous on 28.10. Se on vasta alkumuodollisuuksia. Marras-joulukuussa tarkoitus on perehtyä kaupungin järjestelmien ja toiminnan nykytilaan. Jatko sitten tilanteen mukaan.

Onko IT politiikkaa? – Helsingin tietotekniikkajaosto

Kaupunginvaltuusto perusti eilen kaupunginhallituksen tietotekniikkajaoston ja nimitti minut sen puheenjohtajaksi (kiitos luottamuksesta jne). Koska olen osavastuullinen siihen, että näin tehtiin, lienee paikallaan selittää mistä on kyse, ja mitä tällä jaostolla yritetään saada aikaan.

IT-jaosto (joksi sitä nyt kutsun) on siis poliittinen luottamuselin. Se tarkoittaa, että valtuusto valitsee sinne eri puolueiden edustajia. Valintaperuste ei ole mikään nimenomainen pätevyys, vaan kukin puolue saa paikkoja vaalimenestyksensä mukaan, ja jakaa ne kuten parhaaksi katsoo.

IT-jaosto ei siis myöskään suunnittele tai varsinkaan toteuta kaupungin IT-hankkeita. Sen tehtävänä on asettaa suuntaviivat IT-ratkaisuille yleisesti, ja valvoa, että suuret hankkeet tehdään asianmukaisesti.

Kaupunginhallituksen tietotekniikkajaoston jäsenet ovat

Otso Kivekäs (pj, vihr)        vara Jasmin Hamid (vihr)
Minerva Krohn (vihr)          vara Hannu oskala (vihr)
Ulla-Marja Urho (vpj, kok)  vara Arja Karhuvaara
Ossi Mäntylahti (kok)          vara Joona Haavisto
Katrina Harjuhahto-Madetoja (kok) vara hannele Luukkainen (kok)
Kaarin Taipale (sd)               vara Jouko Malinen (sd)
Tuomas Kurttila (sd)           vara Miriikka Laaksonen (sd)
Mikko Pöri (vas)                    vara Juho Lindman (vas)
Kristiina Juth (rkp)               vara René Hursti (ps)

Kuten listan ihmisiin tutustumalla huomaa, osalla on IT-taustaa, osalla taas ei. Tämä on normaalia luottamushenkilöpäätöksenteossa. Aivan vastaavasti kaupunkisuunnittelulautakunnassa ei ole pelkkiä arkkitehtejä tai opetuslautakunnassa opettajia. Poliittisten päätöksentekijöiden on tarkoitus edustaa kaupunkilaisten ääntä. Itse asiasisällön osaaminen pitäisi tulla esittelevien virkamiesten puolelta.

Tässä vaiheessa voidaankin esittää ihan perusteltu epäilys, että kannattaako poliitikkojen nyt sorkkia tietotekniikkaa? Eikö asiat sujuisi paremmin, jos annettaisiin ammattilaisten tehdä työnsä?

Oma arvioni on, että tässä tapauksessa kannattaa, kahdesta syystä

Ensinnäkin, kaupungin IT-hankinnoissa on ongelmia. Esimerkiksi toimeentulotuen nettilomake maksoi miljoonia, koska se tehdään vanhentuneelle suljetulle alustalle; määrittelyjä tilataan tekemään sama yritys jonka on tarkoitus tehdä myös toteutus; ja päätöksentekojärjestelmä muistuttaa välillä vitsiä.  Lisäksi tietenkin Apotin kaltaiset jättihankkeet vaativat huolellista seurantaa.

Vaikka poliitikoilla ei ole mitään maagista kykyä ymmärtää asioita muita paremmin, niin poliittinen päätöksenteko on luonteeltaan julkista. Ja se tarkoittaa että mahdolliset ongelmat tulevat esiin; vanhanaikaiset hankintakäytännöt ja epäterveet toimittajasuhteet täytyy perustella jaostolle, joten samalla ne huomataan ja ongelmien korjaaminen saattaa edistyä. Esimerkiksi mainittu sosiaalitoimen järjestelmäalusta olisi pitänyt korvata viimeistään kymmenen vuotta sitten. Asia vaan ei ole noussut esiin ennen  kuin nyt.

Vaikka hankinnat ovat periaatteessa vain tehokasta päätösten toimeenpanoa ja siten virkamiesvalmistelun piiriin kuuluva asia, niin käytännössä prosesseille pitää tehdä jotain. …ja tämä on jotain.

Toisekseen, on olemassa tietotekniikan ja tietoyhteiskunnan poliittisia kysymyksiä. Vaikka hankinnat ovat tehokkaan toimeenpanon osa, niin vaikkapa datan avaaminen ei ole. Se on poliittinen linjaus, joka hyödyttää kaupungin asukkaita ja yrityksiä ja myös kaupungin organisaatiota. Mutta se on linjaus, ja demokratiassa linjapäätökset kuuluvat luottamuselimille.

Muita mahdollisia poliittisia linjauksia ovat esimerkiksi pääsyn avaaminen kaupungin päätöksentekodataan, avoimen lähdekoodin suosiminen tai kaiken kaupungin kanssa asioimisen tarjoaminen netin kautta. Näitä kysymyksiä ei ole kovin suurta määrää, mutta ne ovat kuitenkin olemassa. Ja ennen tätä ei ollut käytännössä mitään areenaa niiden käsittelylle.

IT-Jaosto on syntynyt Vihreiden aloitteesta. Hannu Oskala ehdott sitä kaksi vuotta sitten, ja vaalien jälkeen ehdotimme sitä kaupungin strategiasta neuvoteltaessa. Strategiaan kirjattiinkin:

”Perustetaan kaupunginhallituksen alaisuuteen IT-jaosto, joka valvoo kaupungin tietotekniikkastrategiaa sekä tietohallinto- ja tietotekniikkainvestointeja eri hallinnonaloilla.”

Lautakunnan sijasta perustetaan jaosto, koska lautakunta valvoo yhtä virastoa, kun taas kaupunginhallituksen jaostolla on valtaa kaikkeen kaupungin toimintaan. Ja IT on oikeasti hajallaan pitkin kaikkea kaupungin toimintaa.

Eilen päätetysti jaoston tehtävänä on:

  1. tehdä esityksiä tietotekniikkaa ja tietohallintoa koskevista periaatteista ja linjauksista sekä seurata niiden toteutumista
  2. seurata kaupungin tietotekniikkaohjelman laatimista, toimeenpanoa ja toteutumista
  3. hyväksyä tietotekniikan hankeohjelmaan hallintokuntien esityksestä tietotekniikkahankkeet, joiden kokonaiskustannusarvio ylittää miljoona euroa
  4. antaa lausunto kaupungin tietotekniikan hankeohjelman kokonaisuudesta.

Ensimmäinen kohta antaa vallan ehdottaa periaatteita. Jaosto ei voi suoraan päättää, että kaikki kaupungin hankinnat tehdään vaikka ketterästi, mutta se voi ehdottaa tällaista yleistä periaatetta kaupunginhallitukselle.

Toinen kohta koskee kolmen vuoden välein laadittavaa tietotekniikkaohjelmaa. Merkittävää tässä on erityisesti toteutumisen seuraaminen. Esimerkiksi tämänhetkinen tietotekniikkaohjelma linjaa avoimesta datasta ”Tietojen saatavuutta parannetaan rakentamalla avoimia rajapintoja olemassa oleviin järjestelmiin ja edellyttämällä avoimia ja dokumentoituja rajapintoja hankittavissa järjestelmissä.” Jaostolla on nyt valtuudet kutsua minkä tahansa viraston johto kertomaan, millä tavalla he ovat dataansa avanneet ja aikovat sitä tehdä.

Kolmas kohta tarkoittaa, että yli miljoonan euron hankkeita ei voi Helsingissä aloittaa ilman IT-jaoston siunausta. Tarkka prosessi pitää vielä hakea, mutta tarkoituksena on, että asiat tuodaan IT-jaostoon niin aikaisessa vaiheessa että hanketta voidaan vielä aidosti muuttaa.

Neljäs kohta koskee kaikkia muita kaupungin IT-hankkeita, joita on vuosittain vajaat sata. Niitä IT-jaosto ei yleensä käsittele yksittäin, vaan kokonaisuutena.

Jo käynnissä olevia hankkeita IT-jaosto seuraa, mutta sillä ei ole suoraa toimivaltaa määrätä niitä. Tässä voidaan kuitenkin ”lainata” kaupunginhallituksen valtaa. Eli jos IT-jaosto suhtautuu kriittisesti johonkin hankkeeseen, valmistelevat virkamiehet luultavasti kuuntelevat sitä, koska viime kädessä asia voidaan aina viedä kaupunginhallitukseen, joka luultavasti kuuntelee jaoston näkemystä.

Erityisesti tämä koskee Apottia. Apotin etenemistä tullaan raportoimaan IT-jaostolle säännöllisesti, mutta jaosto ei voi määrätä hanketta toimimaan millään tietyllä tavalla. Ja päätös lähteä tekemään yhteistä potilastietojärjestelmää on joka tapauksessa jo tehty, eikä jaostolla ole mandaattia sitä muuttaa. Sen sijaan tulen ainakin itse keskittymään siihen, miten hanke saadaan onnistumaan mahdollisimman hyvin niissä reunaehdoissa, jotka on jo päätetty.

Jaoston työ alkaa tämän vuoden puolella. Ensimmäiset kuukaudet menevät lähinnä asioihin perehtymiseen, eli mitään kovin konkreettista ei kannata heti odottaa. Mutta ensi vuoden aikana uskoisin toiminnan muutoksen jo näkyvän jossain.

Tässä vaiheessa jaosto on vaalikauden mittainen kokeilu. Ei ole itsestäänselvää, että poliittisen valvonnan tuominen IT-kysymyksiin saa asiat toimimaan paremmin. Mutta tuskin ne ainakaan huonommin voivat mennä.

 

Kirjoittaja aikoo raportoida tässä blogissa kaupunginhallituksen tietotekniikkajaoston tulevasta toiminnasta. Stay tuned.

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.

Toimittajaloukku vantaalaisittain

Kesäkuussa Vantaa osti toimeentulotuen nettihakemuksien käsittelyjärjestelmän 1,9 miljoonalla CGI:ltä (ent Logica, ent VM-Data) suorahankintana, kilpailuttamatta. Heinäkuussa selvisi, että Helsinki on ostanut saman toiminnallisuuden CGI:ltä 1,85 miljoonalla, myöskin kilpailuttamatta.

Kumpikin kaupunki osti noin kahdella miljoonalla nettilomakkeen ja sen integroinnin taustajärjestelmiin. Useammankin eri asiantuntijan arvio julkisten tietojen perusteella oli, että tuon pitäisi maksaa pikemminkin kymmeniä tuhansia euroja kuin miljoonia. Jos taustajärjestelmä on poikkeuksellisen hankala, niin ehkä 200 000€. Mutta ei kahta miljoonaa.

Mistä on kyse

Suorahankinta tarkoittaa sitä, että kaupunki ei etsi markkinoilta parasta tai halvinta ratkaisua, vaan ostaa järjestelmän tietyltä yhtiöltä tämän määräämään hintaan. Koska hankintatapa on ilmeisen altis erilaisille väärinkäytöksille ja vedätyksille, on sen käyttöä rajattu laissa tiukasti. Hankintailmoituksessa Vantaan kaupunki perustelee suorahankintaa näin:

”Toimeentulotuki on kiinteä osa Vantaan asiakastietojärjestelmää, eikä sitä voi erottaa VATJ:stä aiheuttamatta hankintayksikölle huomattavaa teknistä ja taloudellista haittaa. Mikäli sähköinen toimeentulotukiasiointi hankittaisiin kolmannelta osapuolelta, olisi rakennettava erillisiä integraatioita ja tietoliikenneyhteyksiä eri järjestelmien välille. Samalla tieto hajaantuisi useaan tietokantaan, mikä estäisi asiakastiedon keskittämisen samaan järjestelmään. VATJ:n rajapinnat eivät ole avoimia, joten kaikki integraatiot olisi rakennettava erillisinä. Edellä mainitut seikat aiheuttaisivat hankintayksikölle huomattavia ylimääräisiä taloudellisia kustannuksia. Hankinta on tehtävä pakottavasta lainsäädännöstä johtuvista syistä. Vantaan kaupunki ei tällä hetkellä pysty noudattamaan toimeentulon käsittelylle asettuja määräaikoja.”

Tässä on kyseessä toimittajaloukku. Se on tilanne, jossa tietojärjestelmää tarvitseva taho on täysin yhden toimittajan armoilla. Tällöin toimittaja voi käytännössä sanella hintansa. Katsotaanpa vähän tuota hinnoittelua.

Vantaalla lasketaan säästettävän järjestelmän avulla 15 henkilötyövuotta. Kun yksi henkilötyovuosi maksaa vajaat 38 300, tarkoittaa tämä 425 000 euron vuotuista säästöä. Ihan kiva säästö siis, pitkän päälle.

Mutta Vantaa on mukana Apotti-hankkeessa, jossa Helsingin seudun kuntien terveydenhuollon ja sosiaalitoimen järjestelmät korvataan yhdellä yhteisellä järjestelmällä. Nyt ostettava koodi on siis tarkoitus heittää roskikseen parin vuoden jälkeen. Realistisesti luultavasti hankkeen loppupäässä, noin 2018.

Jos oletetaan, että säästöt saataisiin täysimääräisinä, ehtisi järjestelmän elinkaaren aikana siis säästyä noin 2,1 miljoonaa euroa. Eli projekti maksaa sen verran, että se juuri ja juuri kannattaa vielä tilata. Pienikin viivästys tai budjetinylitys, niin olisi kannattanut ennemmin palkata 15 ihmistä lisää.

Helsingissä taas kustannussäästöksi on laskettu 0,8 – 1,6 miljoonaa euroa vuodessa. Toisaalta järjestelmään liittyy kaikenlaisia oheiskuluja enemmän, joten kokonaisuudessaan takaisinmaksuajaksi on laskettu 3 vuotta käyttöönotosta. Jos käyttöönotto saadaan tehtyä suunnitellusti 2014 alkuun, järjestelmä ehtii olla käytössä ehkä 3-4 vuotta, eli sopivasti juuri niin kauan, että se kattaa kulunsa. Kuinkas sattuikaan.

Vaikuttaisi siltä, että tässä on tehty niin sanotusti maksukykypohjaista hinnoittelua. Siinä tuote maksaa juuri niin paljon, kuin mitä asiakas on siitä korkeintaan valmis maksamaan. vaikka se olisi kymmenen kertaa kohtuullinen hinta.

Vapaassa markkinataloudessa tuotteensa saa tietenkin hinnoitella juuri kuten haluaa. Yleensä vaan ylihinnoittelija menettää asiakkaansa, mutta toimittajaloukussa ei. Toimittajayrityksellä on kissanpäivät, asiakas on pulassa.

Asiakas, joka hankkiutuu tällä tavoin toimittajan armoille, on hoitanut asiansa todella huonosti.

Miten tähän on tultu

Helsingin sosiaalitoimessa on käytössä CGI:n toimittama ATJ-järjestelmä ja Vantaalla VATJ. Tai no, oikeastaan CGI ei ole niitä toimittanut. Historia on hiukan monimutkaisempi. ATJ tarkoittaa AsiakasTietoJärjestelmä ja VATJ on siitä muokattu versio, Vantaan AsiakasTietoJärjestelmä. Ne kehitti pääkaupunkiseudun kuntien omistama PKT-tietokeskus 80-luvulla. Kyse oli siis kuntayhtymästä, joka teki kuntien omiin tarpeisiin ATK-järjestelmiä. Se, että eri kunnille tehtiin omat versiot oli ajan tapa.

Vuosina 1997-2007 Suomessa tapahtui tietojärjestelmiä toimittavien yritysten kentässä melkoinen myllerrys. valtio, kunnat ja kuntayhtymät alkoivat luopua it-yksiköistään. Alan yritykset ostivat niitä ja toisiaan nopeassa tahdissa. Seurauksena julkishallinnon tietojärjestelmät päätyivät lopulta lähes kaikki kahdelle toimijalle: Tiedolle ja Logicalle. ATJ:n polku fuusiopuussa kulki näin:

  • 1990 PKT-tietokeskus fuusioitui Kunnallistiedon (muiden kuntien vastaava yksikkö) kanssa KT-tietokeskukseksi
  • 1997 KT-tietokeskus listautuu pörssiin nimellä Novo Group
  • 2004 ruotsalainen VM-Data ostaa Novo Groupin
  • 2006 brittiläis-hollantilainen LogicaCMG ostaa VM-datan
  • 2012 kanadalainen CGI ostaa Logican

Kun kuntien yhteinen yksikkö muuttui ensin kuntien omistamaksi yhtiöksi, sitten kotimaiseksi pörssiyhtiöksi ja lopulta kansainvälisen yrityksen haarakonttoriksi, toimintatavat kulkivat perässä hitaammin. Alkujaan ATK-yksikön vastuulla ei ollut pelkästään koodaaminen, vaan myös tuleviin kehitystarpeisiin varautuminen ja suunnittelu. Ja siellä se on edelleenkin. Ei jollain Vantaan sosiaalitoimella ole ollut realistisia edellytyksiä suunnitella ja ennakoida tietojärjestelmiensä kehitystarpeita, arkkitehtuurimuutoksia ja mahdollisia kilpailutuksia. Käytännössä ATJ:n ja VATJ:n kehityksestä ovat vastanneet PKT-tietokeskuksen perilliset, KT-kuntatieto, Novo, VM-data, Logica ja nyt CGI. Kaupungin rooliksi on jäänyt kysyä paljonko rahaa varataan budjettiin ja maksaa laskut.

Hanna Kuusela ja Matti Ylönen kuvaavat kirjassaan Konsulttidemokratia tätä rakennetta. Valtion ja kuntien IT-yksiköt päätyivät osaksi isoja konsulttitaloja, mutta niiden rooli toiminnassa oli ja on edelleenkin paljon suurempi kuin ulkopuolisella tarjoajalla saisi olla. Vantaa ja Helsinki eivät ole ongelmiensa kanssa mitenkään yksin. On aivan normaalia ja maan tapa, että IT-yritys rahastaa kovalla kädellä yksinoikeuttaan järjestelmään, joka on alkujaan tehty kuntien rahalla. ”Järjestelmien suljetut ohjelmistorajapinnat toimivat suoranaisena kiristyskeinona, jolla sosiaali- ja terveydenhuollon yksiköitä pakotetaan hankkimaan kaikki palvelut samalta toimittajalta”.

ATJ
ATJ:n ja tulevan Kansallisen sosiaaliarkiston (KanSa) integrointisuunnitelma. Kuva ei liity suoraan tässä käsiteltyihin projekteihin.

Varsinainen virhe ei siis ollut tämä yksi hankinta. Virhe on tehty joka päivä viimeiset viisitoista vuotta, kun sosiaalitoimen ydintoimintojen järjestelmää ei ole otettu millään tapaa omaan hallintaan – edes rajapintojen tasolla. Pörssiyrityksen tehtävä on tuottaa voittoa, eikä suojella kuntia näiltä itseltään. Kun työntää päänsä katiskaan, hyviä lyhyen tähtäimen ratkaisuja ei enää ole.

Apotti korjaa tilannetta osin, koska siinä vaaditaan avoimia rajapintoja, joiden päälle uusia lisäosia voidaan hankkia muualtakin kuin taustajärjestelmän toimittajalta. Tosin rajapintojen määrittely ja pahimmassa tapauksessa avoimuuskin jää taustajärjestelmän toimittajan vastuulle. Samassa katiskassa on siis kaikkien muidenkin päät, ja silmäkoko on isompi eli pikkukalat pääsevät kulkemaan.

Apotin tapa voi kuitenkin periaatteessa, jos kaikki sujuu onnellisten tähtien alla, johtaa ihan oikeisiin hyötyihin, kun ulkomailla jo valmiiksi kehitetyn järjestelmän ominaisuuksia saadaan käyttöön ”ilmaiseksi”. Vantaan ja Helsingin tapa, jossa yksityisellä yrityksellä on vain yhden asiakkaan käytössä oleva vanhanaikainen tuote, ei missään kuviteltavissa olevassa maailmassa voi johtaa kuin katastrofiin.

Mitä sitten pitäisi tehdä?

Ratkaisua ongelmiin avaa Espoon melko vastaava tapaus vuoden takaa. Espoo hankki kotihoidon optimointisovelluksen (älkää kysykö mikä se on) suorahankintana Tiedolta, koska sovellus rakentui suoraan Tiedon Effican päälle, ja ”sovellus on teknisistä syistä pakko hankkia Effica-järjestelmän toimittajalta.”

Kolme yritystä valitti markkinaoikeuteen, vedoten siihen, että ovat toimittaneet vastaavia järjestelmiä. Valituksia ei tutkittu, koska ne myöhästyivät, mutta Espoo päätti kuitenkin perua hankinnan ja kilpailuttaa työt.

En tiedä Espoon hankkeen jatkoa tarkemmin, mutta nyt Espoo testaa yhdessä Lahden ja Kuntien Tieran kanssa ”hyvinvointijärjestelmien tietojen välittämistä palveluväylän kauttaperustuen Viron X-roadiin. Kuulemani mukaan siinä pilotoidaan juurikin kotihoidon optimointisovellusta. Palveluväylän ansiosta itse sovelluksen voi tehdä helposti kuka vain, vaikka taustalla on edelleen Tiedon Effica.

Menemättä tällä kertaa sen syvemmälle X-roadin ja väyläarkkitehtuurin kiehtoviin saloihin, tiivistän mitä Helsinki ja Vantaa voisivat länsinaapurilta tässä oppia

  1. Älä tilaa suorahankintana järjestelmätoimittajaltasi, vaikka he kuinka sanoisivat että on pakko. Se on luultavasti laitonta ja varmasti tyhmää.
  2. Rakenna arkkitehtuuri, jossa uudet sovellukset ovat irrallaan perustiedoista ja hankinnat voidaan tehdä vapaasti. Se on ensimmäinen askel toimittajaloukusta vapautumiseksi
  3. Tee se mieluiten vuosia sitten. Jos et kuitenkaan tehnyt, tee se heti.

ps. Hesarin Tuomas Peltomäki kirjoitti tänään myös toimittajaloukusta ja Helsingin hankkeesta. Kannattaa lukea.

Konsulttikratia

konsulttidemokratiaKäsiini sattui kirjaston pokkarihyllystä ”Konsulttidemokratia”, Hanna Kuuselan ja Matti Ylösen tutkimus/pamfletti konsulttien käytön kasvusta julkisella sektorilla. Kun nyt itsekin leipäni IT-konsulttina ansaitsen, ja minuakin tähän kirjaan haastateltiin, niin pakkohan se oli lukea.

Kirja käy laajojen haastattelujen perusteella läpi sitä, miten konsulttien rooli on 2000-luvulla kasvanut julkishallinnossa. Erityishuomio on siinä, miten valtionhallinnon tuottavuusohjelma on kieltänyt palkkaamasta työntekijöitä eläköityvien tilalle, jolloin samat työt pitää tilata kalliimmalla konsulteilta. Samalla vastuu ministeriöiden toimintatavoista siirtyy organisaatioselvitysten myötä konsulteille, jotka tietenkin suosittelevat malleja joissa tarvitaan paljon konsultteja. Samalla demokraattisen päätöksenteon rooli kaventuu kohti kumileimasinta, kun päätösten perustelut ovat konsulttien ammattisalaisuuksia.

”Konsulttidemokratian hyveenä pidetään nopeutta, joustavuutta ja ketteryyttä. Konsultit eivät edusta ketään, he eivät ole kansalaisille tilivelvollisia, he eivät ole kulloisenkin alan asiantuntijoita – ja silti he voivat nyky-Suomessa panna liikkeelle tärkeimpiä rakenneuudistuksia vuosikymmeniin. Konsulttidemokratian kulmakivenä on ajatus maailman jatkuvasta monimutkaistumisesta. Tästä huolimatta sen soihdunkantajat kaipaavat pientä viisaiden ryhmää aidosti laaja-alaisen, eri alojen ammattitaidosta ammentavan valmistelun ja päätöksenteon sijaan.”

Oman lukunsa saa myös IT-konsultointi, jossa ei ole yhtä suurta demokratiaongelmaa, mutta sitäkin suurempi rahankuppaus käynnissä. Valtion tietokonekeskus on nykyään osa Tieto oyj:tä ja Kunnallistieto kanadalaista CGI-konsernia (ent. Logicaa). Kuten kaikki muutkin vanhat julkishallinnon IT-yksiköt, jotka yhtiöitettiin ja myytiin. Seurauksena ostaja on yleensä toimittajaloukussa. Osiossa referoidaan myös omaa blogiani – melkein oikein. Nimettömistä sitaateista on myös hauska yrittää arvailla, kuka niiden takana kulloinkin voisi olla.

”Vuonna 2005 [verohallitus] palkkasi toistaiseksi voimassa olevalla sopimuksella konsultin, jolle maksettiin kuukausittaista kiinteää korvausta. Konsultti laskutti kuukausittain riippumatta siitä, oliko työtehtäviä vai ei. Usein ei ollut. Kun konsultti lopulta raportoi tekemästään työstä, kävi ilmi, että AgentIT Finland oy:lle oli maksettu laskutuskäytännön vuoksi noin 70 000 euroa työstä, jota konsultti ei ollut tehnyt.”

Tilanteen korjausehdotusten valikoima sen sijaan jää ohuemmaksi. Tiivistetysti: haabermasilainen Kallio-liike voisi leikkiä demokratian kehittämistä ja muutoin voitaisiin palata 90-luvulle. Tai vielä mieluummin 80-luvulle. Jos vaan sovimme, että työttömyysaste on sama kuin 1989, niin varmaan kaikki muukin hoituu kuten 1989?

Käytännön korjausehdotukset ovat klassisella sarjalla ”laadukasta johtamista”, ”riittävää resursointia”, ”huomioida eri ryhmien äänenpainot” ja ”tuottavuuskeskustelun täyskäännös”. Vähän kuin konsultti olisi kerännyt haastatteluista kasaan kaiken sen mikä ennen oli paremmin ja tehnyt niistä yhteenvedon. Jään kaipaamaan pidemmälle vietyä analyysiä.

Komiteatyöskentelyllä varmasti oli hyvät puolensa, mutta kaipaan kyllä hiukan syvempää ymmärrystä siitä, miksi siitä on luovuttu ennen kun uskon että vanhaan malliin palaaminen sellaisenaan ratkaisee ongelmat.

Lähes ainoana selvänä konkreettisena ehdotuksena nousee esiin ainakin kolmesti mainittu Valtiontalouden tarkastusviraston budjetin (ja roolin?) kasvattaminen. Sitä voi todellakin kannattaa, kuten myös avoimuusperiaatteen laajentamista. Vaan riittävätkö ne pitkällekään?

Nykyinen tie on selvästi ongelma, ja uhkaa jo kohta demokratiaa sekä oikeusvaltioperiaatetta. Mutta mitä tilalle? En usko, että pelkkä ongelmien osoittaminen sormella riittää. Kun konsulttidemokraatit kerran tunnistetaan vallankumoukselliseksi liikkeeksi, ei vastaukseksi siihen riitä menneisyyden haikailu, vaan pitää tuottaa oma, vaihtoehtoinen kertomus valoisasta tulevaisuudesta.

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

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

Apotin riskit

Sain käsiini APOTTI-hankkeen riskianalyysin, joka terveyslautakunnan kokousmateriaaleissa salattiin. Se on julkinen dokumentti, joten jaan sen tässä, olkaa hyvät. Postausta on muokattu.

Mitä raportti sanoo?

Tämä on bisnestason analyysi siitä, mitä riskejä hankkeen toteuttamiseen liittyy. Teknisiä riskejä tai hankittavaan järjestelmään liittyviä riskejä ei ole analysoitu. Tämä on ilman muuta virhe, mutta valitettavan yleinen sellainen.

Työmenetelmänä on ollut haastatella hankkeen johdossa olevat henkilöt ja rakentaa yhteenveto heidän esiin tuomistaan huolista. Tästä lähtökohdasta riskianalyysi on sinänsä hyvin tehty, mutta siis hankkeeseen nähden liian suppea.

Muuan riskianalyysejä työkseen tekevä ammattilainen kommentoi:

Mitään analyysiframeworkkiä tai standardia ei ilmeisesti ole sovellettu, vaan tulosten luotettavuudesta on lähinnä PWC:n sana. Jos otetaan vertailukohdaksi kirjallisuudessa tyypillinen viitekehys

  1. Projects – failing to deliver;
  2. IT service continuity – when business operations go off the air;
  3. Information assets – failing to protect and preserve;
  4. Service providers and vendors – breaks in the IT value chain;
  5. Applications – flaky systems;
  6. Infrastructure – shaky foundations; and
  7. Strategic and emergent – disabled by IT.

Tässä PwC:n paperissa on näistä käsitelty kevyesti ensimmäistä ja viimeistä, ei muita.

Toinen, 20 vuoden kokemuksella riskianalyysejä tehnyt ja lukenut IT-ammattilainen kommentoi analyysiä ”En ole urallani ikinä nähnyt näin kriittistä analyysiä hankkeesta jota ei ole vielä edes aloitettu”. Hän saattoi toki olla hiukan kyyninen.

Riskienhallintaan vähemmän tutustuneille suomennoksena:

  1. Konsultti pitää erittäin todennäköisenä, että toimintaa ei saada muutettua hankkeen toteutuksen kautta. Tällä on hankkeen hyötyjen muodostumiselle katastrofaaliset seuraukset.
  2. Muutosjohtajuus, hankkeen vaatimat resurssit ja uuden oppiminen ovat kaikki todennäköisesti menossa pieleen.
  3. (Poliittinen) päätöksenteko hankkeessa epäonnistuu. Päättäjille ei saada oikeaa tietoa ja päätökset tehdään väärien tietojen valossa.
  4. Hankkeen hinta tulee karkaamaan käsistä. (Mikä on konsulttiraportissa poikkeuksellisen voimakas ilmaisu)

Muutamia huomioita

Sitten vähän yksityiskohtaisempi läpikäynti. Alla omia tulkintojani ja suomennoksiani esiin nostetuista riskeistä. Analyysi kun on kirjoitettu kaunistelevalla konsulttikielellä, jota ei siihen tottumattoman ole aina helppo lukea.

4.1. Hankkeen perusteisiin liittyvät riskit

”Haastatellut kokivat hankinnan laajuuden riskinä sekä tunnistivat kokonaisuuden niin suureksi, että sen ymmärtäminen on haastavaa.”

Kyllä näin on. Normaali johtopäätös olisi pilkkoa hanke ymmärrettävän kokoisiin osiin. Isot IT-hankkeet epäonnistuvat lähes aina juuri siksi, että ne ovat liian suuria ymmärrettäviksi.

”Tuottavuuden kasvun odotukset ja laadulliset tavoitteet pitää varhaisessa vaiheessa konkretisoida mittareiksi, jotka sallivat mahdollisimman vähän tulkinnanvaraisuutta. Jos onnistumista ei konkretisoida mittareiksi jää koko hankinnan menestys subjektiivisten arvioiden varaan ja altistuu spekulaatiolle. Hankkeelle tulee asettaa mitattavissa olevat tavoitteet, joiden toteutumista tulee seurata ja johtaa.”

Niin tulisikin. Miksi sitä ei ole tehty? Jos kyse on ennen kaikkea toimintatapojen muutoshankkeesta, miksi niitä muutoksia ei ole lähdetty hahmottelemaan ensimmäisenä?

4.2. Hankintarengasmalliin liittyvät riskit

”Haastateltavat kokivat HUS:in kaikkein kiireisimmän aikataulun riskiksi, sillä sen koettiin aiheuttaneen tarpeetonta kiirettä hankkeen suunnittelussa ja hankintailmoituksen teossa. Tämän riskin koettiin konkretisoituvan juuri nyt hutiloituun hankintailmoituksen julkaisemiseen ja neuvotteluvaiheen aloittamiseen ilman riittävää suunnittelua.”

Konsultti sanoo, että valmistelua ei ole tehty kunnolla ja että hankintailmoituksessa on ongelmia.

4.5 Hankintaorganisaatioon liittyvät riskit

”Ohjausryhmän työskentelyä pidettiin asiaa edistävänä ja pääasiallisesti tehokkaana, mutta tietotekniikan ja hankintaprosessien substanssiosaamisen koettiin olevan riittämätöntä.”

”Kehittämisryhmän työskentelyssä riskejä nousee haastateltavien mielessä asioiden esittelyn ja aikataulun liiallisesta nopeudesta, yhteisen kielen ja ymmärryksen puutteesta ja keskustelun vähäisyydestä. Asioita on tuota kehittämisryhmään nopealla aikataululla ja haastateltavat kokivat että usein esiteltyjä asioita ja dokumentteja on ollut liian myöhäistä muuttaa. Kehittämisryhmän jäsenistä usea totesi että hankintajuridinen ja tietotekninen sanasto on ongelmallista ja yhteisen kielen puute on hankaloittanut asioiden ymmärtämistä. Riskinä on, että kehittämisryhmä ei pysty täysipainoisesti edistämään hankinnan onnistumista, koska jäsenillä ei ole riittävää hankinnan ja tietotekniikan substanssiosaamista.”

Ensinnäkin, niinhän minä sanoin: osaamista tarvittaisiin lisää. Toisekseen, tästä tulee huolestuttavasti kuva, että hanketoimiston yläpuolisessa ohjauksessa ollaan aika tuuliajolla, eikä tosiasiallista mahdollisuutta tai kykyä ohjata hanketta ole. Hanketoimisto työskentelee siis hyvin itsenäisesti, ilman että sen tarvitsisi kuunnella ulkopuolisia. Tämä vastaa kuvaa, joka erityisesti HUS:n toiminnasta on perinteisesti ollut ja josta ehdottomasti pitäisi päästä eroon.

”Riskienhallintatoimenpiteet eivät ole vielä konkretisoituneet työkaluiksi vaikka keskustelu riskeistä ja niiden vaikutuksista onkin moniulotteista.”

Konsulttikielellä tässä lukee, että riskien hallitsemiseksi ei ole tehty mitään.

”Hanketoimisto on mitoitukseltaan minimaalinen verrattuna hankinnan laajuuteen, sen resurssien pieneneminen olisi merkittävä riski ja vaarantaisi hankkeen onnistumisen.”

Konsultin mielestä hanketoimisto ei ole tehtäviensä tasolla.

4.6 Kilpailuttamiseen, neuvotteluvaiheeseen ja sopimukseen liittyvät riskit

”Koska valmiita järjestelmiä tällä puolelle on hyvin rajallisesti ja ulkomaisissa järjestelmissä ei ollenkaan, ei järjestelmätoimittajien voida ajatella pystyvän demonstroimaan valmiita ratkaisuja.”

Konsultti huomauttaa, että tässä ei olla ostamassa valmista järjestelmää vaan järjestelmä räätälöidään joka tapauksessa HUSin ja kuntien käyttöön. Senhän toki tiesimmekin, mutta päinvastaistakin kuvaa yritetään julkisuuteen antaa.

”Sosiaalihuollon asiantuntijaryhmän perustaminen hanketoimiston alaryhmäksi on välttämätön ja kiireellinen riskienhallinta toimenpide. Ryhmän tulisi valmistautua neuvottelumenettelyyn luomalla tavoitetila ja määrittelemällä hankintaa niin konkreettiseksi että se on kommunikoitavissa palveluntuottajaehdokkaille.”

Konsultin mukaan hankkeessa ei siis tunneta sosiaalihuollon vaatimuksia, eikä järjestelmä luultavasti tule niitä palvelemaan. Miksi sosiaalihuoltoa edes yritetään tuoda mukaan samaan hankkeeseen, kun onnistumisen edellytyksiä ei tunnu olevan?

”Suuressa osassa haastatteluita nousi esille riskinä prosessien määrittelemättömyys ja tavoiteltavan IT-arkkitehtuurin kuvauksen puute.”

Hankkeen tavoitteita ei siis oikeastaan ole määritelty. Riski, jota on kansalaiskeskustelussa pidetty merkittävänä.

”Riskiä hankeorganisaation erimielisyyksistä liittyen määrittelyyn tulisi hallita antamalla selvitys siitä miksi nykyiseen toimintamalliin on päädytty.”

Haastateltavat siis ihmettelevät, miksi hanketoimisto toimii sammutetuin lyhdyin. Vahvistaa valitettavasti ylläkin jo syntynyttä kuvaa ongelmallisesta johtamistavasta.

”Suurimpana kustannustenhallinnan riskinä pidettiin sitä, että palvelun oston hinta muodostuu kokonaisuutena paljon ennakoitavaa suuremmaksi. Tämä liittyy olennaisesti ”jälkilypsyn” mahdollisuuteen, eli siihen ettei palvelutasosopimuksessa ole huomioitu kaikkea vaan järjestelmätoimittaja pystyy rahastamaan muutos-, räätälöinti- ja päivitystöillä loputtomasti.”

Kyse on toimittajaloukusta. Valitulla toimintamallilla se on mahdotonta välttää. Välttämisen tapoja olen käsitellyt aiemmin. Niihin kuuluu ennen kaikkea hankkeen pilkkominen, keskeisten osien kontrollin pitäminen itsellä ja avoimuus.

Riskianalyysi ei sen sijaan tarjoa tähän näitä yleisesti tunnettuja vastauksia, vaan ehdottaa, että palkataan hankintakonsultti. Analyysin kirjoittanut PriceWaterhouceCoopers onkin tiettävästi palkattu hankkeen hankintakonsultiksi.

4.8 Implementaatioon liittyvät riskit

”Sekä muutosjohtajuutta että operatiivista muutosta tulee toteuttaa systemaattisesti koko hankkeen ajan. Kaikkialla ei ole vielä otettu muutoksen ensimmäistäkään askelta, nämä organisaatiot tulee tunnistaa riskien hallitsemiseksi ja niiden toimintaan vaikuttaa ensi tilassa.”

Suomeksi: konsultin mukaan hanke on ainakin osin tuuliajolla.

4.9 Viestintään liittyvät riskit

”Viestintään liittyviä riskejä voidaan hallita tehokkaimmin toimimalla proaktiivisesti. Hanketoimiston tulee aktiivisesti huolehtia oikean ja ajantasaisen tiedon levittämisestä sekä hankintarenkaan päätöksenteolle, hankintarenkaiden osapuolille, lehdistölle ja muille kiinnostuneille sidosryhmille.”

Riski selvästikin on toteutunut ja sen hallinta epäonnistunut. Hanketoimsito ei ole kyennyt toimittamaan julkisuuteen oikeaa ja ajantasaista tietoa, vaan päin vastoin keskeisiä päätöksenteon asiakirjoja on pyritty pimittämään julkisuudelta. Esimerkiksi hankintailmoitus ja tämä riskikartoitus jaettiin Helsingin terveyslautakunnassa vain paperilla, jottei niitä levitettäisi julkisuuteen. Erittäin huono käytäntö, mutta valitettavasti ei ainutlaatuinen.

Avoimempi tiedotuskulttuuri olisi varmasti auttanut hanketta paljon. Esimerkiksi väärinkäsitykset 1,8 miljardin euron hinnasta olisivat voineet jäädä syntymättä. Vielä ei ole myöhäistä reagoida tähän riskiin!

4.10 Johtamiseen ja organisointiin liittyvät riskit

”Merkittävimmät johtamiseen ja organisointiin liittyvät riskit johtuvat siitä ettei hankinnan parissa työskentelevien asiantuntijoiden rooleja, vastuita ja valtuuksia ole kuvattu. Tämä riski ei koske vain ohjaus- ja kehittämisryhmään sekä hanketoimistoa vaan kattaa myös kussakin kunnassa työskentelevien asiantuntijoiden toimintaa hankkeessa.”

Suomeksi: konsultin mielestä hanketta ei ole suunniteltu kunnolla, vaan se on kaikilla tasoillaan  tuuliajolla tai vähintään aivan liian keskeneräinen päätöksiä varten.

”Ohjausryhmään kohdistuu riski siitä, että heidän panoksensa hankkeen läpiviemiseen jää pinnalliseksi ”tuen antamiseksi”. Tukemisen sijaan vaativa hanke vaatii johdolta todellista sitoutumista ja panostusta hankalienkin asioiden läpivientiin. Lisäksi johdon tulee investoida aikaansa aihealueeseen perehtymiseen, jolla parhaiten vältettäisiin riski siitä että päätöksiä tehdään vajavaisin tiedoin.”

Suomeksi: konsultin arvio on, että johtoryhmä ei ole tilanteen tasalla.

Liite 1: : Haastatellut asiantuntijat

”Hanketoimisto antoi 21 henkilön listan haastateltavista henkilöistä. Näistä Lasse Lehtonen (HUS) ja Mikko Rotonen (HUS) kieltäytyivät haastattelusta. Tapio Korhosen (Helsinki) kanssa ei saatu sovittua sopivaa haastatteluaikaa hänen kiireisen kalenterinsa vuoksi.”

Siis hankkeen projektipäällikkö ja hanketoimiston keskeisin puuhamies kieltäytyvät riskienhallintakonsulttien haastattelusta. Aikatauluongelmat voi ymmärtää, sellaista sattuu, eikä aina voida jäädä odottamaan jokaista. Mutta suora kieltäytyminen on varovaisesti sanoenkin hyvin erikoista.

Jos aiemmat kriittiset huomautukset voisikin ajatella konsulttien ylivarovaisuudeksi (ja tulkintani niistä ylireagoinniksi), niin tässä kohti viimeistään syntyy kuva, että hankkeen johtamisessa on nyt jotain pahasti ongelmallista.

Mitä raportti ei sano

Vielä merkittävämpää kuin riskianalyysin sisältö on, se mitä siinä ei ole.

  • Teknisiä riskejä ei ole käsitelty juuri lainkaan.Selvästikin tarvitaan vielä erillinen riskianalyysi siitä, miten itse järjestelmän mahdollisiin ongelmiin varaudutaan. Tätä on syytä käsitellä jo ennen hankintaa, koska riskeihin täytyy reagoida jo kokonaisarkkitehtuurissa (jota ei ole ainakaan julkaistu, jos on suunniteltu).
  • Vertailua saman kokoluokan epäonnistuneisiin hankkeisiin (esimerkiksi NHS) ei ole tehty. Miten aiotaan välttää brittien virheet?
  • Vaihtoehtoja yhteen toimittajaan sitoutumiselle toimittajaloukon välttämiseksi ei ole käsitelty.
  • Riskiä, että järjestelmää joudutaan vaihtamaan uudestaan ei ole käsitelty lainkaan. Muuan IT-ostopäällikköä siteeratakseni ”ensimmäinen mitä kysyn on aina, että miten systeemistänne pääsee sitten aikanaan eroon”. Nyt HUS aikoo käyttää satoja miljoonia päästäkseen eroon Uranuksesta. Paljonko Apotista luopuminen tulee maksamaan?

Yhteenveto

Hankkeesta tulee tämän raportin perusteella ongelmallinen kuva. Vaikuttaa siltä, että hanketta ajetaan kuin käärmettä pyssyyn, eikä osaaminen ole riittävällä tasolla näin suureen hankkeeseen. Valittu toimintatapa on koettu ongelmalliseksi, mutta halukkuutta keskustella siitä ei ilmeisesti hankkeen johdossa ole.

Hankkeen johtajaa Lasse Lehtosta lainatakseni, ”Kritiikki ei vaikuta hankintaan”.

Tältä pohjalta täytyy sanoa, että riittävää riskianalyysiä hankkeen käynnistämiseksi ei ole tehty. Sitä ei tosin tarvitakaan, koska jo tämä kevyt analyysi osoitti johtamisessa ja toimintatavoissa merkittäviä puutteita, jotka täytyy korjata jotta hankkeella olisi onnistumisen mahdollisuuksia.