Yksikin Tekes-zombie on liikaa

Sijoittaja Mika Marjalaakso kirjoittaa siitä, miten Tekes-lainat muuttuvat kovin hankaliksi kun tuoteyritys ei menestykään, ja miten tilanteen voisi korjata tavalla joka auttaisi yrittäjiä ja yhteiskuntaa molempia. Kirjoitus on alunperin julkaistu Mikan blogissa

Zombit riivaavat yritysrekisteriä. Kuva flickr

Pekka Soini
Pääjohtaja

Tekes
Kyllikinportti 2, Länsi-Pasila
00101 Helsinki

Ehdotus koskien GoAct Oy:n yhtiön toiminnan päättämistä ja Tekes-lainoja

Kiitämme yhtiön puolesta Tekesiä ja asianosaisia avainhenkilöitä taloudellisesta panostuksesta ja joustavuudestanne matkan varrella. Yhtiön tausta kuvattu yksityiskohtaisemmin jäljempänä.

Nykytilanne

Yhtiö on epäonnistunut teknologian kaupallistamisessa. Yhtiön toiminta on käytännössä päättynyt. Yhtiön hallitus on täysimääräisesti alaskirjannut taseeseen aktivoidut tuotekehityskustannukset.

Yhtiön velat ylittävät moninkertaisesti yhtiön varat. Yhtiöllä on kaksi velkojaa: Tekes ja Keksintösäätiö. Velka Tekesille on 363,702€ ja Keksintösäätiölle 19,500€, molemmat yhteensä 383,202€. Yhtiön varat koostuvat lähes yksinomaan kassavaroista ja ovat yhteensä n. 25,000€.

Ehdotus

GoAct Oy:n hallituksen tavoitteena on ajaa yhtiö alas yhdessä Tekesin kanssa hallitusti ja ammattimaisesti.

Ehdotamme Tekesin johdolle seuraavaa maksu- ja alasajojärjestelyä:

1. Yhtiö maksaa Tekesille välittömästi kaikki taseessa olevat varat vapaaehtoisena lainanlyhennyksenä (n. 20,000€). Tilille jätetään rahaa 5,000€, jolla katetaan yhtiön purkamiseen / alasajoon liittyvät välittömät kustannukset.
2. Tekes jättää lainat kokonaisuudessaan perimättä tai vaihtoehtoisesti muuttaa ne kokonaisuudessaan osakeyhtiölain (624/2006) 12. luvussa tarkoitetuksi pääomalainaksi.
3. Yhtiö puretaan vapaaehtoisen selvitystilamenettelyn kautta.

Perustelut:

1. Yhtiön taloudellinen tilanne ei tule tästä paranemaan ajan kuluessa. Päinvastoin. Nopea alasajo vapaaehtoisen selvitystilan kautta varmistaa maksimaalisen velan takaisinmaksun Tekesille. Selvästi parempi vaihtoehto kuin viivästetty konkurssi.
2. Yksikään toimija noin kolmestakymmenestä startupista, jotka lähtivät rakentamaan sosiaalista kalenteria, ei ole onnistunut. Kaikkien toiminta on päättynyt yhtä yhdysvaltalaista vaatimatonta acquihireä lukuun ottamatta. Pivotointi on joko vaikeaa tai mahdotonta: minimituote kalenteri –domainissa on tavanomaista laajempi ja vaativampi tuotekehitysponnistus ja samanaikaisesti tämän perusteknologian hyödyntäminen kalenteri –domainin ulkopuolella ei ole mahdollista.
3. Työtä on paiskittu rehellisesti ja kovaa. Yhtään kiveä ei ole jätetty kääntämättä. Uutta osaamista on syntynyt. Alasajo viivästetyn konkurssin kautta ei tunnu mielekkäältä vaan pikemminkin raskaalta tapahtuneen jälkeen. Ratkaisulta, jossa kukaan ei voita.
4. Liitteenä olevassa dokumentissa (Liite 1/Dia 21: alkuperäinen visio) on kuvattu alun perin tunnistetut riskit. Facebook –riski realisoitu täysimääräisesti ja vaihtoehtoiset muut tavat rakentaa uusi kalenteriekosysteemi eivät olleet riittävän tehokkaita, jotta niillä olisi ollut aito mahdollisuus haastaa status quo. Facebook –riskin realisoituminen merkitsi myös sitä että kuluttajan kannalta erinomaista käyttökokemusta kalenteroinnille ei ollut mahdollista rakentaa.

Kunnioittavasti,

Espoossa 5.7.2013

GoAct Oy
________________________

Mika Marjalaakso
Hallituksen puheenjohtaja
sarjayrittäjä

_________________________________________________________________________________________________

Ylläoleva ehdotus ei odotusteni mukaisesti mennyt läpi. Tämä oli taustoitusta aiheeseen. Nyt varsinaiseen asiaan. Tässä blogikirjoituksessa on kaksi toisiinsa liittyvää aihetta: Tekesin riskilaina ja pieleen menneen yrityksen jolla Tekes-riskilainaa hallittu alasajo. Pyrin käsittelemään kirjoituksessani seuraavia kysymyksiä:

1. Miksi Tekesin riskilaina on ongelmallinen rahoitusinstrumentti startupille?
2. Miksi ei tunnu intuitiiviselta että Tekes ajaa yhtiön konkurssiin ainoana velkojana?
3. Mitkä ovat eri vaihtoehdot ajaa alas yhtiö, jolla on Tekes-riskilainaa?
4. Miten välttää konkurssimerkintä?
5. Mitkä ovat erityiset haitat yhteiskunnalle?
6. Miten toimintaympäristöä pitäisi kehittää?

Miksi Tekesin riskilaina on ongelmallinen rahoitusinstrumentti startupille?

Eräs hyvä ystäväni ja VC varoitteli minua jo vuosia sitten abstraktilla tasolla että Tekesin velkainstrumentit ovat hankalia ja niitä pitäisi välttää kuin ruttoa. En koskaan saanut häneltä sen tarkempaa kirkastamista että miksi näin on. Enkä siis noudattanut neuvoa.

Jos kaikki menee kuin unissa, niin silloin velkainstrumentti toimii ihan hyvin. Yritysmyyntitilanteessa käteisvaroissaan oleva ostaja maksaa velan pois tai sitten yhtiö maksaa sen itse vahvasta kassavirrastaan. Kaikki taputtavat ja lehdet kirjoittavat ja kuvia otetaan.

Entäs sitten jos yhtiö on jo polttanut sijoittajilta saadun oman pääoman ehtoisen sijoituksen ja taseessa on Tekesin velkaa, mutta yhtiö on löytänyt uuden suunnan? Ei ole aivan maailman helpoin tehtävä löytää uusia sijoittajia, jotka olisivat halukkaita laittamaan sisään uutta rahaa ihan alkuvaiheessa olevaan firmaan, jossa on tase ns. kuralla. Riippuen toki paljon uuden suunnan mielekkyydestä ja siitä onko Tekes velkaa taseessa kymppitonneja, satatonnia tai vaikkapa puoli miljoonaa.

Jos yritys sattuisi löytämään ostajan, joka olisi halukas tekemään acquihiren, niin neuvotteluprosessi menee astetta vaikeammaksi ja hitaammaksi Tekesin velan vuoksi. Tämä ei ehkä ole kovin kriittistä sittenkään.

Minulle henkilökohtaisesti ei ollut ollenkaan intuitiivista että Tekesin riskilainasta ei voi neuvotella vaan se on joko maksettava pois tietyiltä osin, ajettava yhtiö konkurssiin tai sitten synnytettävä zombie.

