Digital by default

Britanniassa on määritelty tarkat ohjeet, joita kaikkien valtion nettipalveluhankkeiden tulee noudattaa. Ajatus on, että kun kansalaisille tehdään palveluita, heillä on oikeus odottaa jotain perustason toimivuutta ja viranomaisilla velvollisuus se tarjota. Myös USA:ssa on käytössä vastaavat ohjeet.

Suomessa sen sijaan ei toistaiseksi ole kattavia ohjeistuksia julkisten digitaalisten palveluiden suunnitteluun. Koska ainakin Helsingissä sellaisia suunnitellaan, tässä lähtökohdaksi suomennos brittien ohjeistuksesta.

Digital by Default

  1. Tunne käyttäjäsi. Selvitä keitä palvelun käyttäjät ovat ja perehdy heidän tarpeisiinsa. Selvitä, miten tämän pitäisi näkyä digitaalisten palveluiden suunnittelussa.
  2. Perusta pysyvä, monialainen ryhmä, joka vastaa palvelun suunnittelusta, rakentamisesta ja käytöstä. Ryhmän johtajalla tulee olla riittävä asiantuntemus sekä valtuudet päättää palvelun toimintatavasta.
  3. Selvitä, mitä käyttäjien tietoja palvelu tallentaa tai käsittelee ja mitä turvallisuusvaatimuksia tai muita juridisia vaatimuksia ja riskejä tähän liittyy, esim. henkilörekisterisäädöksistä johtuen. Konsultoi tarvittaessa asiantuntijoita.
  4. Arvioi riskit yksityisyydelle ja varmista että henkilötietojen käsittelyä koskevat vaatimukset täyttyvät.
  5. Arvioi, mitä työkaluja ja järjestelmiä tarvitaan palvelun kehittämiseen, ylläpitoon sekä toiminnan mittaamiseen, ja kuinka nämä työkalut ja järjestelmät kannattaa hankkia.
  6. Rakenna palvelu käyttäen ketteriä, iteratiivisia ja käyttäjäkeskeisiä menetelmiä.
  7. Laadi palvelulle laatukriteerit ja -mittarit (kohdat 21–24), joiden mukaan sen toimivuutta arvioidaan.
  8. Analysoi prototyyppipalvelun menestystä. Suunnittele uudet ominaisuudet ja muu jatkokehitys käyttäjiltä saadun palautteen perusteella.
  9. Luo palvelu, joka on niin yksinkertainen ja intuitiivinen, ettei ensikertalainenkaan tarvitse apua sen käyttämisessä.
  10. Tarjoa avustettua sähköistä tukea niille, jotka tarvitsevat apua voidakseen käyttää palvelua
  11. Suunnittele vanhojen, korvattavien palveluiden elinkaaren loppu hallitusti.
  12. Integroi digitaalinen palvelu ja mahdolliset ei-digitaaliset osat yhdeksi yhtenäiseksi palvelukokemukseksi.
  13. Tee palvelun käyttäjäkokemuksesta, -tyylistä ja ohjeistuksesta yhteensopivia muun julkisen palvelutarjonnan kanssa.
  14. Varmista että sinulla on riittävä kapasiteetti ja tekniset edellytykset palvelun jatkuvaan päivittämiseen ja parantamiseen.
  15. Tee kaikki syntyvä lähdekoodi mahdollisimman uudelleenkäytettäväksi ja julkaise se avoimella lisenssillä (tai perustele vakuuttavasti, miksi jotakin osaa koodista ei voida julkaista).
  16. Käytä avoimia standardeja ja valtion yhteisiä palveluja silloin kun niitä on saatavilla.
  17. Testaa palvelua ympäristössä, joka on identtinen lopullisen käyttöympäristön kanssa. Testaa sitä kaikilla yleisillä selaimilla ja laitteilla. Käytä testitunnuksia ja edustavaa otosta käyttäjistä.
  18. Käytä analytiikkatyökaluja palvelun toiminnan seuraamiseen.
  19. Rakenna palvelua jatkuvasti iteroiden, ja varmista että koko organisaatiolla on siihen tarvittavat edellytykset.
  20. Luo suunnitelma myös käyttöönoton jälkeen jatkuvalle käyttäjätutkimukselle ja käytettävyystestaukselle ja kannusta käyttäjiä antamaan palautetta.
  21. Aseta käyttäjätyytyväisyyden tavoitetaso kaikille palvelun osille erikseen ja seuraa tuloksia systemaattisesti.
  22. Aseta tavoitetaso tehtävien onnistumisasteelle ja seuraa tuloksia systemaattisesti.
  23. Tee (faktojen tukema) suunnitelma saavuttaaksesi matalat yksikkökustannukset ja seuraa tuloksia systemaattisesti.
  24. Tee (faktojen tukema) suunnitelma, jotta mahdollisimman suuri osa kohderyhmästä ottaisi palvelun käyttöön, ja seuraa tuloksia systemaattisesti.
  25. Tee suunnitelmat sen varalle, että palvelu otetaan väliaikaisesti pois käytöstä. Kuinka käyttäjiä palvellaan?
  26. Testaa palvelua kokonaisuudessaan siitä vastaavan ministerin kanssa.

Ohjeet ovat lyhyitä ja selkeitä. Ne eivät määrittele täsmälleen mitä pitää tehdä, mutta ammattitaitoinen verkkopalvelun suunnittelija osaa soveltaa niitä hetken mietittyään googlattuaan omaan tilanteeseensa. Ne ovat sitä, mistä nykyään käytetään sanaa lean.

Käännös on alunperin tehty kirjaani Kuinka tietoyhteiskunta korjataan. Käännös allekirjoittanut & Jussi Sarkkinen. Sittemmin Britannia on tiivistänyt ohjeet 18 kohtaan.

Helsinki siirtyy avoimeen koodiin

Helsingin kaupunginhallitus hyväksyi juuri uuden tietotekniikkaohjelman, jossa linjataan avoimen koodin käyttö:

”Kaupungin toimeksiannosta kehitettävä uusi ohjelmistokoodi julkaistaan avoimen lähdekoodin lisenssillä, ellei ole perusteltua syytä muuhun.”

Tämä tarkoittaa, että jatkossa kun kaupunki hankkii uuden tietojärjestelmän, eikä valmiita tuotteita ole ostettavissa, projektissa tehtävä koodi julkaistaan avoimella lisenssillä. Ei enää toimittajaloukkua, vaan sen sijaan järjestelmien laatu parantunee ja hinta laskee pikkuhiljaa. Kyse ei ole ideologisesta periaatteesta, vaan käytännöllisestä tietojärjestelmien hallinnasta. Päätös olikin yksimielinen sekä kaupunginhallituksessa että sen IT-jaostossa.

Tämä ei tarkoita, että kaupunki siirtyisi Linuxiin tai Open Officeen. Valmiita tuotteita hankittaessa valitaan ensi sijassa parasta, ja se voi olla myös Windows tai Office365.

Samassa paperissa linjataan myös, että ennen hankintaa on valittava ja perusteltava hankinnassa käytettävä strategia: ollaanko hankkimassa valmista tuotetta vai teettämässä uutta järjestelmää. Ja kaupunki aloittaa myös koulutusprojektin, jossa IT-hankintoja tekevät virkamiehet koulutetaan siihen, miten hankinnat saadaan onnistumaan.

Ensimmäisenä merkkinä uudesta toimintatavasta, tarjouskilpailu avoimen kehityksen puitesopimukseen on jo käynnissä.

Avoimen koodin kirjaus ei ole ohjelmassa sattumalta, vaan se on vuosien työn tulos.

Tammikuussa 2012 ehdotin edelliseen tietotekniikkaohjelmaan lisäystä:

”Avoin lähdekoodi. Kaupungin tilaama ohjelmistokehitys julkaistaan EU:n avoimen lähdekoodin lisenssillä (EUPL), ellei tästä ole erityisistä syistä tarpeen poiketa”

Silloin ei ollut oikein mitään tapaa käydä poliittista keskustelua aiheesta, eikä virkakunnassa myöskään oikein ymmärretty, mitä edes tarkoitin. Itselläni ei myöskään ollut mitään asemaa, joka pakottaisi minua kuuntelemaan. Olin vain yhden lautakunnan jäsen.

Nyt kolme vuotta myöhemmin molemmat ovat osa uutta ohjelmaa (tosin lisenssiä ei määritellä). Sillä tavoin politiikka toimi. Ensin ehdotetaan, sitten keskustellaan. Usein se vie aikaa, ja joskus se vaatii uusien keskustelukerhojen perustamista. Kun vaan jaksaa keskustella ja perustella asiat, kysyä kysymyksiä ja antaa vastauksia, niin lopulta voi käydä niin, että ehdottamasi muutos hyväksytään yksimielisesti.

