Avainsana: julkiset ohjelmistohankinnat

Digitaalinen itsenäisyys, osa 1: riippuvuus

Digitaalinen riippuvuus Amerikan yhdysvaltoihin on pakko katkaista. Tämä on käynyt selväksi viimeistään parin viime viikon aikana.

Ongelma on paljon syvempi kuin useimmat alan tekniikan ulkopuolella tajuavat. Suomen koko julkinen sektori ja lähes kaikki yritykset toimivat amerikkalaisten digijättien infran varassa. Jos palvelut ja tiedot eivät olekaan suoraan niiden halussa, niin vähintäänkin käyttäjähallinta ja siis pääsy kaikkiin palveluihin ja kaikkeen tietoon riippuu niistä.

Trumpin Grönlantia koskeva uhkailu sisälsi mielivaltaisia tulleja. Askel niistä teknologian vientikieltoihin ei ole kovin pitkä. Se olisi toki vapaakauppasopimusten vastaista, mutta niin ovat Trumpin tullitkin. Emme voi tuudittautua sen varaan, että sopimukset yksinään riittävät suojaamaan meitä.

Myös EU oli viime viikolla valmis harkitsemaan ACI-mekanismin käyttöä vastauksena Trumpille. Se voisi tarkoittaa amerikkalaisen ratkaisujen käyttökieltoa kaikissa julkisissa hankinnoissa, tai amerikkalaisten IPR:ien kumoamista, mikä johtaisi vetäytymiseen markkinoilta.

Nämä eivät ole spekulaatioita. Nämä ovat tällä hetkellä realistisia lyhyen tähtäimen riskejä.

Parhaassa tapauksessa Yhdysvaltojen politiikka alkaa rauhoittua ja palaamme kohti jonkinlaista normaalia. Jäljelle jää tieto, että tämä voi tapahtua uudelleen, mutta meillä on aikaa korjata pahimmat riskit. Pahimmassa tapauksessa saatamme olla viikkojen päässä siitä, että yhtäkkiä valtionhallintomme, terveydenhuoltomme ja suurin osa julkisista organisaatioistamme lakkaa toimimasta.

Pidemmällä tähtäimellä riippuvuuden suurempi riski on suomettuminen – samanlainen itsesensuurin ja putkinäköisyyden kulttuuri, jonka hankala kytkös Neuvostoliittoon tuotti 1940-1980-luvulla. Jos sinulla ei ole neuvottelupöydässä vaihtoehtoja ja toinen osapuoli tietää, että sinulla ei ole vaihtoehtoja, suunta on yleensä kohti huonompaa. Vaikka mitään konkreettista uhkausta ei koskaan esitettäisi, itsenäisyys heikkenee koko ajan lisää.

Kannatan totta kai kansainvälistä sopimuspohjaista järjestystä ja todella toivon, että tästä sekasotkusta selvitään vielä ilman tämän pahempia kriisejä. Niin varmasti toivoo jokainen järkevä ihminen. Mutta samalla emme voi sulkea silmiämme todellisuudelta. Täydellinen riippuvuus amerikkalaisesta infrasta on suunnaton riski huoltovarmuudelle – vähän kuin laskisimme maataloutemme jatkuvan venäläisten lannotteiden tuonnin varaan.

Siksi riippuvuutta on pakko vähentää. Tästä ei tule helppoa, eikä tästä tule mukavaa. Mutta viimeinen hetki ottaa uhka vakavasti on joskus viime vuonna. Vähentäminen ei tarkoita katkaisua, vaan aktiivista työtä kohti jonkinlaista tasapainoisempaa keskinäisriippuvuutta.

Suurin riski – ja se josta osaan itse sanoa eniten – on Suomen julkisella sektorilla. Kunnat, hyvinvointialueet ja valtio myös käsittelevät meidän kaikkien tietoja ja palveluita. Siksi niiltä voi ja pitää edellyttää vahvempaa huoltovarmuutta kuin yrityksiltä, jotka voivat harkitusti riskeerata olemassaolonsa, mikäli se on tehokkaampaa.

