Hyvää jatkoa, toivottaa renki

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

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

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

toivottaa,
Hyvä renki

ps. saman aihepiirin keskustelua löytyy ainakin

• Codenton blogista
• Otson blogista

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

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

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

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

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

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

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

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

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

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

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

Kuinka kansallinen palveluväylä tulisi tehdä

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

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

Optimistin tarina

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

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

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

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

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

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

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

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

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

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

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

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

Pessimistin tarina

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

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

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

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

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

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

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

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

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

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

Suuntaviivoja hankkeelle

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ensinnäkin, pitää palkata osaavia.

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

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

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

Toisekseen, pitää palkata muutosta haluavia.

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

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

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

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

Vanhaa ei voi korvata uudella

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

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

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

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

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

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

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

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

Mikä siis neuvoksi?

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

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

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

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

Moderni tietojärjestelmähankinnan valmistelu

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

Ketterä kehitys vaatii kurinalaista valmistelua

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

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

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

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

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

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

Esiselvityksen perusteella voidaan käynnistää hanke

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

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

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

Varsinainen hankinta valmistellaan sitten näiden avulla:

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

Hankintaa valmistellesasi mieti jo projektin aloitusta

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

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

JHS-179 ja arvo

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

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

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

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

arvo = hyöty – kustannus (1)

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

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

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

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

Avoimuutta ja pitkää ikää

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

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

Asetinlaite

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

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

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

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

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

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

7 askelta käyttäjien saamiseen

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kuva: http://instagram.com/jboyedk

 

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.