Matkalla oli aika monta askelta. Käytiin kuntavaalit 2012 joissa tulin valituksi. Strategianeuvotteluissa olin vihreiden neuvottelijana ja esitimme IT-jaoston perustamista. Syksyllä 2013 se perustettiin, ja minusta tuli sen puheenjohtaja.

Jaosto käsitteli ohjelman valmistelua moneen kertaan, ja vaatimuksestamme se oli myös kahdesti kommentoitavana julkisesti. Kommentoinnit tosin osuivat juhannukseen ja uuteen vuoteen, mutta jostain se on avoimuuskin aloitettava. Ensi kerralle voisimme ehkä ottaa oppia Espoosta.

Helsinki on nyt ottanut merkittävän askeleen kohti toimivampia tietojärjestelmiä. Seuraavaksi sama periaate pitää ottaa käyttöön koko maassa. Intia ehti jo meitä ennen, samaten Britannia ja USA.

Miksi Apottia kannattaa jatkaa

Helsingin sosiaali- ja terveyslautakunta päätti juuri hyväksyä Apotin tarjouspyynnön, eli hankinta jatkuu suunnitellulla tavalla. En ole lautakunnan jäsen, enkä siis ollut päätöstä tekemässä. IT-jaosto, jonka puheenjohtajana toimin, esitti vain kannanoton hankkeesta. Meilä ei ollut päätösvaltaa asiassa.

Olisin kuitenkin voinut painostaa lautakunnan jäseniä vastustaman Apottia. IT-jaoston puheenjohtajana ja Vihreän ryhmän varapuheenjohtajana minulla on merkittävää vaikutusvaltaa asiaan. Jos olisin kehottanut lautakuntalaisia äänestämään Apottia vastaan, minua olisi kyllä kuunneltu.

En kuitenkaan tehnyt niin. Sen sijaan sanoin heille, että hanketta kannattaa jatkaa. Koska olen sitä mieltä, että keskeyttäminen olisi ollut huonompi vaihtoehto.

Tämä oli varmaan se hetki, kun systeemi sai minusta otteen. Hanke, jota olen vuosia kritisoinut, on yhtäkkiä vaa’ankielellä, ja voisin sen kaataa. Sen sijaan lähden sitä tukemaan, koska se on kuitenkin kokonaisuuden kannalta parempi.

Apotti-hankkeessa on ongelmia. Sen suuruusluokan hankkeet eivät juuri koskaan onnistu aikataulussaan tai budjetissaan. Apotissa on koetettu paketoida mahdollisimman monta asiaa samaan hankintaan, kun alan nyrkkisääntö on nykyään pikemminkin tehdä mahdollisimman vähän asioita yhdellä kertaa. Silloin onnistuminen on todennäköisempää.

Erityisesti sosiaalitoimen yhdistäminen Apottiin on kyseenalaista. Apotissa halutaan hankkia valmis järjestelmä, ja julkisuuteen nousseet kiistat Epicin tarjouksen muutoksesta liittyvät siihen, että sopivia valmiita järjestelmiä sosiaalitoimeen ei oikeastaan ole.

Mutta ongelmia on nykytilassakin, paljon isompia ongelmia. Koko hankintahan lähti siitä, että HUSin tietojärjestelmien kehitys ei toimi ja kustannukset ovat poskettomia. Helsingillä ja Vantaalla taas on käytössä muun muassa ATJ, josta yritettiin luopua jo vuosikymmen sitten, mutta epäonnistuttiin. Olenkin koko ajan sanonut, että vaikka Apotti on myöhässä ja hanke ylittänee budjetin, on tulos silti selvä parannus nykytilaan. Ja tämä on kuitenkin tärkein kysymys.

Terveydenhoidon tietojärjestelmien tärkein ominaisuus on se hyöty mitä niistä saadaan  potilaiden parempaan hoitoon ja hoitohenkilökunnan työn säästämiseen. Vaikka hanke olisi muuten kuinka ongelmallinen, jos se on hoidon onnistumisen kannalta parannus, se on parannus.

Apotin havainnekuva tietojärjestelmine nykytilasta
Apotin havainnekuva tietojärjestelmine nykytilasta

Apotti hankitaan hankintarenkaana, johon kuuluvat Helsinki, Vantaa, Helsingin ja Uudenmaan sairaanhoitopiiri sekä KL-kuntahankinnat. Ja jokaisen on tehtävä täsmälleen saman sisältöinen päätös. Jos Helsingissä nyt haluttaisiin muuttaa vaatimusmäärittelyä, tarkoittaisi se uutta käsittelyä kaikkialla muuallakin. Ja ei ole selvää, että muut kannattaisivat Helsingissä esitettyjä muutoksia.

Tämä on demokraattisen päätöksenteon kannalta vakava ongelma. Merkittäviä hankintoja ei pitäisi tehdä tällaisina yhteishankintoina. Mutta tässä nyt ollaan, ja realistiset vaihtoehdot ovat hyväksyä Apotin eteneminen, tai todennäköisesti kaataa koko hanke. Käytännössä nyt ei siis päätetä siitä, pitäisikö selvittää hiukan huolellisemmin, vaan päätetään koko hankkeen jatkosta.

Ja jos joku pääosapuolista irtautuu hankkeesta, joudutaan ilmeisesti koko hankinta tekemään uudelleen, eli palataan ruutuun nolla. Useampi vuosi lisää nykyisten järjestelmien kanssa.

Entä hankinnan laillisuus? Julkisuudessa on esitetty epäilyjä,että hankintalakia olisi rikottu. Hanketoimistolla on asiantuntevia juristeja käytössään, ja he vakuuttavat tehneensä hankintaa hankintalain mukaisesti. Erityisesti Epicin tarjoaman ratkaisun muuttamiseen oli hankinnan sääntöjen mukaan oikeastaan pakko antaa lupa, kunhan uusi sosiaalihuollon järjestelmäydin oli riittävän hyvä.

Minä en ole juristi, enkä istu markkinaoikeudessa. En lähde tekemään arviota, onko tarjoajien valituksissa perää. Sen paremmin SOTE-lautakunta kuin IT-jaostokaan eivät tee juridista arviointia, sen tekee oikeus. Tämä on oikeasti oleellinen oikeusvaltioperiaate: toiminnan lainmukaisuuden ratkaisee oikeus, poliittiset elimet ratkaisevat ovatko päätökset toivottavia.

Siksi oikea kysymys nyt on, halutaanko Apotti tehdä, vai onko ilmaantunut syitä kaataa hanke. Päätöstä ei pidä tehdä sen pohjalta, että hankinnasta valitetaan. On koko ajan tiedetty, että hankinnasta tullaan valittamaan markkinaoikeuteen.

Pidän edelleenkin Apotin lähtökohtia huonoina. Mutta ne lähtökohdat päätettiin 2012. Ja niillä lähtökohdin hanke etenee nyt suunnilleen niin hyvin kuin se realistisesti voi.

Olen itse ohjelmistojen hankinnan ammattilainen. Mutta aivan rehellisesti: ei minullakaan ole sellaista viisastenkiveä, jolla voisin sanoa että näin tämä menee varmasti paremmin. Sairaala-IT:n kovimmat ammattilaiset pitävät tätä hankintatapaa varmimpana mahdollisuutena saada hyvä järjestelmä. Ja joku arvo täytyy antaa muidenkin ammattitaidolle. Ihan niin ylimielinen en minäkään ole, että kuvittelisin aina tietäväni paremmin.

Tältä pohjalta olen päätynyt kannattamaan Apotti-hankkeen tekemistä loppuun. Mikään hanke ei saa olla ”too big to fail”, ja suuriakin julkisia hankkeita pitää voida keskeyttää, jos ne eivät täytä tavoitteitaan. Mutta Apotti ei ole siinä tilassa. Hoitohenkilökunta ja potilaat tarvitsevat paremman järjestelmät, ja saamme ne kuitenkin todennäköisemmin näköpiirissä olevassa tulevaisuudessa jatkamalla hanketta kuin kaatamalla sen.

Päätöksen yhteyteen lautakunta kirjasi ehdottamani lisäyksen:

”Hyväksyessään esittelijän esityksen Apotti-hankkeen tarjouspyynnön hyväksymisestä sosiaali- ja terveyslautakunta haluaa evästää Helsingin kaupungin edustajia ohjausryhmässä niin, että hankkeen jatkosuunnittelussa sovelletaan mahdollisuuksien mukaan Helsingin tietotekniikkaohjelman 2015-2017 mukaisia ohjeita.”

