Otso Kivekäs Helsinki

Toimittajaloukku vantaalaisittain

Kesäkuussa Vantaa osti toimeentulotuen nettihakemuksien käsittelyjärjestelmän 1,9 miljoonalla CGI:ltä (ent Logica, ent VM-Data) suorahankintana, kilpailuttamatta. Heinäkuussa selvisi, että Helsinki on ostanut saman toiminnallisuuden CGI:ltä 1,85 miljoonalla, myöskin kilpailuttamatta.

Kumpikin kaupunki osti noin kahdella miljoonalla nettilomakkeen ja sen integroinnin taustajärjestelmiin. Useammankin eri asiantuntijan arvio julkisten tietojen perusteella oli, että tuon pitäisi maksaa pikemminkin kymmeniä tuhansia euroja kuin miljoonia. Jos taustajärjestelmä on poikkeuksellisen hankala, niin ehkä 200 000€. Mutta ei kahta miljoonaa.

Mistä on kyse

Suorahankinta tarkoittaa sitä, että kaupunki ei etsi markkinoilta parasta tai halvinta ratkaisua, vaan ostaa järjestelmän tietyltä yhtiöltä tämän määräämään hintaan. Koska hankintatapa on ilmeisen altis erilaisille väärinkäytöksille ja vedätyksille, on sen käyttöä rajattu laissa tiukasti. Hankintailmoituksessa Vantaan kaupunki perustelee suorahankintaa näin:

”Toimeentulotuki on kiinteä osa Vantaan asiakastietojärjestelmää, eikä sitä voi erottaa VATJ:stä aiheuttamatta hankintayksikölle huomattavaa teknistä ja taloudellista haittaa. Mikäli sähköinen toimeentulotukiasiointi hankittaisiin kolmannelta osapuolelta, olisi rakennettava erillisiä integraatioita ja tietoliikenneyhteyksiä eri järjestelmien välille. Samalla tieto hajaantuisi useaan tietokantaan, mikä estäisi asiakastiedon keskittämisen samaan järjestelmään. VATJ:n rajapinnat eivät ole avoimia, joten kaikki integraatiot olisi rakennettava erillisinä. Edellä mainitut seikat aiheuttaisivat hankintayksikölle huomattavia ylimääräisiä taloudellisia kustannuksia. Hankinta on tehtävä pakottavasta lainsäädännöstä johtuvista syistä. Vantaan kaupunki ei tällä hetkellä pysty noudattamaan toimeentulon käsittelylle asettuja määräaikoja.”

Tässä on kyseessä toimittajaloukku. Se on tilanne, jossa tietojärjestelmää tarvitseva taho on täysin yhden toimittajan armoilla. Tällöin toimittaja voi käytännössä sanella hintansa. Katsotaanpa vähän tuota hinnoittelua.

Vantaalla lasketaan säästettävän järjestelmän avulla 15 henkilötyövuotta. Kun yksi henkilötyovuosi maksaa vajaat 38 300, tarkoittaa tämä 425 000 euron vuotuista säästöä. Ihan kiva säästö siis, pitkän päälle.

Mutta Vantaa on mukana Apotti-hankkeessa, jossa Helsingin seudun kuntien terveydenhuollon ja sosiaalitoimen järjestelmät korvataan yhdellä yhteisellä järjestelmällä. Nyt ostettava koodi on siis tarkoitus heittää roskikseen parin vuoden jälkeen. Realistisesti luultavasti hankkeen loppupäässä, noin 2018.

Jos oletetaan, että säästöt saataisiin täysimääräisinä, ehtisi järjestelmän elinkaaren aikana siis säästyä noin 2,1 miljoonaa euroa. Eli projekti maksaa sen verran, että se juuri ja juuri kannattaa vielä tilata. Pienikin viivästys tai budjetinylitys, niin olisi kannattanut ennemmin palkata 15 ihmistä lisää.

Helsingissä taas kustannussäästöksi on laskettu 0,8 – 1,6 miljoonaa euroa vuodessa. Toisaalta järjestelmään liittyy kaikenlaisia oheiskuluja enemmän, joten kokonaisuudessaan takaisinmaksuajaksi on laskettu 3 vuotta käyttöönotosta. Jos käyttöönotto saadaan tehtyä suunnitellusti 2014 alkuun, järjestelmä ehtii olla käytössä ehkä 3-4 vuotta, eli sopivasti juuri niin kauan, että se kattaa kulunsa. Kuinkas sattuikaan.