Ehdotan suunnilleen seuraavaa:

  1. Kriittisimmät tiedot pidetään Euroopassa ja eurooppalaisten yhtiöiden hallinnassa. Tämä koskee ainakin kaikkea vaalidataa, keskeistä terveysdataa, oikeusjärjestelmää ja tietenkin kaikkea puolustukseen liittyvää. Kaikki hankkeet näiden tietojen siirtämiseksi amerikkalaisiin pilviin keskeytetään ja jo siirretyt tiedot palautetaan eurooppalaiseen kontrolliin.
  2. Valtion ja muun hallinnon toiminnan kannalta kriittiset järjestelmät eivät saa olla riippuvaisia amerikkalaisten yhtiöiden toiminnasta. Siltä osin kun näin nyt on (ja lähes kaikkialla on), aloitetaan arviointi, miten riippuvuutta voidaan rajata nopeasti.
  3. Jos julkinen sektori käyttää amerikkalaisten yhtiöiden pilvipalveluita tai järjestelmiä, joiden toiminta on riippuvaista (esim. Kirjautuminen tai lisenssitarkistus) jatkuvasta yhteydestä rapakon taakse, palveluiden puuttumisen varalta täytyy olla varasuunnitelma. Mikäli kyse on keskeisestä järjestelmästä, varasuunnitelman täytyy olla nopeasti toimeenpantava.
  4. Kaikissa julkisissa hankinnoissa tehdään arviointi digitaalista rippuvuuksista pakollisena osana hankintaa ja mikäli kyse on kriittisestä järjestelmästä, varautumissuunnitelma miten tiedot tai palvelu voidaan tarvittaessa siirtää eurooppalaiseen kontrolliin.

Nämä ehdot eivät täyty todennäköisesti missään julkisessa organisaatiossa tässä maassa. Eikä riippuvuuden katkaiseminen ole millään tavalla realistista. Mutta myöskään löysässä hirressä roikkuminen ei ole vaihtoehto.

Siksi ensimmäinen askel täytyy olla riippuvuuksien nopea tunnistaminen ja varautumissuunnitelman tekeminen. Tarvitaan sekä lyhyen tähtäimen hätäratkaisuja, jotka otetaan käyttöön jos on pakko, että myös pidemmän tähtäimen suunnittelua, miten askel askeleelta (nopein askelin) rajataan riippuvuutta ja kasvatetaan digitaalista itsenäisyyttä.

Tämä on minun hahmotelmani digitalisaation ammattilaisena, kaupunginvaltuutettuna ja digitaalista huoltovarmuutta kehittävän yhtiön toimitusjohtajana.

Minä haluan turvata tämän maan digi-infran. Ja yritykseni tekee myös kaikkensa tämän edistämiseksi.

Kuka lähtee mukaan talkoisiin? Laittakaa nimeä alle. Tai myös kaikki kritiikki ja analyysin tarkentaminen on erittäin tervetullutta.

Seuraavassa osassa luvassa konkreettisempia ratkaisuaihioita

Otso Kivekäs
Toimitusjohtaja
Kaupunginvaltuutettu
27 vuotta IT-alalla

Ps. Jokaiselle yritykselle suosittelen niin ikään riippuvuuksiensa kriittistä arviointia, mutta en lähde kirjaamaan näin täsmällisiä ohjeita tuntematta tarkemmin tilannetta ja jo tehtyjä riskianalyysejä. Ja myös yksilönä kannattaa miettiä, mikä on varasuunnitelma ja ovatko itselle tärkeät tiedot vähintään varmuuskopioituna jonnekin turvaan.

Avoin koodi ja digitaalinen huoltovarmuus