Se ei ole kovin merkittävää, mutta se on muistutus, että asiat on syytä tehdä kuitenkin niin avoimesti, kuin tämän hankintatavan puitteissa mahdollista. Tuo tietotekniikkaohjelma nimittäin on hyvä. Siitä lisää ensi viikolla.

Kysymyksiä Apotista

Apotti-hankkeen lopullinen tarjouspyyntö on valmistunut, ja käsittelemme sitä IT-jaostossa huomenna. Asian ydin on varmistaa paras mahdollinen onnistuminen terveydenhoidon tietojärjestelmien kehittämisessä. Lääkäreiden ajasta menee jopa puolet tietokoneen käyttöön. Se on kerta kaikkiaan kestämätöntä, ja pakko korjata. Apotti-hanke parhaimmillaan voi olla merkittävä osa ratkaisua. Pahimmillaan osa ongelmaa.

Tässä vaiheessa mukana on kaksi tarjoajaa: Amerikkalainen Epic Systems yhdessä Accenturen kanssa, ja CGI, joka tarjoaa Amerikkalaista Cerneriä. Käytännössä ollaan siis valitsemassa USA:n kahdesta käytetyimmästä potilastietojärjestelmästä jompaa kumpaa.

Hankkeen päätöksenteko on bysanttilaisen monimutkaista. Helsingin ja Uudenmaan sairaanhoitopiiri, Vantaa, Kauniainen ja Kirkkonummi ovat jo hyväksyneet tarjouspyynnön. Helsingin osalta päätöksen tekee sosiaali- ja terveyslautakunta kokouksessaan torstaina 9.4.

Sosiaali ja terveyslautakunta on oikea paikkaa päättää sosiaali- ja terveystoimen järjestelmästä, koska he vastaavat myös sen käytöstä. Koska lautakunnalla ei kuitenkaan ole käytännössä edellytyksiä perehtyä tarjouspyynnön teknisiin yksityiskohtiin, kutsuin koolle kaupunginhallituksen IT-jaoston ylimääräisen kokouksen 7.4. kuulemaan hankkeen tilanne ja keskustelemaan siitä.

Hankinta on viime päivinä ollut julkisuudessa, koska toinen tarjoajista, CGI, lähetti päätöksentekijöille kirjeen, jossa syytti hanketta kilpakumppaninsa suosimisesta.

IT-jaoston puheenjohtajana en halua lukita omaa kantaani tarjouspyyntöön ennen kun olemme kuulleet esittelyn siitä kokouksessa. Sen sijaan voin hyvinkin julkaista kysymykset, joihin haluan saada selvyyttä kokouksen aikana. Kysymyksiä voi myös ehdottaa kommenteissa lisää 9:30 aamulla asti (sori että meni aika viime hetkeen tämän kanssa). Päivitän myös vastaukset oman ymmärrykseni mukaan tähän blogaukseen.

Apotti-etusivun_logo_2012

kysymyksiä Apotista:

Onko apotissa Avoimet rajapinnat?

Vastaus: ei ole, siinä mielessä kuin avoinrajapinta.fi asian määrittelee. Rajapintoja ei toistaiseksi ole suunniteltu avattavaksi. Sen sijaan Apotissa tietyt lakisääteiset rajapinnat ovat tilaajan hallitsemia, eli Apotti-hanketoimisto voi tehdä rajapinnoilla mitä haluaa ja avata ne kenelle haluaa.Näitä pakollisia rajapintoja ovat mm. Kantaan ja eReseptiin liittyvät rajapinnat.

Koska hanke aloitettiin ennen avoinrajapinta.fi julkaisua, se käyttää siitä poikkeavaa terminologiaa ja tilaajan hallitsemia rajapintoja kutsutaan avoimiksi rajapinnoiksi.

Tarjouspyynnön pohjalta hanketoimistolla on mahdollisuudet avata pakolliset rajapinnat kaikille. Muita kuin pakollisia rajapintoja koskien tarjouspyyntö ei sido mahdollistamaan avaamista.

Tehdäänkö Apotti ketterästi?

Vastaus: Apotti on ennen kaikkea valmiin tuotteen hankinta, eikä valmista softaa tehdä ketterästi eikä vesiputousmallilla, koska se on tehty jo. Apotissa luultavasti tehtävien kustomointien ja integrointien osalta asiaa täytyy kysyä.

Liitteessä H sanotaan, että ketteriä menetelmiä käytetään soveltuvissa tilanteissa. Mitä tämä käytännössä tarkoittaa?

Vastaus: tarjouspyyntö ei rajoita kehitystapaa.

Kenelle jää Apotissa kehitettävän koodin omistajuus?

Koodiahan ei haluta kehittää, mutta käytännössä joku määrä sitä tehdään joka tapauksessa.

Vastaus: Oikeudet ovat yhteiset, eli kumpikin saa tehdä kustomointi- ja integrointikoodilla mitä haluaa. Terveydenhuollossa kustomoinnin osuus on pieni, mutta sosiaalihuollossa 20-30%

Apotti-hankinta sisältää myös tilaajalle oikeuden tehdä omaa kustomointia järjestelmään, tai teettää sitä muilla.

Julkaistaanko Apotissa kehitettävä koodi avoimella lisenssillä?

Vastaus: sopimukset eivät automaattisesti mahdollista kustomointikoodin julkaisua. Joidenkin osien osalta se olisi mahdollista, toisten ei. Tämä riippuu neuvotteluista tarjoajan kanssa.

Onko Apotti tarkoitus toteuttaa SaaSina tarjoajan pilvestä, privaattipilvenä vai perinteisenä palvelinratkaisuna? Onko vaatimuksissa tunnistettu mahdollisuus ajaa Apottia yksityisessä pilvessä?

Vastaus: Käyttöpalvelut hankitaan erikseen, ja niiden hostaustapa ratkeaa niiden kilpailutuksen yhteydessä.

Käytännössä kapasiteettivaatimukset on ilmeisesti tehty perinteistä palvelinratkaisua silmällä pitäen. Tarkoitus ei kuitenkaan ainakaan ole ollut sulkea (sisäisiä) pilviratkaisuja pois.

Onko Apotin vaatimuksille laadittu metriikat, joilla niiden toteutuminen tarjotuissa ratkaisuissa testataan?

vastaus: Metriikoita ei ole mitenkään kattavasti tehty. Vaatimuksissa on pyritty välttämään tulkinnanvaraisuutta.

Miksi maksupostit ovat etupainoiset? 50 % kun pilotti on hyväksytty

Vastaus: toteutuksesta 70-80% on tehty ennen pilottia, maksupostit pyrkivät huomioimaan myös työn määrää. Suhteessa työn määrään maksupostit ovat takapainotteisia.

Olettaako hyötylaskelman toteutuminen kaikkien vaatimusten implementointia?

Vaatimuksissa on suuri määrä pakollisia vaatimuksia, ja suuri määrä ei-pakollisia vaatimuksia, joista saa lisäpisteitä. Minkä kaikkien vaatimusten toteutumisen mukaan hyötylaskelmat on laadittu?

Vastaus: Hyötylaskelma on tehty kokonaisuuden, ei yksittäisten vaatimusten toteutumisen perusteella. Kustannusanalyysiä ei ole päivitetty, mutta hyötyanalyysiä on päivitetty jatkuvasti. tarjousten jälkeen koko analyysi päivitetään

Mikä on realistinen aikataulu?

Valinta tehdään 26.9. ja hanke käynnistyy lokakuussa. Onko realistista suomenkielentaitoisia Epic tai Cerner Millenium+Curam osaajia viikossa?

Myös valituksiin markkinaoikeuteen on syytä varautua. Mikä on realistinen aikataulu jolla projekti on täydessä vauhdissa päätöksen jälkeen?

Vastaus: Tarjoajien tulee varautua aloittamiseen Q4 aikana, ensimmäiset kuukaudet tehdään projektisuunnitelmaa toimittajan kanssa. Valituksien suhteen on olemassa skenaarioit, mutta virallinen aikataulu prustuu letukseen että valituksia ei tule.

Kun hanketoimisto muuttuu Apotti oy:ksi, miten luottamushenkilöt saavat jatkossa tietoa hankkeesta?

Vastaus: tässä on eri kuntia mukana eri intressein. Helsinki haluaa luottamushenkilöille tiedonsaantioikeuden, mutta muut kunnat eivät kaikki suhtaudu tähän positiivisesti.

 

Päätös

IT-jaosto päätti yksimielisesti antaa seuraavan lausunnon Apotista:

”Kaupunginhallituksen tietotekniikkajaosto on aikataulun sallimissa puitteissa tutustunut Apotti-hankkeen teknisiin yksityiskohtiin.

Jaoston erityinen huolenaihe on, että hankkeen vaatimusmäärittelyn laadusta ei ole tehty riippumatonta alan asiantuntijoiden teknistä arviota. Jaosto ei ole saanut käyttöönsä hankkeen päivitettyjä riski- ja kustannusanalyysejä arvioinnin pohjaksi.

Lisäksi jaosto haluaa kiinnittää huomiota kaupunginkanslian valmistelemaan tietotekniikkaohjelmaan 2015-2017, joka sisältää monia suosituksia IT-hankintojen suositeltavista menettelyistä, joita ei kaikkia ole hankkeessa huomioitu.”

Esityksen teki jaoston jäsen Lilja Tamminen . ja sitä kannatti jäsen Mikko Pöri
.

Digiradio 3: Ohjelmistojen hankinta, kuka omistaa julkiset järjestelmät

Julkinen sektori ostaa suomessa ohjelmistoja ja niiden kehitystä vajaalla miljardilla. Kysymys siitä, kuka koodin omistaa on viime viikkoina ollut pinnalla.

Teknologiateollisuuden Jukka Viitasaari ja Ohjelmistoyrittäjien Rasmus Roiha kirjoittivat kuinka valtio haluaakin lähtökohtaisesti itselleen omistusoikeuden koodiin jonka maksaa. Otso Kivekäs (se olen minä) vastasi heille, kuinka toimittajaloukkuja pitää välttää, ja parasta olisi julkaista julkisen sektorin tilaama koodi aina avoimena.

Siispä kutsuin Jukan ja Rasmuksen Digiradioon keskustelemaan aiheesta. Miksi koodin tekijällä pitäisi olla siihen omistusoikeus, ja toisaalta minkä takia julkinen sektori haluaa oikeutta itselleen. Mukaan pyysimme vielä Petri Aukian Codentosta, joka myös kirjoitti aiheesta sekä Janne Järvenojan Avanadelta.

Keskustelussa korostuu nyt ehkä toimittajayritysten näkökulma, julkista sektoria edusti tällä kertaa lähinnä studioisäntä, joka sattuu toimimaan myös Helsingin kaupunginhallituksen IT-jaoston puheenjohtajana.
Yhdessä tunnissa ei kaikkia maailman ongelmia ratkota, mutta kahdesta asiasta saavutettiin melko vahva yksimielisyys

1) Toimittajaloukuista pitää päästä eroon. Vanha malli, jossa julkisella ostajalla on vain yksi tarjoaja ja tällä taas tuotteelleen usein vain yksi asiakas on kestämätön, eikä sen jatkaminen ole kenenkään tavoitteena.

2) Jos julkinen sektori hankkii koodia omistukseensa, se pitäisi julkaista avoimella lisenssillä. Ja nimenomaan julkaista heti kun sitä kehitetään (esim. Githubiin), ei vasta joskus tulevaisuudessa.

Käytännön ehdotuksia ohjelmistojen hankintaan lisää kirjoituksessani Kuinka ohjelmistoja tulee ostaa.

petri_auki_janne_järvenoja_otso_jukka_viitasaari_ja_rasmus_roiha_300x210

Julkiset tietojärjestelmät pitää ostaa avoimesti

Helsingin sanomat julkaisi tänään vastineeni siitä, miten tietojärjestelmiä pitää ostaa: siten, että vältetään toimittajaloukku, siis avoimen koodin lisenssillä. Alla kirjoitus pidempänä versiona.

Mielipide hs 15.3.2015: Julkiset tietojärjestelmät pitää ostaa avoimesti - Otso Kivekäs
Mielipide hs 15.3.2015: Julkiset tietojärjestelmät pitää ostaa avoimesti – Otso Kivekäs

Teknologiateollisuuden Jukka Viitasaari ja Ohjelmistoyrittäjien Rasmus Roiha kirjoittivat (HS 9.3.) kuinka julkishallinto uhkaa IT-yhtiöiden kykyä kaupallistaa osaamistaan. Kirjoituksesta saa melko yksipuolisen kuvan julkisesta IT-hankinnasta ja sen ongelmista. Aihe kaipaakin laajempaakin näkökulmaa.

Julkishallinto käyttää Suomessa IT:hen noin kaksi miljardia euroa vuodessa, siitä ehkä vajaan miljardin tietojärjestelmiin, ohjelmistoihin ja niiden kehitykseen. Suurin kustannus ja ongelma ovat tilanteet, joissa julkinen ostaja on loukussa yhden tietyn IT-toimittajan kanssa eikä kykene vaihtamaan toimittajaansa ilman kohtuuttomia kustannuksia. Seurauksena kustannukset nousevat ja tietojärjestelmän kehitys laahaa jäljessä ja se on vuosi vuodelta huonommin käyttöönsä sopiva. Näitä tarinoita on koko julkishallinto täynnä: pahimmillaan yksi nettilomake maksaa kaksi miljoonaa.

Tällainen toimittajaloukku syntyy, kun julkishallinto tilaa räätälöidyn tietojärjestelmän, ja immateriaalioikeudet jäävät sen toimittaneelle yritykselle. Siis täsmälleen niin kuin Viitasaari ja Roiha esittävät. Tilanteen hyötyjiä ovat muutamat suuret yritykset, kärsijöitä veronmaksajat – ja myös suomalainen ohjelmistoteollisuus.

Toimittajaloukku on vältettävissä. Kun julkishallinto tilaa räätälöityjä järjestelmiä, sopimuksilla tulee varmistaa, että tilaajalla on mahdollisuus kilpailuttaa järjestelmän jatkokehitys uudelleen. Loukkua ei synny, kustannukset pysyvät kurissa ja järjestelmät voidaan pitää paremmin ajan tasalla.

Parhaiten tämä onnistuu tekemällä ohjelmistokehitys avoimena lähdekoodina. Avoin lisenssi sallii kaikkien käyttää ohjelmaa. Tällöin myös toimittajayritys voi vapaasti tuotteistaa työnsä tuloksia ja myydä niitä muualle. Ja niin voivat muutkin ohjelmistoyritykset. Vapaampi kilpailu parantaa laatua ja laskee kustannuksia. Siksi Helsingin kaupunki onkin tekemässä päätöstä ostaa uusi ohjelmistokehitys ensi sijassa avoimella lisenssillä.

Avoimella koodilla ostaminen koskee tulevaisuudessakin vain uutta kehitystyötä. Jos esimerkiksi johonkin tukipalveluun on olemassa valmiita ohjelmia, julkishallinnon kannattaa yleensä käyttää niitä. Valmiiden tuotteiden käyttö on lähes aina tehokkaampaa kuin uusien kehittäminen tyhjästä. Mutta tämä on täysin eri asia kuin ohjelmiston räätälöinti yhdelle asiakkaalle, ja nämä on syytä pitää selvästi erillään hankinnoista puhuttaessa.

Toimin itse julkishallinnolle runsaasti työtä myyvän IT-yrityksen hallituksessa ja myös Helsingin kaupunginhallituksen IT-jaoston puheenjohtajana. Alan toimintalogiikka ja sen ongelmakohdat ovat minulle hyvin tuttuja sekä myyjän että ostajan näkökulmasta.

Vanha toimintatapa ei ole myöskään useimpien ohjelmistoyritysten etu. Hankintakulttuuri jossa keskeiset hankinnat rajataan muutamille – yleensä yhdelle – toimijalle ja todellista kilpailua ei juuri synny, ei anna uusille yrityksille mahdollisuuksia kehittyä suurten järjestelmien tarjoajiksi. Onneksi uudenlaiset hankinnat, joissa toimittajaloukkua ei synny, ovat yleistyneet viime vuosina.

Nähdäkseni parasta mitä julkishallinto voi suomalaisen ohjelmistoteollisuuden kilpailukyvylle tehdä, on modernisoida hankintakäytäntönsä ja vaatia riittävää laatua. Jos julkishallinto vaatii vastaavaa laatua kuin kansainvälisesti, sille töitä tekevillä yrityksillä on mahdollisuus myös kansainväliseen menestykseen.

Otso Kivekäs
Helsingin kaupunginhallituksen IT-jaoston puheenjohtaja
Ohjelmistoyrityksen hallituksen jäsen

 

Aiempi keskustelu aiheesta:

Jotta keskustelussa päästään eteenpäin, kutsuin Ohjelmistoyrittäjien Rasmus Roihan ja Codenton Petri Aukian Digiradioon keskustelemaan aiheesta maanantaina 23.3. klo 15. Stay tuned.

Käsittelen aihetta myös laajasti kirjassani Kuinka tietoyhteiskunta korjataan, jonka saa pdf:nä ladata ilmaiseksi.

Kuinka ohjelmistoja tulee ostaa

Tietojärjestelmähankinnat menevät Suomessa yleensä pieleen. Etenkin julkisella sektorilla. Koska olen vuosien varrella useaan kertaan kertonut miten tietojärjestelmiä ei pidä ostaa ja millaisia virheitä hankinnassa on tehty, koen velvollisuudekseni myös kertoa, miten niitä sitten pitää hankkia.

Tietojärjestelmiä voi julkisella sektorilla ostaa onnistuneesti kolmella tavalla:

  1. Ostamalla palveluna (pilvestä)
  2. Ostamalla valmiin standardituotteen
  3. Teettämällä järjestelmän avoimena

Jos julkiset järjestelmät hankittaisiin näillä tavoin, ongelmia olisi paljon vähemmän.

Perinteisesti tietojärjestelmiä on ostettu niin, että tilaava organisaatio määrittelee (konsultin avulla) mitä tarvitsee, lähettää tästä tarjouspyynnön tarjoajille ja valitsee parhaalta kuulostavan järjestelmän halvimmalla hinnalla. Sen jälkeen seuraa pitkä ja hyvin kallis projekti, jonka myöhästyneen toimituksen jälkeen asiakkaalla on huono järjestelmä, jonka korjailusta ja jatkokehittelystä maksetaan seuraavat kymmenen vuotta, kunnes se päätetään heittää romukoppaan ja palataan toistamaan sama virhe. Useimmat julkiset tietojärjestelmähankinnat on tehty näin.

Se ei ole toimiva tapa. Mutta sen mukaisesti toimitaan, ellei nimenomaisesti pidetä huolta että toimitaan toisin.

Se siitä, takaisin niihin toimiviin tapoihin.

1. Osta palveluna

Ensinnäkin, et oikeasti halua ohjelmistoa. Haluat palvelun, jonka ohjelmisto sinulle tuottaa. Se ohjelmisto on vain tapa tehdä se.
Haluatko extranetin? Ota vaikka Basecamp. Tarvitsetko CRM:ää? Miten olisi SugarCRM? Dokumentinhallintaa? Riittäisikö Google Drive?

Pilvipalvelut eli valmiit online-ratkaisut eivät yleensä ole täsmälleen sitä, mitä sinulla oli mielessä. Mutta vaiva ja kustannus on ehkä tuhannesosa täsmälleen oikeanlaisen järjestelmän hankkimisesta. Kannattaa selvittää, onko sopivia online-tuotteita tarjolla, ja vakavasti miettiä, voitaisiinko toiminta sovittaa toimimaan niillä. Digitalisaation [6] suuret hyödyt tulevat töissä, joissa se yli satakertaistaa tehokkuuden, ja niitä kannattaa hiukan etsiäkin.

Pilvipalvelut sopivat käytettäviksi etenkin tukitoimissa, joissa 1) muillakin lienee suunnilleen samanlaisia tarpeita, ja 2) täsmälleen oikeanlainen toimintatapa ei ole keskeiwtä, vaan voidaan sopeutua siihen mitä palvelu tarjoaa. Koska muuttaahan palvelua ei voi.

Siis esimerkiksi tavanomaisen taloushallinnan tai varastoseurannan ohjelman voi yleensä hankkia palveluna, koska aika lailla samanlaisia tarpeita on muillakin. Laissa tarkkaan määrätyn palvelun toteutusta sen sijaan yleensä ei voi.

Pilvipalveluunkin voi jäädä jonkinlaiseen toimittajaloukkuun. Jos rakennat prosessisi toimimaan nimenomaan vaikkapa Google Driven kanssa, siirtymä siitä toiseen tarjoajaan on ylimääräinen vaiva. Tai palvelu saatetaan lopettaa lyhyelläkin varoitusajalla. Mutta koska kyse oli toiminnoista, joissa asiakkaalla on joustovaraa prosesseissa, tämä ei ole yleensä kovin suuri ongelma.

2. Osta standardituote

Jos jotain ratkaisua ei saa palveluna netistä, sen saattaa silti saada valmiina tuotteena. Tai jos lainsäädäntö ei mahdollista nettipalvelun käyttöä, niin tietojärjestelmän voisi ehkä kuitenkin hankkia valmiina omiin tiloihin.

Tämä on noin kymmenen kertaa työläämpää kuin nettipalvelu, ja ehkä kymmenen tai sata kertaa kalliimpaa. Mutta muutoin kyse on samasta asiasta, ja se siis joskus kannattaa.

Valmis tuote on sellainen, joka on olemassa ja käyttöön otettavissa sinä päivänä kun ostat sen. ”Tuote”, josta näet powerpointin ja toimitus luvataan ensi vuonna, ei ole valmis tuote, vaan myyntipuhe, jonka jäljiltä olet toimittajaloukussa. Se on se perinteinen tapa, jota piti välttää. Jos tuote ei sovi sellaisenaan käyttöön, et ole ostamassa tuotetta. Tai ainakaan pelkästään tuotetta, katso seuraava kohta.

MS Sharepoint on valmis tuote ja Photoshop on valmis tuote. Yksikään Suomessa myyty potilastietojärjestelmä ei ole valmis tuote.

3. Teetä avointa

Jos markkinoilta ei kerta kaikkiaan löydy sellaista järjestelmää jota tarvitset, on se sitten jonkun pakko koodata. Tähän liittyy aina suurin toimittajaloukun riski.
Kun järjestelmä kehitetään yhtä asiakasta varten, asiakkaan siis täytyy maksaa sen kehityskulut. Ja kaikkea koodia täytyy jatkokehittää, mikään järjestelmä ei koskaan ole lopullisesti valmis. Sen jatkokehityksenkin maksaa sama asiakas (sinä), ja siinä vaiheessa jos olet loukussa, sinulla on vain yksi tarjoaja, ja maksat mitä pyydetään.

Toimittajaloukku vältetään sillä, että kaikki koodi on avointa. Tämä on perusperiaate, josta on hyvin harvoin syytä poiketa. Ja yleensä poikettaessa tehdään virhe. Kun koodi on avointa, toimittajaa voidaan vaihtaa tarvittaessa, eikä toimittajaloukkua synny, tai ainakin siitä pääsee pois helpommin.

Koodin avoimuus on lähes välttämätön, mutta ei riittävä ehto kehityshankkeen onnistumiselle. Tässä muutama muu periaate, joita yleensä on syytä noudattaa

  • Ketterä kehitys, esim Scrum-mallilla.
  • Kaikki koodi heti avoimena julkiseen repositoryyn (esim: Github, Bitbucket). Siis joka päivä sitä tahtia kun se syntyy
  • Hyvin dokumentoidut julkiset rajapinnat (usein REST)
  • Standardien käyttö
  • Modernit kehitystyökalut
  • Valmiiden komponenttien käyttö
  • Prototyypit ja käyttöliittymä edellä työskentely
  • Vaiheittainen julkaisu ja pilotointi koko ajan käyttäjien kanssa
  • Modulaarinen arkkitehtuuri ja hankinta osakokonaisuuksina
  • Kilpailutuksessa arvioidaan osaamista ja toteutustapaa, ei tuotetta

Nämä eri käytännöt tukevat toisiaan, ja ovat tavallaan yhtenäinen paketti modernin ohjelmistokehityksen menetelmiä. Lisää ohjeita käytännön hankintaan muun muassa tässä ja tässä.

Jos järjestelmää pitääkin koodata, se ei missään tapauksessa tarkoita, että kaikkea pitäisi koodata tyhjästä. Päin vastoin, suurin osa siitä mitä tarvitaan, voi löytyä valmiina, ja koodataan vain se mitä ei löydy.

Projektin pohjana toimiva alusta voi olla avointa koodia tai suljettu tuote. Yleensä sen kannattaa olla avointa koodia, koska suljetun tuotteen kanssa on helpompi mokata ja päätyä taas toimittajaloukkuun.

Jos halutaan ostaa valmis järjestelmä ja kehittää sen päälle, siihen on syytä suhtautua kahtena eri hankintana: 1) hankitaan perusjärjestelmä, 2) kilpailutetaan erikseen sen päälle uuden laajennoksen kehitys. Perusjärjestelmän pitää siis tarjota riittävät avoimet rajapinnat, että muutkin kuin sen perusjärjestelmän tekijä tai kumppanit voivat aidosti kilpailla kehitysprojektista. Itse asiassa perusjärjestelmän tekijätaho olisi syytä sulkea ulos toisen projektin tarjoajien joukosta. Samaan tapaan ylläpito ja käyttötuki pitää pystyä kilpailuttamaan erikseen.

Jos järjestelmä ei tähän taivu, sen varaan ei voi jatkokehittää mitään jäämättä toimittajaloukkuun. Täytyy valita jokin muu perusjärjestelmä. Avoimen perusjärjestelmän kanssa tällaisia riskejä ei ole, siksi niitä yleensä kannattaa suosia.

Näillä samoilla periaatteilla järjestelmän voi kasata myös omana työnä, jos palkkalistoilla on siihen pystyviä ihmisiä. Työn määrä ei välttämättä ole kovinkaan suuri, mikäli lähes kaikki tarvittava löytyy valmiina avoimen lähdekoodin ratkaisuina. Jos tarve kehittää tietojärjestelmiä omaan käyttöön on jatkuva, ei välttämättä ole huono idea rakentaa jonkinlainen kyvykkyys siihen omaan organisaatioon.

Suuri osa avoimen koodin kehityksen hyödyistä saavutetaan periaatteessa silläkin, että asiakkaalla on omistusoikeus koodiin. Käytännössä se ei kuitenkaan riitä. Avoimeen koodiin kilpailevat yritykset voivat aidosti tehdä tarjouksia jatkokehityksestä, kun taas koodiin, jonka ne periaatteessa saavat, mutta jota ne eivät näe, on vaikea tarjota. Lisäksi toteuttajayritys pystyy sumuttamaan piilossa olevan koodin kanssa paljon paremmin, miten asiat tehdään. Ja olen nähnyt enemmän kuin yhden hankkeen, jossa asiakas ei lopulta ole ihan varma, mitä oikeuksia koodiin itse asiassa onkaan. Selkeän avoimuuden kanssa näitä ongelmia ei tule

Pakko valita

Hankintatapa on strateginen valinta, joka on pakko tehdä heti hankinnan alussa, ennen kun tarjouspyyntöjä lähdetään edes luonnostelemaan. Epävarmempi ostaja saattaa ajatella, että eikö kannattaisi antaa tarjoajien ratkaista? Että tehdään väljä tarjouspyyntö ja katsotaan millainen ratkaisu voittaa. Valitettavasti se on kuitenkin mahdotonta.

Tämä liittyy ennen kaikkea hankintalakiin, joka vaatii määrittelemään tarkasti hankinnan kohteen ja valintakriteerit. Jokainen hankintatapa vaatii oman, erilaisen tarjouspyyntönsä. Kilpailuun, jonka voi voittaa pilvipalvelulla, ei ole järkeä tarjota koodausprojektia, ja koodausprojektia pyydettäessä pilvipalvelu ei täytä ehtoja.

Jos tarjouksen kriteerit määritellään niin väljiksi, että mikä vaan tapa käy, silloin käy myös tapa, jossa ostaja sidotaan toimittajaloukkuun ja se jää tarjoajan vangiksi. Ja silloin tämä tapa tulee myös valituksi. Toimittaja hyötyy aina asiakkaan sitomisesta toimittajaloukkuun, siitä kannattaa jopa maksaa alihintaisen tarjouksen muodossa. Siksi toimittaja, jonka aie on lypsää asiakasta myöhemmin, voi aina tehdä halvimman tarjouksen. Tarjouspyynnön täytyy nimenomaisesti estää toimittajaloukku.

Julkisessa tietojärjestelmähankinnassa yksi tärkeimpiä tehtäviä on välttää joutuminen toimittajaloukkuun, ainakaan yhtään pahemmin kuin on pakko. Nämä kolme strategiaa ovat suhteellisen tunnettuja keinoja minimoida toimittajaloukku. Ne eivät ole omaa keksintöäni, vaan valtaamassa alaa Suomenkin julkisella sektorilla.

Avoimen ja suljetun lähdekoodin eroja IT-projektissa
Avoimen ja suljetun lähdekoodin eroja IT-projektissa

Jälkikirjoitus luotetuista kumppaneista

Yksityisillä yrityksillä on käytössään vielä neljäskin hyvä vaihtoehto: kumppanuus luotetun toimittajan kanssa, jonka tuotetta käytetään.

Jos yrityksen oma toimiala ei ole koodaaminen, sen ei yleensä kannata lähteä teettämään koodia itselleen, vaan antaa pätevämpien hoitaa kehitys. Ja vaikka itsekin koodattaisiiin, erikoispalikat tekee tehokkaammin joku joka on niihin erikoistunut.

Kumppanuus toimii niin, että etsitään johonkin tiettyyn asiaan keskittyneistä firmoista se, jonka tyypit tuntuvat luotettavimmilta ja joiden kanssa tulee hyvin juttuun (ja joilla on näyttöä että osaavat työnsä). Jatkossa sitten ostetaan heidän tuotteensa ja pysytään siinä. Ja usein annetaan myyjän kertoa, että mitä oikeastaan kannattaisi ostaa, koska hehän alan parhaiten tuntevat. Ja jos ei yhteistyö suju tai jos alkaa tuntua että myyjä vedättää, lempataan myyjä niskaperseotteella pihalle ja haetaan seuraavaksi paras kilpailija tilalle. Luottamusta joko on tai ei ole.

Julkisella sektorilla tätä ei pidä tehdä. Se menee yleensä pieleen. Jos sidot itsesi yhteen tuotteeseen, sidot itsesi loukkuun.

Hankintalaki kieltää suosimasta yhtä toimittajaa. Julkinen toimija ei siis voi laillisesti luvata luottotoimittajalle, että he saavat jatkossakin projektit. Eikä valita luottotoimittajaansa, jos joku muu onkin tarjouskilpailun kriteereillä parempi.

Tätä voi tietenkin kiertää, ja hyvin yleisesti kierretäänkin. Ehkä kolmannes julkisista softahankinnoista on viritetty tietyn toimittajan voitettaviksi rakentamalla ehtoja, jotka ovat yhdelle toimittajalle mahdollisia ja muille vaikeita tai jopa mahdottomia. Se on tietenkin laitonta, mutta yleistä.

Jos kumppania onnistuukin suosimaan, se ei kuitenkaan riitä. Kun kumppani muuttuu hyvästä rengistä huonoksi vedättäjäksi, siitä pitäisi vielä päästä eroon. Luotettavan kumppanin pitää luotettavana se, että kumppani tietää tulevan bisneksen olevan kiinni luottamuksesta. Jos luottokumppani alkaa vedättää, se on entinen luottokumppani, ja menettää tämän asiakkaan lisäksi muitakin, joille sana leviää.

Hankintalaki kieltää tämänkin. Tarjoajia pitää kohdella tasapuolisesti, eikä huono maine tai yleinen epäluotettavuus ole pätevä peruste syrjinnälle (ja aiemman kokemuksenkin pohjalta se on vaikeaa). Tässä kohti lain kiertäminen on vaikeampaa. Talossa pitkään toiminut ja asiat tunteva kumppani, jonka tuote on tähän asti ollut paras, osaa kyllä tarvittavat asiat, ja tuntee tarpeeksi sisältöä viedäkseen markkinaoikeuteen selvästi itseään syrjivät tarjouskilpailut.

Julkisessa hankinnassa voi siis vähän laittomasti valita itselleen hovitoimittajan, jolta ostaa jatkossakin. Mutta mitään tapaa saada hovitoimittaja toimittamaan laatua jatkossakin ei ole. Tarjoavat yritykset tietenkin yrittävät rakentaa tällaisen ”luottamussuhteen”, mutta siihen suhteeseen ei valitettavasti voi luottaa.

Se, ettei tätä sääntöä ymmärretä, on suurimpia syitä siihen miksi julkiset tietojärjestelmät ovat niin huonoja.

Helsingin kaupungin tietotekniikkaohjelman luonnos on kommentoitavana Otakantaa.fi:ssä tänään viimeistä päivää. Tämä näkökulma ei näy siinä vielä riittävästi.

Tämä teksti julkaistaan myös tulevassa pamfletissani Kuinka tietoyhteiskunta korjataan. Kirjaa voi ennakkorahoittaa Mesenaatti.me:ssä 25.1. asti.

Mikä meni vikaan IT-Suomessa?

90-luvulla Suomi oli tietotekniikan edelläkävijä, jossa oli eniten kännyköitä ja nettiliittymiä ja palveluita digitalisoitiin ensimmäisenä maailmassa. Tätä ihmettä tultiin ihastelemaan eri puolilta maailmaa.