Vaikuttaisi siltä, että tässä on tehty niin sanotusti maksukykypohjaista hinnoittelua. Siinä tuote maksaa juuri niin paljon, kuin mitä asiakas on siitä korkeintaan valmis maksamaan. vaikka se olisi kymmenen kertaa kohtuullinen hinta.

Vapaassa markkinataloudessa tuotteensa saa tietenkin hinnoitella juuri kuten haluaa. Yleensä vaan ylihinnoittelija menettää asiakkaansa, mutta toimittajaloukussa ei. Toimittajayrityksellä on kissanpäivät, asiakas on pulassa.

Asiakas, joka hankkiutuu tällä tavoin toimittajan armoille, on hoitanut asiansa todella huonosti.

Miten tähän on tultu

Helsingin sosiaalitoimessa on käytössä CGI:n toimittama ATJ-järjestelmä ja Vantaalla VATJ. Tai no, oikeastaan CGI ei ole niitä toimittanut. Historia on hiukan monimutkaisempi. ATJ tarkoittaa AsiakasTietoJärjestelmä ja VATJ on siitä muokattu versio, Vantaan AsiakasTietoJärjestelmä. Ne kehitti pääkaupunkiseudun kuntien omistama PKT-tietokeskus 80-luvulla. Kyse oli siis kuntayhtymästä, joka teki kuntien omiin tarpeisiin ATK-järjestelmiä. Se, että eri kunnille tehtiin omat versiot oli ajan tapa.

Vuosina 1997-2007 Suomessa tapahtui tietojärjestelmiä toimittavien yritysten kentässä melkoinen myllerrys. valtio, kunnat ja kuntayhtymät alkoivat luopua it-yksiköistään. Alan yritykset ostivat niitä ja toisiaan nopeassa tahdissa. Seurauksena julkishallinnon tietojärjestelmät päätyivät lopulta lähes kaikki kahdelle toimijalle: Tiedolle ja Logicalle. ATJ:n polku fuusiopuussa kulki näin:

  • 1990 PKT-tietokeskus fuusioitui Kunnallistiedon (muiden kuntien vastaava yksikkö) kanssa KT-tietokeskukseksi
  • 1997 KT-tietokeskus listautuu pörssiin nimellä Novo Group
  • 2004 ruotsalainen VM-Data ostaa Novo Groupin
  • 2006 brittiläis-hollantilainen LogicaCMG ostaa VM-datan
  • 2012 kanadalainen CGI ostaa Logican

Kun kuntien yhteinen yksikkö muuttui ensin kuntien omistamaksi yhtiöksi, sitten kotimaiseksi pörssiyhtiöksi ja lopulta kansainvälisen yrityksen haarakonttoriksi, toimintatavat kulkivat perässä hitaammin. Alkujaan ATK-yksikön vastuulla ei ollut pelkästään koodaaminen, vaan myös tuleviin kehitystarpeisiin varautuminen ja suunnittelu. Ja siellä se on edelleenkin. Ei jollain Vantaan sosiaalitoimella ole ollut realistisia edellytyksiä suunnitella ja ennakoida tietojärjestelmiensä kehitystarpeita, arkkitehtuurimuutoksia ja mahdollisia kilpailutuksia. Käytännössä ATJ:n ja VATJ:n kehityksestä ovat vastanneet PKT-tietokeskuksen perilliset, KT-kuntatieto, Novo, VM-data, Logica ja nyt CGI. Kaupungin rooliksi on jäänyt kysyä paljonko rahaa varataan budjettiin ja maksaa laskut.

Hanna Kuusela ja Matti Ylönen kuvaavat kirjassaan Konsulttidemokratia tätä rakennetta. Valtion ja kuntien IT-yksiköt päätyivät osaksi isoja konsulttitaloja, mutta niiden rooli toiminnassa oli ja on edelleenkin paljon suurempi kuin ulkopuolisella tarjoajalla saisi olla. Vantaa ja Helsinki eivät ole ongelmiensa kanssa mitenkään yksin. On aivan normaalia ja maan tapa, että IT-yritys rahastaa kovalla kädellä yksinoikeuttaan järjestelmään, joka on alkujaan tehty kuntien rahalla. ”Järjestelmien suljetut ohjelmistorajapinnat toimivat suoranaisena kiristyskeinona, jolla sosiaali- ja terveydenhuollon yksiköitä pakotetaan hankkimaan kaikki palvelut samalta toimittajalta”.

ATJ

ATJ:n ja tulevan Kansallisen sosiaaliarkiston (KanSa) integrointisuunnitelma. Kuva ei liity suoraan tässä käsiteltyihin projekteihin.