Nyky-yhteiskunta on äärimmäisen riippuvainen ohjelmistoista. Tuhansien kriittisten järjestelmien jatkuvan saatavuuden varmistaminen on digitaalista huoltovarmuutta. Väitän, että avoin lähdekoodi on yksi parhaista tavoista parantaa ohjelmistojen huoltovarmuutta.

Eurooppalaisessa keskustelussa on viime aikoina noussut voimakkaasti esiin digitaalisen suvereniteetin vaatimus, eli ajatus miten Euroopan pitäisi kyetä tuottamaan tarvitsemiaan tietojärjestelmiä itsenäisesti – erityisesti ilman riippuvuutta Yhdysvaltoihin. Tavoite on vaikea tai jopa mahdoton ainakin lyhyellä aikavälillä.

Suomessa ajatus on ottanut vähemmän tulta. On kaikille selvää, ettemme koskaan kykenisi kehittämään kaikkia tarvitsemiamme ohjelmistoja kotimaassa. Suvereniteetin kaltainen mahtipontinen käsite myös sopii huonosti kotimaiseen keskusteluun.

Sen sijaan pitäisi puhua digitaalisesta huoltovarmuudesta. Huoltovarmuus on sitä, että varautumalla ennakkoon selviämme kriiseistä jos niitä tulee. Digitaalinen huoltovarmuus on siis varautumista siihen, että jonkin keskeisen tietojärjestelmän käyttö estyy eri syistä.

Vahvimmin digitaalisen huoltovarmuuden ongelma on tullut viime aikoina esiin keskustelussa hävittäjistä ja muista asejärjestelmistä. Jos hävittäjän toimittajavaltio voi etänä lopettaa päivitykset, sammuttaa koneen ominaisuuksia tai jopa estää sen käytön kokonaan, muodostaa tämä ilmeisen riskin, johon käyttäjävaltion on pakko varautua poliittisesti ja teknisesti.

Aivan sama koskee kuitenkin lähes kaikkia ohjelmistojärjestelmiä. Ja koska kaikki maailman asiat toimivat ohjelmistojen varassa, tämä koskee ihan kaikkea. Ruuantuotantomme, terveydenhoitomme, julkinen liikenne ja sähköjakelumme perustuvat kymmenien tai satojen tietojärjestelmien toimintaan. Lukuisat näistä järjestelmistä ovat välttämättömiä tai yhteiskunnan toiminta menee sekaisin hyvinkin nopeasti.

Näitä riippuvuuksia on eri suuntiin ja mikä pahinta, osa niistä ei ole edes tiedossa. Merkittävin kysymys juuri nyt ovat riippuvuudet yhdysvaltalaisiin yrityksiin. Jokaisella organisaatiolla olisi syytä olla ajantasainen käsitys, mitä tarkoittaisi, jos henkilötietoja ei saisi enää säilyttää amerikkalaisten yritysten hallitsemissa järjestelmissä kuten AWS tai Salesforce. Tai vielä pahempana skenaariona, jos joidenkin järjestelmien tai ohjelmistojen saatavuutta Eurooppaan rajoitettaisiin osana kauppasotaa. Taloudellisesti tuollaisessa rajauksessa ei tietenkään olisi mitään järkeä, mutta eipä ole Kanadan valtausuhkauksissakaan. Myös järjettömään pitää varautua.

Monimutkaisessa maailmassa ajatus omavaraisuudesta ei ole realistinen. Meitä on Suomessa viisi miljoonaa ja vaikka kaikki ryhtyisimme koodereiksi tänään, ei se riittäisi siihen että kykenisimme tuottamaan kaikki järjestelmät, joita tekninen sivilisaatiomme käyttää. Euroopan 500 miljoonaa asukasta on jo vahvempi väestöpohja, mutta teknistä velkaa on niin paljon, että jopa Euroopan tasolla on pakko priorisoida mitä kriittisiä ohjelmistoja tehdään itsenäisesti. Loppujen osalta riippuvuuksia pitää hallita.