Tänään tilanne on toinen. Tuomioistuinten tietojärjestelmä junnaa ja vaarantaa oikeusturvan. Sähköinen pysäköinninvalvonta hidasti työtä 30%. Toimeentulotuen nettilomake maksaa kaksi miljoonaa. Lääkärien aika hukkuu tiimalasin katseluun.

2010-luvun Suomi on tietoyhteiskuntana parhaimmillaankin keskisarjaa. Tahtoa vielä on, mutta infrastruktuuri on rikki, ja hajoaa yhä lisää. Julkisten tietojärjestelmien kriisiin etsitään ratkaisuja Virosta, jossa ei 90-luvulla juuri edes ollut tietojärjestelmiä.

Miksi näin kävi? Mikä meni vikaan?

Bz5WTMoIYAAhK6v

Yksi kuulemani selitys on, että vanhenimme. Suomen 90-luvun IT-päättäjät olivat kolmi-nelikymppisiä ja innokkaita viemään maan tulevaisuuteen sekä luomaan itselleen uraa uusilla alueilla. Tänään nuo samat miehet (lähinnä miehet) ovat eläkeiän kynnyksellä ja keskittyvät siihen, ettei loppu-uran aikana tule yllätyksiä.

Jos näin olisi, sehän olisi hyvä uutinen. Päättäjäpolvi vaihtuu aikanaan, ja edistys siis jatkuu. Mutta pahoin pelkään, ettei se ole ainakaan koko totuus.

Vanhenemisen kanssa rinnan meillä on nimittäin syntynyt erityisesti julkiseen hallintoon kulttuuri, jossa IT:tä hankitaan ilman että tarvitsee ymmärtää mitä ollaan tekemässä.

90-luvun alussa valtiolla ja kunnilla oli omat IT-yhtiönsä, jotka vastasivat niiden järjestelmien kehittämisestä. Valtion tietokonekeskus, Kunnallistieto, PTK-tietokeskus ja Medici Data. Toimintatavassa oli ongelmansa, ja kaikki yhtiöt myytiinkin pois. Samalla yksityistettiin julkisten tietojärjestelmien omistajuus sekä lähes kaikki osaaminen niitä koskien.

Ensivuodet uusi tapa toimi. Virastoissa kerrottiin, mikä on ongelmana ja IT-yhtiön miehet kertoivat mitä pitää tehdä ja mitä se maksaa. Hankinnat hoidettiin aina omalle firmalle, koska nehän tämän järjestelmän osaavat. Kustannukset vähän nousivat, mutta siihen oli Nokia-Suomessa varaa.

Mikään ei kuitenkaan toimi ikuisesti. Viimeisen 20 vuoden aikana ohjelmistokehitys on muuttunut. On tullut ketterää kehitystä, pilvipalveluita, avoimen koodin yhteisöjä ja avoimia rajapintoja. Virastoissa ei ole ollut ketään, jonka työ olisi ollut pysyä muutoksesta perillä. Eikä yritysten puolellakaan ollut mitään tarvetta kehittää toimintaa, koska bisneshän luisti hyvin näinkin.

Pikkuhiljaa julkinen järjestelmähankinta on ajautunut yhä kauemmas omaan maailmaansa. Prosessit ja kieli jota käytetään ovat muotoutuneet peittämään sen, tietääkö kukaan osallinen mitä oikeastaan ollaan tekemässä. Ei keskustella mitä järjestelmän pitäisi tehdä, vaan sen hallinnan mallista.

Esimerkiksi yritysarkkitehtuuri syntyi strategisen johtamisen välineeksi, tavaksi ymmärtää yrityksen liiketoiminnan ja tietojärjestelmien suhdetta ja kehittää niitä yhdessä. Väline on parhaimmillaan, kun sitä kehitetään systemaattisesti ja liiketoimintajohto ohjaa toimintaa aktiivisesti.

Nykysuomessa yritysarkkitehtuurista on tullut kokonaisarkkitehtuuria. Käytännössä jokainen virasto tilaa konsultin tekemään pinon kaavioita, koska laissa lukee että sellainen pitää olla. Tuloksena on yleensä joukko itsestäänselvyyksiä ja toiveita, jotka jäävät levyn nurkalle pölyttymään. Toiminnan kehittämiseen dokumenttia harvoin käytetään, jos se siihen edes sopisi.

Vastaavia kyynisiä kuvauksia voisi kirjoittaa myös vaatimusmäärittelyjen, rajapinta-arkkitehtuurien ja käytettävyyssuunnitelmien käytöstä. Kaikkien niiden pitäisi olla tapoja suunnitella ja selvittää organisaatiolle, mitä tässä oikein halutaan tehdä. Siis luoda ymmärrystä. Ja kaikista niistä on tullut dokumentteja jotka tilataan yhdeltä konsultilta ja toimitetaan toiselle. Ymmärrys jää syntymättä.

Se mitä Suomi kaipaa, on ymmärrystä mitä ollaan tekemässä. Että puhutaan konkreettisesti niistä asioista mitä tarvitaan ja miten ne voitaisiin saada toimimaan. Ja kun sanon asiat, tarkoitan myös tietojärjestelmiä. Koska aivan kaikki asiat ovat nykyään numeroita jossain tietojärjestelmässä.

Teksti on julkaistu alunperin Tivissä 10/2014

Kansallinen palveluväylä tienhaarassa

Tietoviikko-lehti pyysi minua tekemään heille tiivistetyn version kansallista palveluväylää koskevasta blogauksestani, jotta voisivat painaa sen paperille.

Se ilmestyi tämän päivän lehdessä, ja löytyy alta nyt myös sähköisessä muodossa.

Tietoviikko 11.4.2014
Tietoviikko 11.4.2014

Kansallinen palveluväylä on ehkä merkittävin IT-projekti tällä hetkellä Suomessa. 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 IT-palvelualan suunnasta tehdään tämän kevään aikana.

Teknisesti palveluväylä on vain alusta, jolla kutsutaan palveluita. Suurin osa siihen kohdistetuista odotuksista onkin ylimitoitettuja, jos ajatellaan pelkkää väylää. Mutta kyse on enemmästä kuin vain tietojärjestelmästä. Palveluväylähankkeen 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, 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 selvemminkin, mutta ei ole ollut tapana. Perustelumuistiossa puhutaan lisää avoimista rajapinnoista, avoimesta koodista ja paremmin toimivista julkisista hankinnoista, joihin PK-yrityksetkin pääsevät mukaan.

Tarkoitus on siis toteuttaa suuri julkinen softahanke kevyesti ja nopeasti ja siirtyä integraatioissa käytäntöön, jossa ne tehdään helposti ja toimivat avoimesti. Samalla avataan kaikki mahdollinen data ja rajapinnat ja siirrytään malliin, jossa julkiset tietojärjestelmät ovat avointa koodia, jotta niitä voidaan hyödyntää tehokkaammin. Rakennepaketissa ennakoidaan tästä saatavan kansantalouden tasolla puolen miljardin vuotuiset hyödyt.

Toisaalta tämä ei ole ainoa totuus hankkeesta, sillä on myös synkempi puoli.

Taloussanomat kertoi tammikuussa, kuinka palveluarkkitehtuurihanke on “120 miljoonan euron ontto kuori” ja rahojen käytölle ei ole olemassa suunnitelmaa. Professori Tomi Voutilainen taas epäilee, että siitä on tulossa teknologiavetoinen uudistus, jossa unohdetaan loppukäyttäjien tarpeet. Luvattujen hyötyjen toteutumisestakaan ei ole mitään näyttöä. Vastaavia tietojärjestelmien yhteentoimivuushankkeitahan on tehty Suomessa ennenkin, mm. VIA ja PERA, mutta 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. Miksi tällä kertaa kävisi eri tavalla?

Koodin avoimuus hankkeessa on myös hiukan epäselvää. Sitran Mirjami Laitisen mukaan palveluväylä ei ole avointa koodia, eikä jaettavissa muille. Internet-huhun mukaan taas koodi olisi avointa vain osittain, eikä kaikkea lähdekoodia saataisi. Huhujen uskottavuutta lisää se, että Suomen ja Viron välisessä sopimuksessa ei mainita avoimuudesta tai ylipäänsä lähdekoodista mitään.

Kaiken lisäksi hankkeessa on käytetty ensimmäinen vuosi saamatta aikaan paljoakaan. On toki kirjoitettu kokonaisarkkitehtuuri ja pidetty seminaareja. Kumpikaan ei varsinainen ketterän hankkeen avauspaukku. Kehitysympäristökin on 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 ja ketterältä hankkeelta, 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 oikea? Molemmat, ja vain aika näyttää, kumpi perii voiton. Palveluväylästä voi tulla käännekohta, jossa julkisten IT-hankkeiden kurssi kääntyy parempaan. Tai siitä voi tulla karmea esimerkki miten IT:n varjolla kerätään rahat yksityiseen taskuun saamatta mitään toimivaa aikaiseksi.