Varsinainen virhe ei siis ollut tämä yksi hankinta. Virhe on tehty joka päivä viimeiset viisitoista vuotta, kun sosiaalitoimen ydintoimintojen järjestelmää ei ole otettu millään tapaa omaan hallintaan – edes rajapintojen tasolla. Pörssiyrityksen tehtävä on tuottaa voittoa, eikä suojella kuntia näiltä itseltään. Kun työntää päänsä katiskaan, hyviä lyhyen tähtäimen ratkaisuja ei enää ole.

Apotti korjaa tilannetta osin, koska siinä vaaditaan avoimia rajapintoja, joiden päälle uusia lisäosia voidaan hankkia muualtakin kuin taustajärjestelmän toimittajalta. Tosin rajapintojen määrittely ja pahimmassa tapauksessa avoimuuskin jää taustajärjestelmän toimittajan vastuulle. Samassa katiskassa on siis kaikkien muidenkin päät, ja silmäkoko on isompi eli pikkukalat pääsevät kulkemaan.

Apotin tapa voi kuitenkin periaatteessa, jos kaikki sujuu onnellisten tähtien alla, johtaa ihan oikeisiin hyötyihin, kun ulkomailla jo valmiiksi kehitetyn järjestelmän ominaisuuksia saadaan käyttöön ”ilmaiseksi”. Vantaan ja Helsingin tapa, jossa yksityisellä yrityksellä on vain yhden asiakkaan käytössä oleva vanhanaikainen tuote, ei missään kuviteltavissa olevassa maailmassa voi johtaa kuin katastrofiin.

Mitä sitten pitäisi tehdä?

Ratkaisua ongelmiin avaa Espoon melko vastaava tapaus vuoden takaa. Espoo hankki kotihoidon optimointisovelluksen (älkää kysykö mikä se on) suorahankintana Tiedolta, koska sovellus rakentui suoraan Tiedon Effican päälle, ja ”sovellus on teknisistä syistä pakko hankkia Effica-järjestelmän toimittajalta.”

Kolme yritystä valitti markkinaoikeuteen, vedoten siihen, että ovat toimittaneet vastaavia järjestelmiä. Valituksia ei tutkittu, koska ne myöhästyivät, mutta Espoo päätti kuitenkin perua hankinnan ja kilpailuttaa työt.

En tiedä Espoon hankkeen jatkoa tarkemmin, mutta nyt Espoo testaa yhdessä Lahden ja Kuntien Tieran kanssa ”hyvinvointijärjestelmien tietojen välittämistä palveluväylän kauttaperustuen Viron X-roadiin. Kuulemani mukaan siinä pilotoidaan juurikin kotihoidon optimointisovellusta. Palveluväylän ansiosta itse sovelluksen voi tehdä helposti kuka vain, vaikka taustalla on edelleen Tiedon Effica.

Menemättä tällä kertaa sen syvemmälle X-roadin ja väyläarkkitehtuurin kiehtoviin saloihin, tiivistän mitä Helsinki ja Vantaa voisivat länsinaapurilta tässä oppia

  1. Älä tilaa suorahankintana järjestelmätoimittajaltasi, vaikka he kuinka sanoisivat että on pakko. Se on luultavasti laitonta ja varmasti tyhmää.
  2. Rakenna arkkitehtuuri, jossa uudet sovellukset ovat irrallaan perustiedoista ja hankinnat voidaan tehdä vapaasti. Se on ensimmäinen askel toimittajaloukusta vapautumiseksi
  3. Tee se mieluiten vuosia sitten. Jos et kuitenkaan tehnyt, tee se heti.

ps. Hesarin Tuomas Peltomäki kirjoitti tänään myös toimittajaloukusta ja Helsingin hankkeesta. Kannattaa lukea.