Miksi ei tunnu intuitiiviselta että Tekes ajaa yhtiön konkurssiin ainoana velkojana?

Tekesin rahoitussopimuksessa on selkeäsanainen ehto, jossa todetaan mikä on ehdoton maksimimäärä lainaa, joka on mahdollista erillistä hakemusta vastaan konvertoida avustukseksi. Aivan. Siellä se sanotaan. Ei vaan osunnut ja uponnut minulle. Tämä siis tarkoittaa karkeasti sitä että jos vaikka Tekes-lainaa on n. 400,000 euroa, niin avustuskonversion jälkeenkin maksettavaa jäisi yli 100,000 euroa. Eli ei toimi.

Jos avustuskonversion jälkeen maksettavaksi jäisi joitakin kymppitonneja, moni jää kituuttamaan. Siis odottelevat ensin vuosikausia. Sitten tekevät hakemuksen, jossa pyytävät jäljellä olevan lainapääoman maksimaalista konversiota avustukseksi. Aikalisä otetaan siksi, jotta hakemus menisi todennäköisemmin läpi Tekesissä. Osa Tekes -käsittelijöistä jopa suosittaa tällaista menettelyä. Ja sitten tehdään konsulttihommia, joilla saadaan velka Tekesille kuitattua. Olisko viisaampi pistää terävät aivot hommiin, josta voi tulla kansantaloudellisesti jotain merkittävämpää?

Mitkä ovat vaihtoehdot ajaa alas firma jolla on Tekes-riskilainaa?

Siinä vaiheessa kun alkoi GoAct Oy:n osalta näyttämään selviöltä ettei siitä mitään tule, aloin tutkimaan mitä alasajovaihtoehtoja olisi tarjolla. Soittelin paljon yrittäjäkavereilleni ja heillä oli kirjavia ja toisistaan poikkeavia käsityksiä siitä mikä olisi mahdollista ja mikä taas ei. Nyt kun olen käyttänyt Tekesin kanssa n. vuoden päivät kalenteriaikaa siitä hetkestä kun yhtiön toiminta tosiasiallisesti päättyi, vaihtoehdot alkavat olemaan selvillä.

1. Maksa Tekesin laina takaisin. Joko täysimääräisenä tai se osa lainasta, joka jää maksettavaksi lainasta-avustukseksi konversion jälkeen. Tämä ei yleensä ole realistinen vaihtoehto, jos jäljelle jäävä maksettava osuus on enemmän kuin 50,000€. Takaisinmaksun jälkeen yhtiö voidaan purkaa, jos muita velkojia ei ole.
2. Konkurssi. Yhtiö puretaan konkurssin kautta. Tämä on Tekesin suosittelema vaihtoehto. Prosessi on tunnettu ja selkeä. Toimitusjohtaja ja hallituksen jäsenet saavat konkurssimerkinnän. Eivät siis välttämättä yrittäjät itse. Valtiokonttori ei saa mitään, koska vähäiset kassavarat menevät tulosiirtoina kirjanpitäjille ja selvitysmiehille.
3. Zombie. Tekesin mukaan Valtiokonttori ei suoranaisesti hae yhtiötä konkurssiin, mutta ryhtyy oikeusteitse perimään saataviaan, jos ne jätetään maksamatta. Tähän vaihtoehtoon osa yrittäjistä päätyy, koska Suomessa konkurssimerkintä edelleen koetaan stigmana ja se pyritään mahdollisuuksien mukaan välttämään. Kuvio menee niin, että Valtiokonttorilta haetaan maksimaalista lykkäystä velan maksuun ja sitten maksellaan korkoja vuosittain ja viivästetään konkurssimerkintää; tarvittaessa annetaan yhtiölle porukalla lainaa, jotta se kykenee selviytymään korkovelvoitteistaan Valtiokonttorille.
4. Velkasaneeraus. Valtiokonttorin on ilmeisesti joissain tapauksissa mahdollista muuttaa saatava pääomalainaksi velkasaneerausmenettelyn (?) kautta, mutta edellytyksenä on se että yhtiön toiminta jatkuu ja edellytykset kannattavalle liiketoiminnalle ovat olemassa. Ei siis mitenkään sovellu alasajoon; edes sen puolesta minkä laki mahdollistaa.

Eli Tekesille ehdottamani vaihtoehto, jossa yhtiö ajetaan alas vapaaehtoisen selvitysmenettelyn kautta ja Valtiokonttorille maksetaan maksimaalinen määrä rahaa ei ole mahdollinen.

Miten välttää konkurssimerkintä?

Jos ei ole fyrkkaa maksaa velkaa takaisin eikä Tekes Zombie kiinnosta, niin silloin vaihtoehdoksi jää konkurssi. Konkurssimerkinnän voi välttää tai sitä voi lievittää seuraavilla keinoilla, joista kaksi viimeistä ovat moraalisesti erittäin arvelluttavia, mutta teknisesti ehkä mahdollisia.

1. Älä ryhdy toimitusjohtajaksi tai hallituksen jäseneksi. Jos ryhdyt, niin viimeistään 6kk ennen konkurssihakemuksen jättämistä jättäydy pois edellämainituista toimista ja valitse tilalle uusi miehistö.
2. Jos olet bisnesenkeli, liity Fibanin jäseneksi ja ilmoita kohdeyrityksesi Suomen Asiakastiedolle, josta Fibanin avulla saar ref -merkinnän.
3. Yhtiön hallituksessa pitää olla vähintään yksi varsinainen jäsen ja yksi varajäsen. Molemmat saavat konkurssimerkinnän. Myös varajäsen. Hanki pari variksenpelätintä hallitukseen ja tee toisesta toimitusjohtaja.
4. Variaatio edellisestä on sellainen, jossa hankit yhden variksenpelätin hallituksen puheenjohtajaksi ja ryhdyt itse varajäseneksi. Ilmoitat uuden kokoonpanon kaupparekisteriin ja hetken päästä eroat varajäsenen tehtävistä. Odottelet 6kk ja variksenpelätin failaa sitten konkurssihakemuksen.

Mitkä ovat erityiset haitat yhteiskunnalle?

Yhteiskunnan kannalta ylivoimaisesti haitallisinta on se että

Terävät aivot jäävät sutimaan tyhjää mutalammikkoon sen sijaan että siirtyisivät seuraavan harjoituksen pariin. On myös erittäin kohtuutonta että alasajovaihtoehtojen kartoitus vie paljon kalenteriaikaa ja siten mentaalista energiaa.

Ei yksikään yrittäjä jolla ei ole miljoonaa euroa tilillä riihikuivaa halua ottaa vapaaehtoisesti konkurssimerkintää. Siitä tulee stigma. Vaikka se on myös voitonmerkki – on se myös meidän yhteiskunnassamme stigma. Ja tämä ei tule muuttumaan kovinkaan nopeasti. Jos tilillä on miljoona euroa riihikuivaa, eri tilanne.

Pitäisi olla Tekesillä suoraviivainen prosessi ilman nyhjäämistä ja ihmettelyä. Ramp down – nappula.

Miten toimintaympäristöä sitten pitäisi kehittää?

Kun yrittäjä tai yrittäjätiimi on päätöksensä tehnyt että ei tästä mitään tule, niin alasajon pitäisi olla suoraviivainen ja nopea prosessi. Ja kaikilla yrittäjillä pitäisi tässä tilanteessa olla yhtäläiset tiedot mikä on mahdollista. Toivon tällä blogillani voivani tuoda helpotusta tähän jälkimmäiseen kysymykseen.

Ratkaisu voisi olla Tekes Roskapankki, jolla olisi seuraavat ominaisuudet:

1. Yhtiön alasajo vapaaehtoisen selvitysmenettelyn kautta. Tulonsiirtojen sijasta kassa kokonaisuudessaan vähennettynä alasajokustannuksilla Valtiokonttorille.
2. Vastuuhenkilöt välttäisivät tarpeettoman konkurssimerkinnän, joka yhteiskunnassamme aiheuttaa edelleen stigman. Stigma ei lisää yrittäjyyttä vaan vähentää sitä. Mitä isompi riski, sitä todennäköisempi epäonnistuminen. Suomi tarvitsee riskinottoa ja lisää epäonnistumisia; koska vain siten syntyy isoja onnistumisia.
3. IPR -kysymykset. Yksi roskapankin keskeisiä tehtäviä olisi standardoidulla tavalla huutokaupata tai jatkojalostaa alasajettavien yhtiöiden IPR:iä (patentteja, koodia …). Näin yhteiskunta voisi hyötyä tehdystä investoinnista. Nyt ei IPR -kysymystä uskalla edes ottaa esille Tekesin kanssa, koska se entisestään monimutkistaisi alasajoa: “Eihän kukaan nyt ainakaan meitä ole kusettamassa?”
4. Eri henkilöt hoitamassa alasajoa. Hyvä eriyttää ja muutoinkin vaatii vähän erilaista mindsettiä ja oman lokeron virkamiesorganisaatiossa.
5. Alasajettujen liiketoimintojen ja IPR:ien yhdistäminen joustavemmaksi. Joskus järkevä vaihtoehto.

Tärkeintä on että yrittäjä voisi nopeasti suunnata energiansa uuteen ja painaa “eject” -nappulaa kun rakettimoottorista loppuu polttoaine. Nyt polttoaineen loppuessa joutuu tekemään täystörmäykseen päättyvän pakkolaskun purjeliitokoneella matkan vain kestäessä.

Ja kun lopulta on päässyt maahan hengissä, lyödään vielä otsaan leima “paska lentäjä”, ja sitten jossain korupuheessa toivotaan että lennä kohta uudestaan, nopeammin ja korkeammalle.

Tekes on toistaiseksi täysin välttämätön kasvuyritysten rahoittaja Suomessa. Olen saanut sieltä lähes aina hyvää palvelua ja nopeasti. Ensimmäinen alasajokokemukseni ei ole täysin positiivinen. Siksi tämä blogikirjoitus. Alla vielä Tekesin perustelut ja olennaiset lainkohdat miksi vapaaehtoinen selvitysmenettely ei ole mahdollinen.

Ohessa pyytämäsi perustelut ja lainkohdat:

Tekesin myöntämä laina on korkotuettua lainaa, jossa yrityksen maksama viitekorkoa alhaisempi korko on valtiontukea. Viitekorko muodostuu Komission julkaisemasta pohjakorosta, johon lisätään yrityksen taloudellisen tilan (Suomen Asiakastiedon reittaus) perusteella korkomarginaali, jota korotetaan 2,5 %-yksikköä, jos laina on pääomalainaa. Lainan korko on tällä hetkellä 1 %, jota korotetaan 2 %-yksikköä, jos laina on pääomalainaa. Pääomalainan korkotuki on siis 0,5 %-yksikköä suurempi kuin vieraan pääomanehtoisen lainan korkotuki. Korkotukea kertyy joka päivä nostetulle pääomalle. Lisäksi korkotukea syntyy, kun takaisinmaksu ei riipu vain laina-ajasta vaan myös yrityksen taloudellisesta tilasta.

Laki yritystuen yleisistä ehdoista (786/1997) 5 § 1 momentti: “Yritystukea voidaan antaa vain sellaiseen elinkeinotoimintaan, jolla arvioidaan olevan edellytykset jatkuvaan kannattavaan toimintaan.” Kun laina muutetaan pääomalainaksi, korkotuki (=valtiontuki) nousee 0,5 %-yksikköä, joten muutos voidaan tehdä vain, jos yrityksen harjoittamalla elinkeinotoiminnalla arvioidaan olevan edellytykset muodostua kannattavaksi.

Lainan muuttaminen pääomalainaksi ei ratkaise ongelmaa. Yritys voidaan purkaa ilman konkurssia vain, jos sen varat riittävät kaikkien velkojen (myös pääomalainojen) maksuun. (Osakeyhtiölaki (624/2006) 20 luku 7 § 2 momentti: “Jos selvitystilassa olevan yhtiön varat eivät riitä sen velkojen maksamiseen, selvitysmiesten on haettava yhtiön asettamista konkurssiin.”

Miten tietojärjestelmän lisäarvon voisi laskea?

Kun uusia tietojärjestelmiä tehdään, niiden soisi mieluummin kehittävän organisaation prosesseja kuin toistavan niitä entisellään tai jopa huonontavan niitä.Torstaina 5.9. järjestettiin FlowIT-seminaari. Aurinkoisessa Poliisien kesäkodissa oli julkisten tietojärjestelmien äärellä ilahduttavan monipuolinen joukko psykologisen ergonomian, taloustieteen ja käytettävyyden tutkijoita, tietojärjestelmätoimittajia ja julkishallinnon ostajia.

Yksi hankkeen tutkijoista, Työterveyslaitoksen Virpi Kalakoski, havahdutti ajattelemaan radikaaleja. Nythän asiantuntija työskentelee usein tietojärjestelmän palvelijana, muistelee pitikö syöttää # vai ”, jotta saa tiedon runnottua järjestelmään ja pääsee vihdoin tulostettuaan ja toimiston hiljettyä ajattelemaan, mitä syötettyjen tietojen kokonaisuudesta oikeastaan seuraa. Parhaista yrityksistä huolimatta nyt ei toteudu edes tilanne, jossa järjestelmä hoitaisi rutiinit ja vapauttaisi ihmisen ongelmanratkaisuun. Päin vastoin järjestelmien käyttäminen aiheuttaa usein lisää henkistä kuormaa. Kuten Kalakoski väläytti seminaarissa, otollisimmillaan tietojärjestelmät kuitenkin auttaisivat tietotyössä, ajattelemisessa tai ongelmanratkaisussa.

Vau. Yksinkertainen alkuperäinen idea tuntuu nykytodellisuuteen nähden mullistavalta.

Sama ajatus organisaatiokehityksen puolella on, että uusia tietojärjestelmiä tehtäessä surkean monet niistä vain sementoivat vanhat prosessit koodiin tai jopa huonontavat niitä. Tämä ongelma on hyvin inhimillinen. Kuitenkin ohjelmistokehitys parhaimmillaan voisi rikkoa olemassa olevat toimintatavat ja mahdollistaa uusia. Tällaisen diruptiivisen työn ostaminen on käytännössä älyn ostamista, jopa innovaation. Siksi tarvittavan osaamisen tunnistaminenkin on haastavaa, puhumattakaan sen mittaamisesta.

Keskusteluissa mielikuvitus alkoi kuitenkin laukata.

TTL:n laskentamallitutkija Tiina Vihtonen esitteli elinkaarimalleja, joilla lasketaan kustannukset tietojärjestelmän eri vaiheissa – pystytettäessä, käyttöönoton hetkellä, jatkokehityksen aikana. On helppo tunnistaa, miten eri laadun ulottuvuuksilla kuten käyttöliittymän intuitiivisuudella tai järkevästi toteutetulla modulaarisuudella, on vaikutus eri vaiheiden kustannuksiin.Millä sitten on vaikutus tietojärjestelmän synnyttämään liiketoiminta-arvoon? Sillä, että järjestelmästä on heti kehityksen alussa jokin uudentyyppinen ominaisuus oikean toiminnan käytössä? Sillä, että joitakin prosesseja voidaan oikaista tai jättää kokonaan tekemättä? Sillä, että löytyy jokin kokonaan uusi tekemisen tapa jolla syntyy paljon aikaisempaa tyytyväisempiä asiakkaita? Ja millä ihmeellä tämän kaiken voisi laskea?

Jonkinlaisia laskentamalleja tarvittaisiin, jotta oikeansuuntaisia päätöksiä alkaisi syntyä. Optimaalisimmillaan tietojärjestelmät voisivat nimittäin auttaa oivaltamaan liiketoimintaa uudessa valossa, luomaan sille uuden käänteen.

Kuinka suomalainen tietoyhteiskunta korjataan?

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.

• Yhä uusia datasettejä avataan jatkuvasti
• Ketterät kehitysmallit alkavat olla yksityisellä puolella standardi, ja myös julkisen sektorin onnistumistarinoita löytyy
• Kunnatkin kehittävät yhdessä palveluita avoimena lähdekoodina
• Omituiset ”maan tavat” kyseenalaistetaan julkisesti
• Maan hallitus haluaa avata datat
• Helsinki perustaa kaupunginhallituksen jaoston kaivamaan IT-ongelmat esiin.

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: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 kautta” perustuen 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.

Julkaistu alkujaan Otson blogissa

5 asiaa, jotka julkishallinnon pitäisi oppia IT:stä

Kirjoitan uudessa Sytyke-lehdessä viidestä tietotekniikan trendistä, joita julkishallinnon on syytä seurata huolella. Artikkeli laajennettuna lähteillä alla.

Media keskittyy päivittelemään valtion tietojärjestelmätyön korkeita kustannuksia vaikka todellinen ongelma on järjestelmien toiminnallisuudessa ja niiden tekotavassa. Liian monet niistä pyrkivät toimimaan vähän parempina arkistokaappeina, teollisen ajan jäänteinä, jossa virkamiehet ovat keskipisteessä ja tietojärjestelmän tehtävänä on välittää lomakkeita ja pitää ne tallessa.

Tietojärjestelmien toiminnallisuuden ja niiden tekotapojen muuttaminen on ensiarvoisen tärkeää. Elämme kansakuntien globaalissa kilpailussa, jossa Suomi maana joko kuihtuu tai kukoistaa. Hyvillä järjestelmillä luodaan nykyistä parempi elinympäristö kustannustehokkaasti. Nykyiset järjestelmät karkottavat menestyvät yritykset maihin, jotka ovat ketterämpiä ja ottavat ajan vaatimukset paremmin huomioon kuin Suomi.

Tämä tietojärjestelmäongelma on vaikeasti korjattava. Tietotekniikan hyödyt jäävät lupauksiksi, jos palveluprosesseihin ei kosketa. Hyvillä järjestelmillä valtion toiminta voitaisiin uudistaa vastaavasti kuin yksityisellä puolella. Pankkisali ei enää muistuta 1970-luvun pankkia eikä rautakaupalla ole mitään tekemistä lapsuuteni rautakaupan kanssa. Molemmissa on muutettu palvelumallia ja sen myötä tietojärjestelmiä. Samaa palvelukehitystä ei riittävästi näy julkisella puolella. Lääkäri on lääkäri ja tuomari on tuomari.

Valtiolle voi käydä kuin Nokialle, jos suuntaa ei muuteta.

Valtiollisessa mattimyöhäisyydessä on etunsakin. Voimme tutustua ulkomaisiin esimerkkeihin ja hyötyä niiden parhaista opeista. Esittelen viisi merkittävää trendiä, joista Suomessa kannattaisi ottaa mallia.

1. Avoin lähdekoodi

Avoin lähdekoodi tarkoittaa asiakaskohtaisten ohjelmien lähdekoodin vapaata jakamista. Tämä on ollut enemmän sääntö kuin poikkeus tiedemaailmassa jo kymmeniä vuosia, mutta toimialan siiloutuneen luonteen vuoksi nämä hyvät tavat eivät levinneet kauas. Hyvänä esimerkkinä on CERN-tutkimuskeskuksessa keksitty www-ympäristö ja sen ympärille avoimen lähdekoodin pohjalta muodostuneet selaimet ja palvelimet.

Avoin lähdekoodi on vallannut markkinaosuutta hivuttautumalla yhä uusille aloille. Hyviä esimerkkejä sen toimivuudesta löytyy varsinkin verkkopalveluista. Lähdekoodinsa avoimesti jakavat esimerkiksi www.whitehouse.gov Yhdysvalloissa ja www.gov.uk Britanniassa. Nämä molemmat ovat hyviä esimerkkejä verkkopalveluista, joissa parhaat käytännöt ovat muiden käytössä sekä omalla maaperällä että kansainvälisesti. Yhä useammissa maissa avoin lähdekoodi on määritelty suositelluksi tavaksi hankkia valtion tietojärjestelmiä.

Avoin lähdekoodi on samalla ohjelmistoalan luontevin yhteistyötapa. Kun kaikki laittavat reseptinsä näkyville, on helpompi siirtyä korkeammalle abstraktio- ja tehokkuustasolle. Kaikki hyötyvät.

Avoin lähdekoodi sopii erityisen hyvin kunnalliselle puolelle. Yhdessä kunnassa kerran tehty työ auttaa muita kuntia vastaavissa tilanteissa.

Linkkejä:

• Government mandates ’preference’ for open source (US)
• Open Source for America
• Interview: GDS head Mike Bracken on Estonia’s digital services
• NASA open source 

2. Ketterät menetelmät

Ketterä eli iteratiivinen kehitys on ollut varsinkin web-hankkeissa valtavirtaa jo vuosia. Ketteryydestä puhuu nyt myös kansainvälinen julkishallinto. Anglo-amerikkalaiset lainsäätäjät ovat tehneet määrätietoista työtä ketteryyden puolesta julkisella sektorilla. Ketteriä menetelmiä käytettiin äskettäin pelastamaan katastrofaalinen, satojen miljoonien hintainen FBI:n Sentinel-vesiputoushanke. Englannissa kansalaisille tehtävien kaikkien uusien palvelujen pitää perustua palvelumuotoilumalliin, jossa palvelu kehitetään ketterästi ja vielä betatestataan loppukäyttäjillä ennen tuotantoonsiirtoa.

Ketterä hankintamalli on vaatinut yksityisellä puolella muutoksia toimintatavoissa ja uusia roolituksia. Samoin käynee julkishallinnossa. Ketterä kehitystiimi on kuin ajopuu ilman määrätietoista asiakkaan tuoteomistajaa. Uusia tuoteomistajia tarvitaan satapäin. Toivottavasti nämä löytyvät virkamiehistä; uutta tuoteomistajakonsulttien armeijaa tuskin kukaan haluaa.

Ketterissä menetelmissä suurin muutos on tuoteomistajan ja päätöksentekijän välillä. Hankkeen ensimmäisessä vaiheessa etsitään palvelun sopiva muoto, usein yrityksen ja erehdyksen kautta. Ketterä hanke etsii rehellisesti uutta toimintamallia perinteisen vesiputousmallin sijaan. Vesiputous sopii rakennusalalle, mistä se on solahtanut IT-alalle. Ketteryyttä vaaditaan aidosti eikä vain termien tasolla, opettavat amerikkalaiset virkamiehet. Ketterissä menetelmissä asiakkaan pitää olla tiimin iholla koko hankkeen ajan.

Briteissä on asetettu tavoitteeksi, että puolet IT-hankkeista on ketteriä jo parin vuoden sisällä. Muutos on merkittävä jäykkien PRINCE- ja ITIL-mallien kotimaassa.

Linkkejä:

• FBI Sentinel Programme Saved by Agile?
• Agile Adoption in the Public Sector: FBI and Port of Rotterdam
• Agile government: What the UK can learn from the US
• Effective Practices and Federal Challenges in Applying Agile Methods
• NAO: Governance for Agile delivery
• Government Service Design Manual (UK)

3. Pilvipalvelut

Pilvipalvelut eli verkosta vuokratut IT-palvelut tehostavat tietotekniikan kehitystä ja ylläpitoa. Ketterät menetelmät vaativat ketterät pilvipalvelimet. Entä jos palvelu loppujen lopuksi tarvitsee aivan eri palvelimet kuin alun perin ajateltiin? Montako viikkoa tai kuukautta palvelimia pitää odottaa?

Ketterät menetelmät ja avoin lähdekoodi helpottavat uusien hankkeiden aloittamista valtavasti: ei enää pitkiä vuosien mittaisia määrittelyhankkeita eikä miljoonalisenssejä. Pilvipalvelut sopivat nykyiseen kokeilukulttuuriin kuin nenä päähän. Pilvipalvelut ovat käytössä heti ja niitä voi muokata kunnes oikea palvelukokonaisuus löytyy. Hyvässä pilvipalvelussa tietokantoja ja muita moduleja saa tuntivelotteisesti. Uuden rakentaminen tällaisista duplo-palikoista on paljon tehokkaampaa kuin totuttu palvelujen nyhrääminen.

Kokeilukulttuuriin sopii pilvipalveluissa myös se, että niistä pääsee helposti eroon. Jos ei tullut takkia eikä kintaita, ei palvelimesta ja sen ylläpidostakaan tarvitse maksaa.

Linkkejä:

• Info.apps.gov, information about how Cloud Computing can help create sustainable, more cost-effective IT Services for the Federal Government
• NIST Cloud Computing Program
• Digital by Default Service Standard

4. Avoin tieto

Avoin tieto tarkoittaa organisaation tietomassojen jakamista verkossa raakamuodossa muiden jatkojalostettavaksi. Tässäkin amerikkalaiset ovat muiden edellä; ei Piilaakso sattumalta siellä sijaitse. Esimerkiksi maailman Internet-sääpalvelut ovat perustuneet alusta asti amerikkalaisten ilmaiseksi jakamaan tietoon. Tätä toimintatavan etumatkaa on vaikea kuroa kiinni. Amerikkalaisessa data.gov-palvelussa on jo yli 400.000 datajoukkoa vapaasti käytettävissä – ja tiedon hyökyaalto kasvaa koko ajan.

Kansainvälisisten tutkimusten mukaan avointa tietoa käytetään eniten julkishallinnossa naapurihallinnonaloilla. Sen sijaan että tutkimustietoa pitäisi ruinata naapuriosastolta, sen voi hakea suoraan verkosta ilman hankalia korvauksia.

Avoin tieto tehostaa julkishallinnon tiedonnälkää ja luo ympärilleen ekosysteemejä tiedon jalostamiseen.

Linkkejä:

• NYC BigApps 2013
• The White House: Connecting citizen developers with the tools they need to unlock government data.

5. Big data

Big datan eli valtavien tietovarantojen käyttäjänä valtio on pitkään ollut edelläkävijä. Sääennusteet, tiedustelu ja sotilassimulaatiot eivät olisi onnistuneet ilman supertietokoneita.

Hallinto perustuu tiedon laajamittaiseen keräämiseen ja sen jalostamiseen päätöksenteon pohjaksi. Tässä on helposti monta rikkinäistä puhelinta jonossa. Big datan parhaat käytännöt sopivat hallinnon käyttöön kuin valettu. Big data -järjestelmissä tietoa ja sen esitysmuotoja yhteismitallistetaan keskitetysti niin, että lähtötietojen suhteen ei tarvitse olla ihan tarkka. Näkisin, että big datalle on käyttöä ministeriössä kuin ministeriössä.

Linkkejä:

• The Mayor’s Geek Squad
• Data.gov
• TechAmerica Foundation Big Data Commission
• Feds to Spend Big on Big Data
• Democratizing Big Data to Bring Government Ahead of the Curve
• Government must improve big data strategy to realise savings of £33bn
• Think Again: Big Data

Uusi toimintatapa

Yhdessä näistä opeista muodostuu toimintatavan muutos, jossa kokonaisuus on enemmän kuin osiensa summa.

Valtiot ympäri maailman, Suomi muiden mukana, käyvät tällä hetkellä ihastelemassa Viron moderneja tietoteknisiä ratkaisuja. Muutaman vuoden ponnistus ja määrätietoinen pyrkimys uuteen toimintatapaan voisi nostaa Suomen julkishallinnon tietotekniikan eturintamaan.

Kirjoittaja:

Petri Aukia (Tekn.lis.) on Codento Oy:n toimitusjohtaja ja osakas. Pilvipalvelujen hyödyntäminen, vaativat arkkitehtuurit sekä ketterä hankinta ovat asiakasorganisaatioiden Top3-listalla juuri nyt. Petrillä on 20 vuoden kokemus tietojärjestelmien ja -arkkitehtuurien kehittämisestä sekä yksityisellä että julkisella sektorilla. Petri on myös aktiivinen kasvuyritysten mentori ja Ohjelmistoyrittäjät ry:n jäsen.

petri.aukia (at) codento.com, +358 400 438610, Twitter @aukia

Julkaistu alkujaan Codenton blogissa

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.

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.

Julkaistu alkujaan Codenton blogissa

Miten gaussin käyrä liittyy teknologiastrategiaan?

Fyysisten laitteiden maailmassa on ilmeistä tarvitaanko F1-kilpuria vai ihan vaan tämän vuoden vuosimallia olevaa perheautoa, mutta ohjelmistopuolella tilanne ei ole ollenkaan niin suoraviivainen.

Tilanteesta riippuen sekä konservatiiviselle Java-sovellukselle että uusimpia tekniikoita käyttävälle HTML 5 -sivustolle on paikkansa. Mutta milloin on minkäkin tekniikan aika? Kuka tarvitsee uusimpia työkaluja?

Kirjoitan aiheesta, sillä uusien asiakkaiden kanssa käyn toistuvasti samoja keskusteluja työkaluista. Onko yhtä selvää Tekniikan Maailman testivoittajaa vai onko sittenkin niin, että työkaluvalinta on tapauskohtaista?

Tarvitsetko uusinta uutta?

Uusimpien työkalujen ja jo käytössä koeteltujen ohjelmointikielien käyttäjien on usein vaikeaa ymmärtää toisiaan. Kumpikin on tottunut omaan katsantokantaansa ja toisen näkökulma tuntuu vieraalta. Mistä valinnassa oikein on kyse? Onko toinen koulukunta ihan väärässä? Sama konflikti on jatkunut jo pitkään, eikä vieläkään ole löydetty yhteisymmärrystä siitä, millä työkaluilla softaa kannattaisi tehdä.

Uusien ideoiden omaksuminen

Alkuperäisen tutkimustuloksen löysi vuonna 1948 maanviljelijä kuvan oikeassa laidassa, viimeisten farmareiden löytäessä idean kahdeksan vuotta myöhemmin.

Tässäkin tilanteessa on kyse on uusien ideoiden omaksumisen lainalaisuuksista. Aiheen popularisoi riskisijoittaja Geoffrey Moore kirjassaan Crossing the Chasm vuodelta 1991. Uudet ideat eivät nouse kerralla kaikkien tietoisuuteen vaan valuvat ensimmäisten käyttäjien kautta hiljalleen kaiken kansan hyödyksi.

Uutena mainostettu malli on paljon vanhempi ja yleispätevämpi kuin voisi kuvitella. Uuden teknologian omaksumista tutkittiin vuonna 1957 Yhdysvaltain keskilännessä helppolukuisessa ja yllättävän kiinnostavassa Adopters of New Farm Ideas -julkaisussa.  Omaksumisen nähtiin noudattavan gaussin käyrää.

Alussa tekniikan ottavat käyttöön vain harvat, heitä seuraa vähän suurempi joukko ja vasta sitten valtavirta. Uusien siemenlajien ja uusien ohjelmointikielien välillä on enemmän yhteistä kuin ensi hätään luulisi. Tarkemmin ajateluna ei ole ihme, että moni suuryrityksen johtaja on vapaa-ajallaan myös menestynyt kartanonherra.

Innovaattorit

Niin maataloudessa kuin ohjelmistotekniikankin alalla innovaattorit näkevät uuden teknologian mahdollisuudet ja ovat valmiit muuttamaan yrityksessään paljonkin saadaakseen uusimman uuden käyttöön. Innovaattorit vievät uudet keksinnöt nopeasti tuotantoon ja käyttävät osin keskeneräisiäkin työkaluja hyötyäkseen keksinnöistä. He ovat uuden teknologian kannalta tärkeitä niin maanviljelyksessä kuin tietotekniikassakin.

Mallin mukaan innovaattoreita on vain noin kaksi prosenttia väestöstä. He kuluttavat keskimääräistä enemmän aikaa ideoiden etsimiseen ja kokeiluun, mutta toisaalta saavuttavat näin kilpailuetua. Suomalaisessa maataloudessa innovaattorit ovat kasvattaneet monia kannattavia suurtiloja rohkeiden kokeilujensa kautta.

Valtavirta

Valtavirtaan kuuluvilla ei ole mahdollisuutta omaksua keskeneräistä uutta teknologiaa. Kyse on yhtä lailla asenteesta sekä priorisoinnista. Uutta otetaan käyttöön siinä vaiheessa, kun sen käyttö on kilpailijoiden toimesta jo hyvin todistettu.  Tekniikkaa ei oteta käyttöön ennen kuin sen rajat tunnetaan hyvin ja se sopii olemassa olevaan rakenteeseen. Tuolloin tekniikan käyttöönotto koetaan helpoksi ja vaarattomaksi, sillä hyödyt ovat ilmeisiä ja vähällä vaivalla saavutettavissa.

Miten gaussin käyrä liittyy teknologiastrategiaan?

Omaksuminen on kategorisoitu sekä alkuperäisessä maanviljelystutkimuksessa että Geoffrey Mooren julkaisussa suoraan tilastollisen keskihajonnan eli sigman mukaan.

Innovaattorit ovat pääsääntöisesti ratkaisemassa ongelmia, joita aiemmalla tekniikalla ei voitu ratkaista. He löytävät markkinarakoja, joiden täyttäminen tuo nopeaa ja kannattavaa kasvua. Innovaattorit valitsevat uusimpia työkaluja saadakseen ideansa kilpailijoita nopeammin valmiiksi. Esimerkiksi pilvipalvelujen ja uusien ohjelmointikielien avulla etsitään voittavaa asemaa markkinoilta.

Valtavirrassa uivalla yrityksellä on turvallinen markkinaosuus ja tutut asiakkaat, joille tarjota ratkaisuja tunnettuihin ongelmiin. Valtavirran rooli on ylläpitää innovaattorien ja muiden propellipäiden aikanaan kehittämiä systeemejä. Tämä on tehnyt heistä varovaisia. Valtavirrassa toimivalle ylläpidettävyys, tuttuus ja virheettömyys ovat arvossaan.

Ohjelmistoalalla tarpeet vaihtelevat suuresti. Harva työkalu sopii sekä perheauton että F1:n luomiseen. Turvallista taloushallinnon järjestelmää tutuille asiakkaille tehdään edelleen pääsääntöisesti Javalla. Se ei ole työkaluista ketterin eikä seksikkäin, mutta osaamista löytyy kaikkiin toiminnan osiin. F1:stä, eli uusinta uutta, tehdään harvoin Javalla. Osaavissa käsissä ohjelmistokielistä Python, Ruby, Scala tai Javascript tuottaa nopeammin tuloksia. Uusimman uuden tekijätiimi joutuu tosin ajoittain etsimään tekijöitä kissojen ja koirien kanssa, kun valitun alustan osaajia ei löydykään helposti.

Työkaluvalintojen arvostelussa saa olla kieli keskellä suuta. Kun ohjelmistoa tehdään mahdollisimman nopeasti, tarvitaan erilaiset työkalut kuin silloin, kun jokainen koodirivi jää elämään omaa elämäänsä vuosiksi tai vuosikymmeniksi.

Julkaistu alkujaan Codenton blogissa

6 vinkkiä turvallisen ohjelmiston tekoon

Turvallisen ohjelmiston tuottaminen poikkeaa tavallisesta ohjelmistokehityksestä yhtä paljon kuin kassakaapin valmistaminen Ikean vaatekaapin kasaamisesta. Vaikka tehtävä on päällisin puolin sama, yhteisiä nimittäjiä ei juuri ole.

Suuri osa turvallisen ohjelmiston kehittämisen nyrkkisäännöistä ovat tuttuja muutenkin: hyvin suunniteltu on puoliksi tehty, kokeneet kehittäjät tekevät vähemmän virheitä ja käytössä koetut perinteiset työkalut sopivat uusia trendituotteita paremmin turvatuotteiden tekoon. Lisäksi turvallisella kehittämisellä ei ole juuri merkitystä, ellei tuotteen perään katsota koko sen elinkaaren ajan.

Seuraavat neuvot eivät sen sijaan ole niin itsestäänselviä, vaikka kehittäminen olisi muuten hyvin näpeissä:

1. Älä tee tietoturvaa väkisin. Parhaat softaideat eivät edellytä kovin hurjaa luottamusta tuotteen turvallisuuteen. Monet uudet tuotteet on tehty niin, että vaikein turvaosuus on suosiolla jätetty toiseen palveluun, jolloin itse tehty osio voi jäädä vaatimattomammalle turvatasolle. Tällaisia hyviä ulkopuolisia tunnistautumis- tai maksamisratkaisuja ovat esimerkiksi:
   • Sisäänkirjautuminen  Facebook-tunnistuksella tai
   • verkkokaupan luottokorttimaksupalvelut Luottokunnalta ja Paypal-yritykseltä
2. Älä jätä kynttilää vakan alle. Nosta turva-asiat etualalle, jos et voi niitä välttää. Jos juuri turvallisuus on ostajalle yksi tärkeistä valintakriteereistä, nosta turvan hyvä taso esiin kaikessa toiminnassa. Toisaalta tuotteet, jotka ovat selvästi turvallisempia kuin niiden asiakkaat haluavat, jäävät markkinoilla niiden tuotteiden jalkoihin, joille on osattu valita oikea turvataso. Hyviä esimerkkejä onnistuneista turvallisista tuotteista ovat:
   • Skype (turvallinen puhelu Internetissä),
   • PayPal (turvallinen luottokorttimaksaminen),
   • sekä toki erilaiset tietoturvaihmisille tehdyt tuotteet, kuten suomalaiset F-Securen, SSH:n ja Stonesoftin tuotteet.
3. Myy säästöjä, älä turvaa. Parhaat turvatuotteet tekevät halvasta ratkaisusta turvallisen ja säästävät roppakaupalla rahaa. Internetin yli tehdyt VPN-yhteydet ovat tuhansia kertoja halvempia kuin vanhat kiinteät yhteydet toimistojen välillä. Jos ratkaistava ongelma on riittävän arvokas, turvaosion voi tehdä huolella.
4. Tee valtakunnansalaisuuksille kassakaappi. Jos tärkeää tietoa on käsiteltävä, se pitää tehdä niin pienessä osassa ohjelmistoa kuin mahdollista. Esimerkiksi sosiaaliturvatunnusten käsittely- ja tallennuskoodia ei pidä levitellä ympäri ohjelmistoa, vaan se pitää säilyttää ainoastaan harvoissa ja rajatuissa kohdissa.
5. Käytä Abloy-lukkoja. Älä tee itse salausta tai muita vaativimpia tietoturvan osia vaan hanki ne valmiina ja testattuina ratkaisuina. Ohjelmiston turvallisuuden pitää perustua valmiisiin ja varmasti toimiviin komponentteihin, sillä eihän arvokiinteistöillekään suunnitella uusia lukkoja. Hyviä turvaohjelmistoja saa sekä kaupallisina tuotteina että avoimen  lähdekoodin ratkaisuina.
6. Oven kolmas lukko on usein turha. Tietoturva-asioissa joutuu aina valitsemaan mitä tehdään ja mitä jätetään tekemättä. Vain poikkeuksellisissa sotilassovelluksissa voidaan tehdä kaikki asiantuntijoiden kaipaamat turvatoimet. Liika panostus yhteen turvan osa-alueeseen on usein merkki väärästä resurssien suuntaamisesta.

Tietoturvallisen ohjelmiston tekeminen vaatii pitkällistä syventymistä. Suosittelen seuraamaan alan ajattelijoiden tajunnanvirtaa Twitterin kautta, he puolestaan nostavat esiin sekä alan uusimpia trendejä että vanhoja klassikoita omassa virrassaan. Itse seuraan Twitterissä muun muassa seuraavia tietoturvan kovia luita:

• Mikko Hyppönen (@mikko)
• Gunnar Peterson (@oneraindrop)
• Per Thorsheim (@thorsheim)
• Mikko Saario (@midisFI)
• Antti Vähä-Sipilä (@anttivs)
• Jari Pirhonen (@japi999)
• Troy Hunt (@troyhunt)

Tietoturvallisen ohjelmiston rakentaminen on yhtä vaikeaa kuin menestyselokuvan tuottaminen. Harvat siinä onnistuvat, mutta onnistujat palkitaan ruhtinaallisesti.

Julkaistu alkujaan Codenton blogissa

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

Toimittajaloukku ja kuinka se vältetään

Taannoinen kirjoitukseni sairaaloiden tietojärjestelmistä sai jonkin verran huomiota, ja myös Hesari innostui aiheesta eilen kirjoittamaan. Eniten huomiota on saanut Accenturen toiminta ja sen moraaliset aspektit. Se on lopulta kuitenkin vain sivujuonne. Oikea ongelma on siinä, miten tietojärjestelmiä ostetaan, ei siinä miten niitä myydään.

Tilanne ei juuri muuttuisi, vaikka järjestelmäksi valittaisiinkin Cerner ja toimittajaksi Logica, tai vaikka Effica ja Tieto. HUS on joka tapauksessa ostamassa yhtä järjestelmää yhdeltä toimijalta, joka samainen toimija tulee sitten toimittamaan myös järjestelmän kustomoinnit, uudet versiot ja tulevaisuudessa tarvittavat lisätoiminnallisuudet. Koska on vain yksi toimittaja, joka voi ne toimittaa.

Tätä kutsutaan toimittajaloukuksi (engl. vendor lock-in). Se tarkoittaa tilannetta, johon varomaton tietojärjestelmän ostaja joutuu valittuaan järjestelmälle toimittajan: kaikki muutostyöt on pakko ostaa samalta toimittajalta, ja tämä voi rahastaa niillä lähes miten haluaa. Myös huono laatu ja hitaus ongelmien korjaamisessa kulkevat yleensä käsi kädessä toimittajaloukon kanssa.

Alalla vuosikymmeniä toiminuttu myyjää lainatakseni, ”Suomessa on haluttu rakentaa järjestelmä, jossa tuotteet myydään halvalla ja raha tehdään ylläpidolla sekä muutostöillä”. Toimittajan vaihtaminen ei siis ratkaise ongelmia.

Koska koen tietynlaista vastuuta myös ratkaista esiin nostamani ongelmat, esittelen tässä kolme tapaa, jolla HUS voisi yhden toimittajan loukun välttää.

Lähtökohta on, että tietojärjestelmä ei koskaan ole valmis tuote. Sitä ei voi ostaa valmiina ja ”vain käyttää”, vaan käyttöönotto on raskas prosessi, jossa sekä muutetaan järjestelmää että muutetaan organisaation toimintatapoja. Ja käyttöönoton jälkeen muutostarpeet jatkuvat. Unohtuneita tarpeita huomataan, ja uusia syntyy.

Mutta tässä ne kolme optiota HUS:lle

Optio 1) sorsat käteen

Mikäli HUSilla olisi pääsy ja käyttöoikeus ostamansa järjestelmän lähdekoodiin, voisi sairaanhoitopiiri teettää haluamansa muutokset kenellä haluaa, tai vaikka tehdä ne omassa IT-organisaatiossa. Tällöin muutostyöt eivät olisi yhtä hitaita ja kalliita, koska niitä tilattaessa vallitsisi ainakin jossain määrin aito kilpailutilanne.

Toki järjestelmän alkuperäisellä tekijällä (ja muilla sen kanssa työskennelleillä) olisi etulyöntiasema, mutta se olisi merkittävästi nykytilannetta pienempi. Toimittajan vaihtamisen kustannus ei olisi satoja miljoonia, vaan ehkä vain satoja tuhansia, joten mahdollisuudet rahastamiseen tai slarvaamiseen olisivat selvästi pienemmät.

Tämä on se ratkaisu, jota aiemmassa kirjoituksessani ehdotin. Käytännössä tämä vaatisi yhtä lisäehtoa tietojärjestelmän kilpailutukseen: ”Osana kauppaa ostaja haluaa järjestelmän koko lähdekoodin, tarvittavat ohjeet ja koulutuksen sen käyttöön sekä oikeuden tehdä itse tai teettää muutostöitä vapaasti haluamallaan toimittajalla.” Juridisesti sitovana ehto olisi varmasti paljon pidempi, mutta olennainen sisältö on tuossa.