Yksi tärkeimmistä keinoista riskien rajaamisessa on käyttää avoimen lähdekoodin järjestelmiä. Avoimen koodin ydinajatus on, että järjestelmän käyttäjä VOI ylläpitää järjestelmää ja tarvittaessa kehittää sitä eteenpäin itsenäisesti. Äärimmäisen pieni osa useimpien järjestelmien käyttäjistä tekee tällaista itsenäistä kehitystä, mutta mahdollisuus on olemassa.

Perinteisen suljetun ohjelmiston tai pilvipalvelun lähdekoodi, johon järjestelmän toiminta on määritelty, on vain sen kehittäjäyrityksen hallussa. Usein järjestelmää ei voi edes operoida ilman kehittäjäyrityksen aktiivista myötävaikutusta. Avoimella lähdekoodilla tämä ehdoton riippuvuus poistuu. Jos järjestelmää kehittänyt tai operoinut yritys katoaa, seuraa siitä varmasti hankaluuksia, mutta korvaava ratkaisu on mahdollinen – ja hyvällä varautumisella siirtymä voi olla jopa sujuva.

Avoin koodi mahdollistaa tai helpottaa varautumissuunnitelmia useita erilaisia riskiskenaarioita vastaan. Jos amerikkalaisten kanssa yhteistyö täytyy lopettaa, voidaan toimia vain Euroopassa. Jos lainsäädäntö kieltää henkilötietojen viennin maasta, voidaan pilvessä toimiva palvelu siirtää kotimaahan. Jos yritys joutuu pakotteiden kohteeksi, voidaan hakea uusi toimittaja. Ja niin edelleen.

Kaikkiin käyttötarpeisiin ei ole olemassa sopivaa avoimen lähdekoodin järjestelmää, mutta yhä useampiin on. Jos kriittinen palvelu on mahdollista toteuttaa perustuen avoimen lähdekoodin järjestelmään, se on yleensä huoltovarmempaa perustaa siihen.

Kaikkien julkisten toimijoiden ja myös yritysten pitäisi tunnistaa digitaaliset riippuvuutensa ja laatia digitaalinen huoltovarmuussuunnitelma, jossa määritellään erilaisten riskien hallintatavat ja toimintasuunnitelmat riskien toteutuessa.

Kirjoittaja toimii toimitusjohtajana yrityksessä, joka mielellään auttaa ottamaan käyttöön ja ylläpitämään avoimen lähdekoodin järjestelmiä.

Avointa koodia julkishallintoon!

10 vuotta sitten kirjoitin kuinka julkisia tietojärjestelmiä pitäisi hankkia. Kuinka pitää miettiä mitä tekee, välttää toimittajalukkoa ja mikäli pitää koodata uutta, tehdä se ensisijaisesti avoimena koodina.

Sain myös jonkin verran edistettyä asiaa, muun muassa Helsinki on julkaissut erilaisia pienempiä ratkaisuja avoimena koodina, muun muassa Varaamon ja Palvelukartan. Suosikkiesimerkkini avoimen koodin hyödyistä on kuitenkin eVaka – Espoon alkujaan kehittämä varhaiskasvatuksen järjestelmä, jota käyttää jo 19 kuntaa. Ajassa jossa Helsinki käytti 32 miljoonaa epäonnistuneeseen hankkeeseensa, eVaka on saatu 12 miljoonalla rakennettua ja leviämään uusille kunnille.

Viime syksynä kirjoitin taas julkisista softahankinnoista ja miten niitä kannattaa tehdä. Ja teoilla on seurauksia.

Tänään aloitin Haltu Oy:n toimitusjohtajana. Haltu on 15v vanha tamperelainen softafirma, jonka uusi strategia on viedä käytäntöön sitä, mitä yllä kirjoitin. Ja perustajat katsoivat, että minä voisin olla paras vetäjä tälle strategialle. Ja sen verran omahyväinen ehkä olen, että itsekin aloin siihen uskoa. Lisäksi firman arvot ja toimintatavat vastaavat monelta osin todella hyvin sitä mitä itse ajattelen. Strategian ytimenä on varmistaa, että asiakkaan eivät ole toimittajalukossa, vaan voivat myös vaihtaa toimittajaa.

Haltu pyrkii tuotteistamaan avoimen lähdekoodin ratkaisuja helposti ostettaviksi paketeiksi. Päätuottemme on yllä mainittu eVaka. Haltu ei ole sitä koodannut eikä koodaa. Mutta kyllä ylläpitää ja auttaa käyttöönotossa. Tänään aloitin kertomalla noin sadalle varhaiskasvatuksen ammattilaiselle, miten voisimme auttaa juuri heidän kunkin kuntaa.

Jatkan Helsingin valtuustossa ja muissa rooleissani, mutta jatkossa tulee siis vietettyä aikaa myös Tampereella. Ja epäilemättä kirjoitettua taas vähän enemmän softajuttuja.

Helsinki ei aiemmista yrityksistäni huolimatta käytä eVakaa. Toivon kaupungin tulevaisuudessa sitä käyttävän, mutta jos näin käy, Helsinki hankkinee tarvitsemansa koodauksen ja ylläpidon isommilta firmoilta. Itse en myy Helsingin suuntaan mitään.

Eli jos kaipaat hyvää softaa varhaiskasvatukseen, täs ois siulle sellainen!

Tai jos on idea, mitä avointa koodia haluaisit julkishallinnossa ottaa käyttöön, niin ota yhteyttä!

Otso Kivekäs
Toimitusjohtaja
Haltu Oy
otso.kivekas@haltu.fi
+358-443336338

Miten tietojärjestelmähankinta epäonnistuu tai onnistuu

Jokaisen tietojärjestelmähankinnan kriittisin vaihe on alussa, ennen kun tarjouspyyntöä tai määrittelyä aletaan valmistella. Siinä kohti pitäisi kysyä, mitä me oikeastaan olemme tekemässä. Ja usein hankinta epäonnistuu jo tässä kohtaa, koska kriittisiä kysymyksiä ei käydä riittävästi läpi.

Tärkein kysymys liittyy siihen, mitä olemme organisaationa tekemässä. Tietojärjestelmää ei voi erottaa toimintatavasta, jota sen olisi tarkoitus tukea. Esimerkiksi Apotti on tullut surullisenkuuluisaksi rakenteisesta kirjaamisesta erotuksena aiempien potilastietojärjestelmien vapaatekstikenttiin. Apottia ei voi käyttää ilman rakenteista kirjaamista, muissa Suomessa käytetyissä järjestelmissä taas voi kirjata lähinnä vapaatekstinä. Oliko muutos rakenteiseen kirjaamiseen harkittu ja tietoinen päätös? Ymmärrettiinkö sen seurauksia riittävästi?

Yleensä toimintatapoja halutaan muuttaa: jos tavoitteena ei olisi muutos, luultavasti jatkettaisiin kuten ennenkin. Eli hankinta lähtee siitä, että ymmärretään haluttu muutos toiminnassa. Jos muutosta ei mietitä tietoisesti, on iso riski, että päädytään määrittelemään järjestelmä tukemaan aiempaa toimintatapaa – josta siis haluttiin eroon. Miika Kuha kirjoittaa omassa blogitekstissään siitä, miten tätä organisaation muutosajurien tunnistamista voi tehdä. Yksi hyvä työkalu on myös arvovirtakartta.