11 thoughts on “Toimittajaloukku vantaalaisittain

  1. Rajaat kirjoituksesi virheellisesti vain suorahankintoja. Todellisuudessa julkisista kilpailutuksista yli 90% on näennäiskilpailutuksia, jotka päätyvät aina näiden isojen toimijoiden käsiin. On vain virkamiesten osaamattomuutta, että puljatun kilpailutuksen sijaan käytetään suorahankintaa.

    Paras ja ainoa ratkaisu tähän olisi Ruotsin malli: lakiin kirjatut avoimet rajapinnat, joilla toimittaja ei saa rahastaa.

    • Rajasin sen vain suorahankintaan, koska näissä kahdessa tapauksessa oli kyse (lain rajamaille tai rajan taa osuvasta) suorahankinnasta. Olet toki täysin oikeassa, että usein järjestetään myös näennäiskilpailutuksia jotka on viritetty juuri tietyn tahon voitettavaksi. Kilpailutusten lisääminen sinänsä ei siis ratkaise ongelmaa.

      Osaatko kertoa tuosta ruotsin laista tarkemmin? Se kuulostaa hyvin samansuuntaiselta idealta, kuin mitä itse olen pohtinut ja olisi kiintoisaa kuulla miten se toimii käytännössä.

    • Valitettavasti minulla ei ole Ruotsin laista tarkempaa tietoa. Siellä asuessani ihmettelin, kun julkisen terveydenhuollon IT-markkina toimi päinvastoin kuin Suomessa: toimittajat olivat järjestäytyneet ja kävivät hattu kourassa keskustelemassa landstingettien johdon kanssa, kun Suomessa se on asiakas joka joutuu kumartamaan näitä kahta isoa. Työkaverit osasivat kertoa, että heillä oli ollut samanlainen tilanne kuin Suomessa kymmenisen vuotta sitten, jolloin markkinamonopoli oli purettu lakimuutoksella. Eron huomaa käytännössä siinä, että Suomen sairaalatietojärjestelmien kenttä on noin kymmenen vuotta Ruotsia jäljessä. Mitään innovaatioita ei ole tapahtunut täällä tällä vuosituhannella, eikä yhtään uutta yritystä ole päässyt sairaaloiden ydinjärjestelmien toimittajiksi.

      Tästä johtuen myös kansalliset järjestelmät, kuten Suomen Kanta.fi -palvelua vastaava NPÖ ja Vårdguiden ovat olleet tuotannossa kymmenen vuotta ja eResepti parikymmentä, kun Suomessa vasta aloitellaan niiden käyttöä. Ennenkaikkea niiden rakennuskustannukset olivat murto-osa Suomen projekteista. Täällähän Tiedolle ja Logicalle on maksettua kymmeniä ellei satoja miljoonia (mm. proxit hanke) pelkästään rajapintojen saamisesta kansalliseen järjestelmään.

      Apotista muuten sen verran, että 500miljoonan hinta on melko vähän verrattuna siihen, että nykyisen järjestelmän ylläpitomaksu samalta ajalta on 300miljoonaa. Eikä se edes sisällä versiopäivityksiä.

  2. Päätellen netissä olleista epävirallisista asiantuntija-arvioista, Apotissa avoimet rajapinnat ei välttämättä toteutu jos alle valitaan EPIC. Ainakaan järkevään hintaan. Järjestelmä on toteutettu poikkeuksellisen vanhalla suljetulla ohjelmistoteknologialla jota ei ole koskaan suunniteltu rajapinnat mielessä. Ilmeisesti jo XML-datan lataaminen tai tuottaminen voi olla huomattavan vaikeaa toteuttaa.

    Taitavien ohjelmoijien saaminen ja sitouttaminen EPIC projektiin voi myös olla hyvin haastavaa, pohjaten siihen miten ohjelmoijat ovat kommentoineet kokemuksiaan ko järjestelmän kehittämisestä. Ja jos projektiin tulee tekijöiden osalta kova vaihtuvuus, aiheuttaa se 100% varmuudella ongelmia. Olisi hyvin mielenkiintoista tietää ym projektien osalta kuin monta kehittäjää projekteissa on ollut ja miten pitkään he ovat olleet projektissa mukana.

    Voisiko julkisen rahoituksen projekteihin laittaa mukaan pykälän joka velvoittaisi toimittajat antamaan toimituksien yhteydessä versionhallintajärjestelmistään login josta näkisi jokaisesta tallennuksesta kehittäjän nimi, päiväys, muutoksen koko sekä automaatiotestauksen/koebuildin tulokset? Tämä pakottaisi toimittajat käyttämään ainakin jossain määrin järkeviä prosesseja, ja kehittäjien vaihtuvuus tulisi heti näkyviin.

    • Minulla on vähän sama huoli. Epic Systems sanoo aivan suoraan, että avoimet rajapinnat eivät kuulu heidän toimintatapaansa. Eli Apotissa täytyy joko vesittää avoimien rajapintojen vaatimus tarkoittamaan ei juuri mitään, tai sitten valinta ei voi kohdistua Epiciin.

      Tai teoriassa Epic voi tietenkin muuttaa politiikkaansa, mutta siihen en usko. Suljettu ekosysteemi on se, millä he tekevät katteensa. TUskin lähtevät siitä joustamaan yhden pienehkön asiakkaan takia.

    • (Otson kommentteihin ei voi vastata?)

      Juu Epicillä on kyllä vahvat intressit olla toteuttamatta avoimia rajapintoja. Heidän kannalta iso riski on että joku muukin asiakas vaatii sellaisia, joten on toimittajan intresseissä että tää rajapinta-usuus menee projektissa oikein kunnolla perseelleen ja maksaa toimittajalle vähintään tulevien kilpailutuksen mahdollistamien säästöjen verran.

    • Tää WP:n käyttöliittymä ei toimi tähän ihan ideaalisti. Poimimalla reply-napin tuolta ylempää ykköstason viestistä josta keskustelu lähti, se tulee saman threadin loppuun.

      Rajapintojen osalta käytännössä: jos niitä halutaan, ja ollaan valmista tuotetta ostamassa, niin sitten pitää valita tuote, jonka toimintastrategiaan ne ennestään kuuluvat. Ekosysteemin avoimuus tai suljettuus on aika liiketoimintastrategian ytimessä, eikä kansainvälinen toimija vaihda sitä yhtä asiakasta varten. Eli jos väittäisikin tarjoavansa avoimet rajapinnat, niin tuskin tarjoaa, jos ei ole ennenkään toimintamalliin kuulunut.

  3. Voiko tavallinen kaupunkilainen auttaa mitenkään saamaan näihin IT-asiohin järkeä? Kirjoittaako kaupunginjohtajalle vai Hesariin vai mitä voi tehdä?

    Hesarin jutussa mainittu Helsingin kaupungin IT-jaos kuulostaa loistavalta idealta, mikäli siellä oikeasti saadaan katsottua kaupungin kaikkiin IT-hankintoihin vähän järkeä.

  4. Minusta on käsittämätöntä että näihin julkisen puolen tietojärjestelmiin saadaan jatkuvasti kulumaan (kymmeniä) miljoonia rahaa. Yksityisellä puolella muutaman opiskelijan porukka pystyttää pienessä ajassa sellaisia sivustoja kuin Facebook, airbnb, Piratebay, jne. jne., jotka ovat sekä palvelun monimutkaisuuden että käyttäjämäärän mukaan laskettuna huomattavasti hankalampia projekteja. Olen ihan varma, että jos tämäkin projekti oltaisiin annettu jonkun kankean konsulttien johtaman IT-firman sijaan teekkareille harjoitusprojektiksi niin oltaisiin päästy samaan tai parempaan laatuun käytännössä ilmaiseksi.

    Kuten sanot, avoimet rajapinnat auttaisivat jo huomattavasti. Kokonaan avoin lähdekoodi vielä enemmän. Lisäksi vaadittaisiin jonkinlaista hajua myös ostajapuolelta miten tällaisia projekteja käytännössä toteutetaan. Ohjelmiston koodaaminen ei ole samanlaista työtä kuin moottorityön rakentaminen; firman koko ja koodareiden määrä ei välttämättä tuota hyvää lopputulosta ja koko projektia ei voida tehdä alusta loppuun kerralla, vaan ohjelmisto väistämättä elää elämäänsä ja vaatii jatkokehittämistä aina ensimmäisestä betaversiosta lähtien.

    • Täsmälleen näinhän se on. Tosin jos ja kun alla on 80-luvulta peräisin oleva viritys, johon ei ole rajapintoja, ei nähtävillä olevaa lähdekoodia eikä välttämättä dokumentaatiotakaan, niin kyllä siinä saattaisi mennä teekkariporukalla sormi suuhun. Ja oikea virhehän on tietenkin se, että moisen loukkujärjestelmän kanssa on jääty naimisiin vuosi toisensa jälkeen.

      Yksi tuttu oli Tampereen kaupungille tarjonnut johonkin vastaavaan ratkaisuun mallia, jossa heidän pieni ketterä firmansa tekisi sähköisen lomakkeiden vastaanoton, mutta koska rajapinnat puuttuvat, yksi ihminen palkattaisiin kopypasteamaan tietoja järjestelmästä toiseen. Vaikka ajatus kuulostaa pähkähullulta, niin se olisi silti luultavasti halvempaa, kuin maksaa loukkusoftan toimittajalle kymmenkertainen hinta, tai että 10 korkeastikoulutettua ihmsiteä tekee työt paperiprosessilla. No, Tampere ei suostunut.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *