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ä.
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
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:
Jos hankintaan ryhtyessä ei tiedetä mitä ollaan hankkimassa ja miksi, hankinta todennäköisesti epäonnistuu.
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.
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.
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
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.
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.
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.
Arvioi riskit yksityisyydelle ja varmista että henkilötietojen käsittelyä koskevat vaatimukset täyttyvät.
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.
Rakenna palvelu käyttäen ketteriä, iteratiivisia ja käyttäjäkeskeisiä menetelmiä.
Laadi palvelulle laatukriteerit ja -mittarit (kohdat 21–24), joiden mukaan sen toimivuutta arvioidaan.
Analysoi prototyyppipalvelun menestystä. Suunnittele uudet ominaisuudet ja muu jatkokehitys käyttäjiltä saadun palautteen perusteella.
Luo palvelu, joka on niin yksinkertainen ja intuitiivinen, ettei ensikertalainenkaan tarvitse apua sen käyttämisessä.
Tarjoa avustettua sähköistä tukea niille, jotka tarvitsevat apua voidakseen käyttää palvelua
Integroi digitaalinen palvelu ja mahdolliset ei-digitaaliset osat yhdeksi yhtenäiseksi palvelukokemukseksi.
Tee palvelun käyttäjäkokemuksesta, -tyylistä ja ohjeistuksesta yhteensopivia muun julkisen palvelutarjonnan kanssa.
Varmista että sinulla on riittävä kapasiteetti ja tekniset edellytykset palvelun jatkuvaan päivittämiseen ja parantamiseen.
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).
Käytä avoimia standardeja ja valtion yhteisiä palveluja silloin kun niitä on saatavilla.
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ä.
Käytä analytiikkatyökaluja palvelun toiminnan seuraamiseen.
Rakenna palvelua jatkuvasti iteroiden, ja varmista että koko organisaatiolla on siihen tarvittavat edellytykset.
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.
Aseta käyttäjätyytyväisyyden tavoitetaso kaikille palvelun osille erikseen ja seuraa tuloksia systemaattisesti.
Aseta tavoitetaso tehtävien onnistumisasteelle ja seuraa tuloksia systemaattisesti.
Tee (faktojen tukema) suunnitelma saavuttaaksesi matalat yksikkökustannukset ja seuraa tuloksia systemaattisesti.
Tee (faktojen tukema) suunnitelma, jotta mahdollisimman suuri osa kohderyhmästä ottaisi palvelun käyttöön, ja seuraa tuloksia systemaattisesti.
Tee suunnitelmat sen varalle, että palvelu otetaan väliaikaisesti pois käytöstä. Kuinka käyttäjiä palvellaan?
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.
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.
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.
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.
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.
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.”
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.
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
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
Jotta keskustelussa päästään eteenpäin, kutsuin Ohjelmistoyrittäjien Rasmus Roihan ja Codenton Petri AukianDigiradioon keskustelemaan aiheesta maanantaina 23.3. klo 15. Stay tuned.
Tietojärjestelmähankinnat menevät Suomessa yleensä pieleen. Etenkin julkisella sektorilla. Koska olen vuosien varrella useaankertaankertonut 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:
Ostamalla palveluna (pilvestä)
Ostamalla valmiin standardituotteen
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
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.