Toisaalta toimintatapaakaan ei voi määritellä irrallaan tietojärjestelmästä, vaan yhteys on kaksisuuntainen: toimintatavasta seuraa millainen järjestelmä halutaan, mutta tarjolla olevista vaihtoehdoista seuraa, millainen toimintatapa on mahdollinen. Käytännössä toiminnan muutosta ja järjestelmävaihtoehtoja pitää selvittää rinnakkain tai vuorotellen iteroiden.

Tietojärjestelmän hankintaan on kolme perusstrategiaa: valmistuote, oma kehitys ja strateginen kumppani. Jokaisella on omat hyvät ja huonot puolensa, eikä ole olemassa mitään yleissääntöä että yksi olisi toista parempi.

Miksi valita valmistuote?

Valmistuotteen etuna on, että se on valmiina saatavissa, eli nopea – ja milloin se on valintana mahdollinen, se on yleensä halvin vaihtoehto. Haittapuolena on, että valmistuote on sellainen kuin on, joten toimintatapa täytyy sopeuttaa siihen. Useimpia järjestelmiä pystyy jonkin verran muokkaamaan ja käyttämään vaihtoehtoisilla tavoilla, mutta mitä kauemmas erkaannutaan tuotteen perusprosessista, sen heikommin se luultavasti tukee toimintatapaa. Siksi valmistuotetta valittaessa tärkein kysymys on, pystymmekö sovittamaan toimintamme tähän järjestelmään? Kuinka kykeneviä ja halukkaita olemme muuttamaan toimintaa?

Valmistuote voi olla SaaS-palvelu tai erikseen asiakaskohtaisesti asennettava

Teknologiavalintojen ja organisaation käyttämien järjestelmien rooli on suuri ja pohdinta siitä miten asia ratkaistaan on strateginen

järjestelmä. Tilanteesta riippuen sen hankinta voi olla luottokorttiostos, monimutkainen sopimusneuvottelu tai mitä tahansa näiden väliltä. Perusprosessina on selvittää vaihtoehdot, vertailla ja koekäyttää niitä, tunnistaa muutokset omiin toimintatapoihin ja arvioida niiden hyvät ja huonot puolet. Lopuksi tasapainotetaan kustannuksia ja toimintatapoja. Julkisena hankintana erityinen haaste on, että toimintatapoja arvioidaan vasta vaihtoehtojen tunnistamisen jälkeen, mikä tekee suoraviivaisen tarjouspyynnön vaikeaksi.

Mitä oma kehitys tuo, jos siihen päädytään?

Oman kehityksen etu on puolestaan se, että järjestelmän voi määritellä juuri haluamakseen. Huono puoli on, että kehitys on hidasta ja kallista, lähes aina paljon kalliimpaa kuin valmiit ratkaisut. Useimmiten käykin niin, että tavoitteita on kustannussyistä pakko karsia, eikä järjestelmä täytäkään niitä toiveita mitä alussa oli. Lisäksi järjestelmän määrittely on aidosti vaikeaa. Etukäteen tehdyt tarkat määrittelyt unohtavat aina jotain olennaista, ja toisaalta sisältävät asioita joita ei lopulta tarvitakaan. Ongelmaa voi hallita ketterällä lähestymistavalla, mutta sen hintana tulee epävarmuus lopullisista kustannuksista.

Oman kehityksen kustannusta voi joskus olla mahdollista alentaa avoimen lähdekoodin kehityksellä, jossa samaa kustannusta jakamaan saadaan suurempi joukko käyttäjiä. Esimerkiksi monien Suomen kaupunkien kehitämä eVaka-päivähoitojärjestelmä on tästä hyvä esimerkki.

Oma kehityskin on useimmiten ulkoa hankittua ohjelmistokehitystä, käytännössä ketterän tiimin kilpailutus. Omana osaamisena on kuitenkin välttämättä oltava tuoteomistaja, joilla on kykyä ohjata kehitystä ja käydä jatkuvaa vuoropuhelua toimintatapojen ja kehitystyön ristipaineessa. Yleistäen voisi sanoa, että ulkoistetussa kehityksessä onnistuvat sellaiset organisaatiot, jotka kykenisivät tekemään saman kehitystyön myös sisäisesti. Voidakseen hankkia koodausta, pitää myös ymmärtää jonkin verran koodausta.