On epävarmaa, suostuisivatko ulkomaiset toimijat kuten Epic tai Cerner tällaiseen ehtoon. Voi olla, että eivät. Kotimaiset toimijat luultavasti suostuisivat: jos kukaan ei heiltä enää ostaisi tietojärjestelmää kuin sikaa säkissä, joutuisivat he myymään sitä sisuskaluineen kaikkineen. Palkinto on liian suuri, jotta Tieto tai Logica heittäisi pyyhkeen kehään.

Optio 2) open source

Toinen vaihtoehto on avoin lähdekoodi. HUS voisi vaatia ehtona, että ostettavan järjestelmän koko lähdekoodi julkaistaan avoimella lisenssillä. Tämä poikkeaa ensimmäisestä vaihtoehdosta siinä, että myös muut kuin HUS pääsisivät käyttämään koodia. Eniten hyötyisivät muut sairaanhoitopiirit, jotka saisivat HUSin järjestelmän käyttöönsä ilmaiseksi, mutta myös HUS hyötyisi, koska avoimuus tehostaa kehitystyötä monin tavoin. Sitä paitsi HUS saisi sitten muiden muutostyöt myös itselleen käyttöön.

Kehityksen lähtökohtana voisi toimia jokin nykyinen potilastietojärjestelmä, valmis avoimen lähdekoodin järjestelmä, kuten USA:n veteraaniterveydenhuollon VistA, tai se voitaisiin kasata tyhjältä pöydältä. Yksikään ratkaisu ei ole ongelmaton. Nykyiset järjestelmät ovat juuri niitä, joita kovasti kritisoidaan, eikä toimittajien halukkuudesta avata koodinsa ole mitään varmuutta. VistA taas sisältää samaa arkaaista MUMPS-kieltä kuin EPICkin eikä amerikkalaisena välttämättä sovellu suoraan Suomen terveydenhuolto-organisaatioon. Ja tyhjältä pöydältä kehittäminen on aina työlästä ja osin riskaapelia.