Otso Kivekäs
Ohjelmistokonsultti ja Helsingin kaupungin tietotekniikkajaoston puheenjohtaja

Tietojärjestelmä on politiikkaa, osa 1: case opetuksen pilviväylä

Opetusministeriö suunnittelee ”pilviväylää” sähköisten oppimateriaalien välitykseen kouluihin. Hanke on sunnuntaihin asti kommentoitavana otakantaa-palvelussa.

Nyt olisi helppo ajatella, että jostain softakikkarettahan tässä vaan tehdään, nörtit miettikööt sen. Mutta se olisi virhe. Oikeasti tässä päätetään:

  • Millaisia oppimateriaaleja tulevaisuuden koulussa voidaan käyttää ja millaisin laittein
  • Kuka valitsee oppimateriaalit: oppilas, opettaja, kunta vai valtio
  • Onko jatkossa olemassa suomalaista oppimateriaalibisnestä (a.k.a. koulukirjakustantamot) ja miten se järjestäytyy, kenelle tuotteitaan kauppaa
  • Onko isoilla kansainvälisillä toimijoilla tarkat tiedot kaikista Suomen koululaisista

Nämä ovat kaikki tyypillisiä tietojärjestelmän suunnitteluun liittyviä teknisiä päätöksiä. Päätöksiä arkkitehtuurista, pääsynvalvonnasta, tietomallista. Ne ovat päätöksiä, minkä laatikoiden väliin piirretään minkäkinlaisia viivoja kaavioon.

Samaan aikaan ne samat viivat kaviossa ovat  merkittäviä linjanvetoja siitä, mitä koko organisaatio on tekemässä. Tässä tapauksessa siis opetuksen ja oppimateriaalituotannon tulevaisuudesta.

Valistuneessa organisaatiossa tämä softa-arkkitehtuurin ja toiminnan yhteys ymmärretään. Ymmärretään, että samassa pöydässä missä piirretään laatikoita ja viivoja, täytyy myös valita, mitä organisaatio haluaa tulevaisuudessa tehdä. Koodin ja bisneksen on pakko keskustella.

Opetusministeriö taitaa onneksi olla tässä suhteessa olla valistunut organisaatio.

Tutustuin pilviväylään syksyllä, kun tein työn puolesta yhtä sen esiselvityksistä. Siinä vaiheessa piirtelemäni arkkitehtuuriluonnokset olivat vielä tukevasti irrallaan tavoitteista: alihankintakonsultti vaan umpiossa keksii ideoita tietämättä mihin tässä oikeastaan pyritään.

Myöhemmin tekniset ideat ja poliittiset tavoitteet kuitenkin lähenivät toisiaan: Helmikuussa opetusministerin erityisavustaja Esa Suominen kokosi porukan aiheesta kiinnostuneita kansalaisia sekä projektin vetäjät keskustelemaan vähän valmiimmista suunnitelmista. Itse päädyin mukaan lähinnä blogausteni ansiosta, kommentoimaan miten tietojärjestelmiä kannattaa tehdä. Ja innostuin sen verran, että kirjoitin projektisuunnitelman luonnostakin. Hankkeen nyt esitelty kuvaus perustuukin pääosin tekstiini.

No ,jos pikkuhiljaa koitan päästä asiaan, mistä tässä pilviväylässä on siis kyse?

Projektisuunnitelman sanoin:

Pilviväylä-hankkeen tarkoitus on tuottaa järjestelmä, jolla parhaat ja uusimmat opetusmateriaalit saadaan helposti koulujen ja opettajien käyttöön. Lisäksi kehitetään tapoja tukea opettajien omaa opetusmateriaalien tuotantoa ja levitystä muidenkin käyttöön ja helpottaa yritysten mahdollisuuksia päästä oppimateriaalimarkkinoille. Oppi- ja opetusmateriaali ymmärretään tässä laajasti sisältäen oppimiseen liittyvät teksti- ja videomateriaalit, pelit, käyttösovellukset, ryhmätyökalut ja palvelut.

 

Pilviväylästä kehitetään kokonaisvaltainen edutech-ekosysteemin kohtaamis- ja vuorovaikutuspaikka verkossa. Se on paikka jossa oppilaiden, opettajien ja palveluntuottajien muodostama vertaisverkko toimii ja vaikuttaa tulevien pedagogisten käytänteiden luomiseen ja levittämiseen.

Käytännössä kyseessä on siis ”kauppapaikka”, josta opettajat valitsevat opetusmateriaaleja, joka on integroitu oppilasrekisteriin ja tarjoaa automaattisesti oppilaille auktorisoinnin ja autentikoinnin materiaaleihin: kun opettaja klikkaa vaikka nettipelin käyttöön, oppilaat pääsevät siihen käsiksi, vaikka se pyörii pelin tarjoajan palvelimilla. Ja sama auktorisointi toimii myös laskutusperusteena, joten mitään erillistä DRM:ää ei tarvita tiedostomuotoisillekaan materiaaleille.

foo

Palataanpa alussa esittämiini kysymyksiin

Millaisia oppimateriaaleja tulevaisuuden koulussa voidaan käyttää ja millaisin laittein? Mitä tahansa tiedostoina liikkuvaa tai serverillä toimivaa. Myös erilaisiin laitteisiin asennettavat ohjelmat ovat mahdollisia, joskin eksoottisempien laitteiden kanssa saattaa asentaminen mennä käsityöksi. Järjestelmä ei oleta täysin yhtenäistä laitekantaa

Kuka valitsee oppimateriaalit: oppilas, opettaja, kunta vai valtio? Opettaja, koulu tai kunta, riippuen miten kyseisessä kunnassa valinnat halutaan tehdä. Ilmaismateriaalien osalta yleensä opettaja, mutta maksullisiin on yleensä kunnalla jokin kontrolli. Joissain tapauksissa oppilaatkin.

Onko jatkossa olemassa suomalaista oppimateriaalibisnestä (koulukirjakustantamot) ja miten se järjestäytyy, kenelle tuotteitaan kauppaa? On. Alan liiketoimintamalleja pyritään olemaan rajaamatta. Laskutus voidaan hoitaa luokittain käyttöönoton mukaan tai todellisen käytön mukaan tai kuinka vaan. Erityistä huomiota suunnataan myös avoimien oppimateriaalien tuotannon tukemiseen.

Onko isoilla kansainvälisillä toimijoilla tarkat tiedot kaikista Suomen koululaisista? Ei ole, mutta… Oppimateriaalintarjoaja tietää oppilaista vain ne tiedot, jotka materiaalin tai palvelun käyttöön tarvitaan. Käytännössä tosin tämä voi sisältä nimen ja luokan.

 

Nämä vastaukset eivät ole ainoita mahdollisia. Suunnittelun aikana on pyöritelty erilaisia ratkaisuja, joista seuraa eri vastaukset. Luultavasti useampia kuin voisin kuvitellakaan. Esimerkiksi oppimateriaalien valinta olisi voitu koodata vain koulutuksen järjestäjän (kunnan) vastuulle. Tai materiaalituotanto olisi voitu rajata vain virallisesti hyväksytyille tahoille sen sijaan että sitä voi tehdä ”kuka vain”. Tai järjestelmään olisi voitu rakentaa jokin virallinen DRM, joka olisi halvaannuttanut sen. Jne, jne.

On suhteellisen helppoa tunnistaa olemassa oleva toimintapa, ja varmistaa että se on jatkossakin mahdollinen (ellei sitä juuri haluta estää). Esimerkiksi se, että opettajat voivat valita käyttämänsä opetusvälineet. Selvästi vaikeampaa on nähdä mahdolliset tulevat toimintatavat, jotka järjestelmä sopivalla tavalla tehtynä mahdollistaa. Esimerkiksi avoimien oppimateriaalien kehityksen tuen rakentaminen järjestelmään vaatii sekä teknistä että yhteiskunnallista näkemystä.

Code is law, sanoi Lawrense Lessig vuoskymmen sitten. Se tarkoittaa, että tietojärjestelmät jotka rakennamme, sanelevat mikä on mahdollista ja mikä ei, mikä on helppoa ja mikä vaikeaa. Siksi tietojärjestelmien rakentamista ei saa jättää pelkästään nörttien asiaksi. Siinä suunnitellaan, millaisessa maailmassa tulevaisuudessa elämme.