Strategisen kumppanuuden merkitys on suuri

Strateginen kumppani on ulkopuolinen firma, joka kehittää omaa ohjelmistotuotettaan, mutta tiiviissä yhteistyössä kanssamme, niin että meidän tarpeemme ohjaavat osittain heidän tuotekehitystään. Näin saadaan osa oman kehityksen joustavuudesta ja mahdollisesti osa valmistuotteen kustannusedusta, mutta haasteena on tiivis sitoutuminen yhteen toimijaan ja sen tuleviin ratkaisuihin. Onnistunut suhde vaatii kumppanin tavotteiden ja insentiivien ymmärtämistä sekä molemminpuolisen luottamuksen kehittämistä.

Strateginen kumppanuus on enemmän kuin hankinta, se on molemminpuolinen pitkäaikainen sitoumus yhteisiin tavoitteisiin. Yritysten välillä tällaiset kumppanuudet ovat kohtuullisen yleisiä, julkisella sektorilla sen sijaan hankintalaki tekee onnistuneen kumppanuuden erittäin vaikeaksi ja riski tulla hyväksikäytetyksi on merkittävä.

Hankintastrategiaa kannattaa harkita huolella

Hankintastrategian valinta ei ole suoraviivainen kysymys. Ratkaisun tekeminen vaatii samaan aikaan riittävää ymmärrystä omista tarpeista ja kyvyistä ja toisaalta markkinoilla tarjolla olevista ratkaisuista. Usein kannattaa aloittaa omien tarpeiden analyysistä ja sen rinnalla selvittää markkinalla tarjolla olevia vaihtoehtoja, jotta voi vertailla niiden sopivuutta omiin tarpeisiin.

Hyvin usein toimintatapa valitaan heti alkuun, eikä vaihtoehtoja sille mietitä oikeastaan missään vaiheessa. Tämä on monen epäonnistuneen hankinnan taustalla. Toinen virhe on ajatella, että aloitetaan vaan hankinta ja antaa markkinan ratkaista, millaisia esityksiä tulee. On kuitenkin käytännössä mahdotonta tehdä tarjouspyyntöä, johon voi vastata yhtä hyvin ketterällä kehitystiimillä kuin valmisjärjestelmällä. Monet keskeisimmät valintakriteerit strategioiden välillä ovat myös organisaation sisäisiä: muutoskyvykkyys, ohjelmistoprojektin hallintaosaaminen, ymmärrys omista prosesseista.

Varsinaista hankintaosaamista on mahdollista ostaa ulkoa, mutta strategista valintaa konsultti ei voi tehdä organisaation puolesta. Siihenkin toki voi hankkia apua, mutta sisäinen panos on merkittävä, koska ymmärryksen mitä ollaan tekemässä ja miksi täytyy syntyä organisaation sisälle.

Yhteenveto

Tässä vielä hankintastrategiasanoma tiivistetysti:

  1. Jos hankintaan ryhtyessä ei tiedetä mitä ollaan hankkimassa ja miksi, hankinta todennäköisesti epäonnistuu.
  2. Hankintastrategian valinnassa käsitellään samaan aikaan tavoitteita, organisaation muutoskyvykkyyksiä ja osaamista sekä markkinoilla olevaa tarjontaa. Mikään näistä irrallaan toisista ei riitä ratkaisuun.
  3. Sellaista strategiaa ei ole, jolla voisi onnistua ilman, että ymmärtää mitä on tekemässä. Oman osaamisen lisääminen on aina osa hanketta.

Teksti on julkaistu alun perin Withmoren blogissa. Withmore auttaa tämäntyypisissä haasteissa mielellään.

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.