Optio 3) pilkonta, rajapinnat ja vahva yhteistyö

Tanskassa terveydenhuoltoalan tietojärjestelmät ostetaan pienehköissä osissa: yksi järjestelmä kerrallaan. Eri sairaanhoitopiirit ostavat kuka mistäkin. Alan toimijat – niin yritykset kuin viranomaisetkin – määrittelevät yhteistyössä rajapinnat ja tiedonsiirtostandardit, joita noudattaen järjestelmät toimivat sulavasti yhteen. Kokonaisuutena Tanskassa on ”ekosysteemi” terveydenhuoltoalan tietotekniikkaa tekeviä yrityksiä.

Paperilla järjestelmä kuulostaa melko samantapaiselta kuin Suomessakin. Erona on, että Tanskassa se toimii, kun suomalainen terveydenhuollon IT on katastrofi. Juutit siis ilmeisesti tekevät jotain oikein.

Jari Forsström et al kuvaavat raportissa ”Terveydenhuollon tietojärjestelmät ja Suomi” miten Tanskan ja Ruotsin vastaavat alat toimivat, sekä esittävät näkökantoja siitä, miten potilastietojärjestelmien uudistusta tulisi Suomessa tehdä. Heidän keskeinen johtopäätöksensä on:

1. Terveydenhuollon kokonaisjärjestelmään sisältyy suuria riskejä.
2. Hajautetuista ratkaisuista, ohjelmistojen ekosysteemistä, on pohjoismaista hyviä kokemuksia.
3. Terveydenhuollon tietojärjestelmäkustannuksista noin puolet koostuu henkilötyöstä, joten toimialalla on merkittävä työllistävä vaikutus. Suomalaisen IT-osaamisen taso on korkea ja sitä tulisi voida hyödyntää näin mittavassa kansallisessa hankkeessa.

Käytännössä Suomessa Terveyden- ja hyvinvoinnin laitoksen (THL) pitäisi ottaa vetovastuu ja johtava rooli sairaanhoidon tietojärjestelmäekosysteemin kehittämisestä. Samaan tapaan kuin Tanskan Medcomilla on. THL tosin on taustaltaan tutkimusorganisaatio, eikä muutos ohjaavaksi viranomaiseksi varmasti olisi sille ihan helppo.

Hajautetummassa kehityksessäkin on riskinsä. Jos halua yhteentoimivuuteen ei ole, ei sitä myöskään synny. Standardit voidaan määritellä paitsi hyvin, myös huonosti. Järjestelmiä hankittaessa pitää myös oikeasti ymmärtää, mitä ollaan hankkimassa ja miten se suhtautuu muihin jo hankittuihin järjestelmiin. Tanskassa on saatu aikaan koko alaa koskeva yhteinen henki ja halu tehdä yhdessä järjestelmistä hyviä. Suomesta tämä toistaiseksi puuttuu.

Perinteinen ja moderni terveydenhuollon tietojärjestelmän arkkitehtuuri Forsströmin et. al mukaan. Suomessa käytössä olevat ja Sirius-hankkeessa ehdotetut uudet järjestelmät perustuvat vanhaan monoliittiseen arkkitehtuuriin.

Johtopäätökset

Kaikille kolmelle vaihtoehdolle on yhteistä, että ostaja joutuu tekemään selvästi nykyistä enemmän ja parempaa työtä. Tilaajan puolelle pöytää tarvitaan nykyistä enemmän ammattitaitoa sekä sairaalan hallinnoinnista että erityisesti nykyaikaisesta tietojärjestelmien kehittämisestä.

Tietojärjestelmät muodostavat nykyään organisaation kuin organisaation toiminnan ytimen. Ne ovat se luuranko, jonka varassa organisaatiot liikkuvat. Jos ei tietojärjestelmää soviteta organisaation toimintatapaan, täytyy toimintatavat sovittaa järjestelmään.

On vaarallista fantasiaa kuvitella, että tällaisen ydintoiminnon voisi ostaa valmiina ulkoa ymmärtämättä sen toimintaa itse. Ajatus ulkomaisesta potilastietojärjestelmästä, joka ”vaan toimii” on hopealuoti: fiktiivinen ratkaisu kaikkiin ongelmiin. Se on käärmeöljyä, ei lääketiedettä.

Ihmepillereitä ei ole, vaan terveys perustuu elämäntapoihin; samaan tapaan potilastietojärjestelmän toiminta perustuu organisaation toimintatapoihin. Mikään ratkaisu, jossa ei muuteta sairaanhoitopiirien tapaa ostaa ja tuottaa tietojärjestelmiä, ei tule ratkaisemaan ongelmia.

Kaikki kolme ehdotusta sisältävät myös ongelmia ja riskejä. Yksikään niistä ei ratkaise terveydenhuoltoalan nykyisiä ongelmia mitenkään itsestäänselvästi. Siksi paras mitä osaan suositella on, että jokaista näistä vaihtoehdoista – ja muitakin – tutkitaan tosissaan, ja etsitään paras mahdollinen tapa välttää toimittajaloukku.

Sillä jos jokin on varmaa, niin se, että perinteisenä könttäkauppana ei Suomessa tulla koskaan ostamaan onnistunutta potilastietojärjestelmää. Epäonnistuminen on prosessin sisäänrakennettu ominaisuus.

Tietojärjestelmistä päättää viime kädessä HUSin hallitus. En kehota häiritsemään kenenkään kesälomaa, mutta meillä, jotka ymmärrämme tietojärjestelmiä on vastuu, että he tietävät mistä ovat päättämässä.

Edistääkseni asiaa loin adressin, jonka toivon lukijoiden allekirjoittavan. Siinä vaaditaan HUSin hallitusta selvittämään mahdollisuudet välttää toimittajaloukku. Mitään yksittäistä nimenomaista ratkaisutapaa ei vaadita, ainoastaan katastrofaalisen virheen välttämistä. Addressi toimitetaan alkusyksystä HUSin hallitukselle.

Keskustelualustaksi loin myös Facebook-ryhmän Terveydenhuollon IT korjattava. Liittykää sinnekin, ketkä FB:tä harrastatte ja haluatte aihetta seurata.

Kolmantena tapana vaikuttaa ovat vaalit. Kysykää ehdokkailta, mitä he aikovat tehdä, jotta terveydenhuollon IT-järjestelmien katastrofi saadaan tulevina vuosina korjattua. Erityisesti kysykää tätä sairaanhoitopiirien hallituksissa istuvilta.

Julkaistu alkujaan Otson blogissa