Apotin päätöksenteko siirrettävä tietotekniikkajaostolle

Parempaa päätöksentekoa
Apotti on enemmän tietojärjestelmä kuin sotejärjestelmä. Helsingin osalta Apotin päätökset tekee kuitenkin sote-lautakunta tai sen virastopäällikkö:


”Saimme juuri Apotin hanketoimistolta tiedon, että alla mainittu päätöksenteko Apotin välikarsinnasta siirtyy elokuulle. Uusi päätösaika on 11.8. Uusi aikataulu mahdollistaa samanaikaisen päätöksen Helsingissä, HUS:issa, Kauniaisissa ja Vantaalla.”


”Apotti-järjestelmähankinnan kevään neuvottelut on saatu päätökseen ja hankkeen ohjausryhmä (puheenjohtajana apulaiskaupunginjohtaja Laura Räty) on käsitellyt neuvottelujen tuloksen kokouksessaan keskiviikkona 18.6.2014. Ohjausryhmä päätti omalta osaltaan välikarsinnasta, eli siitä mitkä toimittajat valitaan jatkoon. Näille jatkoon valittaville lähetetään syksyn aikana lopullinen tarjouspyyntö. Tämä välikarsintapäätös tulee nyt jokaisen hankintaan osallistuvan tahon päätettäväksi. Helsingissä sosiaali- ja terveyslautakunta on 17.12.2013 (§423) delegoinut päätöksenteon virastopäällikölle.


Juha Jolkkonen tekee päätöksen ensi viikolla vs. virastopäällikkönä. Normaalin ottoharkintamenettelyn mukaisesti päätös tulee lautakunnan puheenjohtajan ottoharkintaan 1.7.2014.”


Poliitikkojen tehtävä ei ole toimia hanketoimistonkaan virkamiesten kumileimasimena, vaan haastaa ja arvioida tehtyjä valintoja. Tämä parantaa hankinnan laatua ja pienentää riskejä.


Sote-lautakunnan tietotekninen pätevyys on heikko. Lisäksi sote-lautakunnan haasteena on hyvin laaja ja monimutkainen tehtäväkenttä. Näistä syistä kohtuullisenkin kokoiset it-asiat jäävät lautakunnassa heikolle käsittelylle – puhumattakaan Apotin kokoisesta megahankkeesta. Vapaaehtoistyönä politiikkaa tekevillä on vain rajallinen määrä tunteja käytettävissä asioihin perehtymiseen. Lisäksi it-asiat ovat monella vahvimman osaamisalueen ulkopuolella.


Kaupungin kannattaisi siirtää Apotin päätöksenteko sote-lautakunnasta asiantuntevammalle elimelle eli tietotekniikkajaostoon. Jaoston, kuten myös lautakuntien, päätökset ovat luonnollisesti kaupunginhallituksen otto-oikeuden alaisia.


Poliitikoille enemmän it-osaamista ja -uskallusta
Poliitikot pelkäävät it-asioiden käsittelyä ja it-projektien ohjaamista, vaikka ne esimerkiksi fyysisen maailman rakennusprojekteja paremmin soveltuvat pätkittäviksi pienempiin osiin. Tällöin riskit ja kustannukset ovat paremmin hallinnassa ja vaatimukset toteutuvat varmemmin.


Poliitikkojen toivoisi näkevän hieman vaivaa ja lukevan edes yhden ohjelmistoja koskevan yleisteoksen, kuten esimerkiksi Ian Sommervillen “Software Engineering” (löytyy esim.) tai muutoin perehtyvän aiheeseen. Yliopistojen kurssit tarjoavat ilmaista ja avointa materiaalia ja opetusta. Kannattaa tutustua esimerkiksi Helsingin Yliopiston Tietojenkäsittelylaitoksen Ohjelmistojärjestelmien erikoistumislinjan kursseihin.


Apotti ei lähtenyt liikkeelle onnellisten tähtien alla
Jälkikäteen viisasteltuna Apotti meni liian suurena hankkeena liian helposti läpi poliittisen päätöksenteon. Tämä kritiikki koskee yhtäläisesti kaikkia puolueita. Valtuuston  Apotista käymä keskustelu kuvaa hyvin muutamien valtuutettujen sinänsä arvokasta yritystä ottaa hanketta haltuun tuoden joitain riskejäkin esiin, mutta osoittaa valtuuston yleisen kyvyttömyyden päättää tämänkokoisesta it-hankkeesta ja suhteuttaa sen eri tasoisia riskejä ja ulottuvuuksia.




Perusteellinen poliittinen seuranta?
Hyvä olisi arvioida kuinka hankkeen seurannan ja ohjauksen nykyiset prosessit toteuttavat valtuuston hyväksymää pontta:

“Hyväksyessään asiakas- ja potilastietojärjestelmäpalvelun hankintamenettelyn kaupunginvaltuusto kehottaa sosiaali- ja terveyslautakuntaa selvittämään, miten hankkeen perusteellinen seuranta järjestetään Helsingin sisäisesti.”.

Jo edellä mainituista syistä ei voida puhua laadukkaasta tai perusteellisesta seurannasta.

Virheitä tulee myös jatkossa Helsingin ohjelmistoihin

Helsingin Sanomat uutisoi virheestä Helsingin sähköisessä avustusjärjestelmässä. Kaupunki ei kuitenkaan tule koskaan hankkimaan virheetöntä softaa, koska sellaista ei ole olemassa. Olennaisempaa olisi pohtia millä hinnalla (hankinta, ylläpito, jatkokehitys), laadulla (käytettävyys, tietoturvallisuus, suorituskyky jne.) ja toiminnallisuuksilla kaupunki ohjelmistonsa hankkii. Ohjelmistoja hankittaessa on monia asioita, joista ei kannata maksaa nyt tai myöhemmin ja monia bugeja, joita ei kannata korjata.


Yhden bugisen softan sijaan tulee pohtia kaupungin IT-ekosysteemin kokonaisuutta ja siihen liittyen ohjelmistotuottajiamme laadukkuutta ja tarkoituksenmukaisuutta. Esimerkiksi monasti tuntuu, että kun jokin toimialaan erikoistunut ohjelmistoyritys on saanut jalkansa tietyn viraston ovenväliin ostetaan tältä tutulta toimittajalta räätälöityinä kaikenlaisia mustalaatikkototeutuksia (eli suljetun lähdekoodin toteutuksia, joissa toimittaja omistaa koodin eikä jaa sitä esim. kaupungille.). Eli käytännössä kaupunki maksaa toimittajan uusiin teknologioihin tutustumisen ja ko. ohjelmiston tuotteistamisen kustannukset.


Monet kaupungin hankinnat epäonnistuvat, kuten varavaltuutettu Petra Malin valtuustossa esiin nostama yli 400 000 € maksanut Rakennusvalvontaviraston yritys yhdistää Facta Ahjoon. Toiset, kuten mainittu Ahjo, ovat heikkolaatuisia ja vaativat kaupungin kannalta kalliita korjauksia ja parannuksia. Ohjelmistoja hankittaessa kaupungille aiheuttaa kustannuksia myös puutteellinen elinkaarikustannusten suunnittelu ja syntyvät toimittajaloukut.


Kaupunki on suuri, yleishyödyllinen ja monialainen toimija eivätkä kaupungin perustehtävät muutu yhtä usein kuin monien firmojen. Tästä johtuen kaupungin kannattaisi panostaa enemmän avoimeen lähdekoodiin, avoimiin rajapintoihin ja datan avoimuuteen.


Kaupungin IT-kokonaisuuden pohdinnassa voisivat kaupungin omien virkamiesten lisäksi hyvin olla mukana kolmatta tehtäväänsä toteuttamassa yliopistot tutkimuksen ja seminaarien muodossa.


Tulee muistaa että, tietotekniikkajaoston rooli on neuvoa-antava ja vastuun ohjelmistohankinnoista kantavat edelleen virastot (lautakunnat), hankintakeskus (teknisten palveluiden lautakunta), kaupunginhallitus ja valtuusto. Paljon riippuu siitä kuinka jaoston neuvoja ja ohjeita kuunnellaan ja toteutetaan. Monissa kymmenissä hankkeissa pallo jo pyörii eikä jaosto ennätä niihin paljoakaan puuttumaan, suurimpana esimerkkinä mainittakoon Apotti. Jos nykyisen muotoinen tietotekniikkajaosto olisi ollut olemassa ei Apotti olisi todennäköisesti päässyt valtuustossa läpi näin puutteellisena ja riskialttiina kokonaisuutena.

Ja jos jollekin jäi Hesarin jutusta sellainen kuva, että tietotekniikkajaosto on sellainen elin, joka omin pikku kätösin testaa softia syöttäen kenttiin ääkkösiä, niin se kannattaa unohtaa heti.

Helsingin tietotekniikkajaoston jäseneksi

”…Viimeinen syksy
Byrokraatit virastoihin homehtukoon
teknokraatit näppäryyten sortukoon
aristokraatit nenäänsä venyttäköön
fallokraatit potenssin menettäköön…”
Pelle Miljoona
Helsingin Kaupunki perusti tietotekniikkajaoston ja valitsi minut jäseneksi. Olen innoissani, sillä jaostolla on hyvä mahdollisuus konkreettisesti vaikuttaa kaupungin toimintaan ja palveluiden tehokkuuteen ohjaamalla kohtia parempia it-järjestelmiä. Kokoluokka on suuri. Kaupungilla on n. 100 miljoonan euron it-budjetti (pl. Apotti) ja yli 750 erilaista toimialasovellusta käytössä. Kaupungin järjestelmillä on myös laaja (potentiaalinen) käyttäjäjoukko eli yli 40 000 virkamiestä sekä 600 000 kaupunkilaista. Kaupungin virastoilla on hallussaan myös paljon dataa. Kaikesta tästä meidän helsinkiläisinä tulee ottaa mahdollisimman paljon irti!
Jaoston tulee arvioida nykyistä it-päätöksentekoa kaupungin kokonaisuuden kannalta, kehittää kaupungin it-ekosysteemiä kokonaisuutena ja lisätä avoimen datan, rajapintojen ja lähdekoodin käyttöä.
Kaupunki ei voi enää nykyiseen malliin rahoittaa it-firmojen tuotteistamiskuluja maksamalla suljetusta lähdekoodista. Ostotoiminnasta syntyvät toimittajaloukut takaavat firmoille helpot rahat tuleviksi vuosiksi. Kaupunki ei voi jatkaa nykyistä politiikkaansa ja toimia lypsylehmänä pienelle joukolle hovihankkijoita, jotka toimittavat laaduttomia tai epäonnistuneita järjestelmiä, kuten 400 000 € Facta-Ahjo. Lisäksi kaupungin tulisi muistaa vastuunsa alan kehityksessä, sillä kaupungin laaduton ostaminen vääristää alan kilpailua ja heikentää alan laadun kehitystä Suomessa.
Jaoston tulisi antaa tukea lautakuntien it-päätöksenteolle. Liian usein lautakuntien jäsenet ymmärtävät tai haluavat ymmärtää varsin vähän it-järjestelmien hankinnasta ja elinkaariajattelusta. Seurauksena tuhlataan rahaa, luodaan toimittajaloukkoja, hankitaan laaduttomia järjestelmiä ja aiheutetaan hankaluuksia kaupungin it-ekosysteemille. Ei kuitenkaan ole välttämätöntä luoda kaupunkiin liian keskitettyä it-päätöksentekoa, sillä virastojen pitää tehokkuuden ja laadun vuoksi olla omien järjestelmiensä herroja.
Hankinnat liittyvät usein virastojen toimintamallien kehittämiseen, joka tapahtuu parhaiten askel kerrallaan, aina edellisestä oppien. Hyödyllistä olisi siirtyä iteratiivisiin hankintamalleihin ja uskaltaa kokeilla uusia asioita pienillä, mutta jatkuvilla panostuksilla. Iteratiivinen toimintamalli edellyttää virkamiehiltä halua kokeilla ja valmiutta onnistua tai epäonnistua nopeasti. It-järjestelmien hankintaa tuleekin helpottaa ja lisätä suurten ja kalliiden epäonnistumisten vähentämiseksi.
Ketteryyden karmivana vastaesimerkkinä HUS-hanke Apotti on kokonaisuutena pitkäkestoinen, hintava, vaikutuksiltaan sekä tekijäjoukoltaan hyvin laaja ja toiminnallisuuksiltaan monimutkainen hanke. Hankkeen riskien yhdistelmä on liian suuri etenkin ollakseen nykyiseen tapaan demokraattisen poliittisen ohjauksen ulkopuolella.
Apotilla voi olla ikäviä sivuvaikutuksia nykyisten sosiaali- ja terveyspuolen tietojärjestelmien toiminnalle ja kehitykselle, jollei Apotin aikatauluja, toiminnallisuuksien tarkempia kuvauksia ja tärkeysjärjestystä saada pian luotua. Tätä kuitenkin epäilen huomioiden hankkeen suuret riskit ja epävarmuudet. Huomioitava on, että etenkin sosiaalipuolen toiminnallisuudet ovat helposti lapsipuolen asemassa Helsingin ollessa niiden ainoa tarvitsija. Jaoston tuleekin parhaansa mukaan pienentää hankkeen riskejä ja haittavaikutuksia kaupungille.
Mutta, katsotaan mihin suuntaan jaoston työ lähtee ja kuinka hyvin kaupungin organisaatio osaa ottaa jaostosta parhaan hyödyn irti.

Lääkärit ohjelmistoja ostamassa

Otso nosti hyvin esiin IT-ammattilaisten puutteen Apotti-hankkeessa, mikä riskeeraa hankittavan ohjelmiston laadun. Ohjelmistojen ostamisessa tarvitaan myös ostamisen eli rahan ammattilaisia. Heitäkään ei Apotin hanketoimistossa tai ohjausryhmässä näytä olevan, joten tuleva todennäköinen epäonnistuminen kaupallisissa neuvotteluissa tuntunee myös veronmaksajien kukkarossa nykyistä arviota vahvemmin.

Apotin arvion mukaan laadukas ja toimiva ohjelmisto säästäisi toiminnan tehostumisen kautta sosiaali- ja terveyssektorin kuluja 330 miljoonaa euroa. Hanketoimiston hankintaosaamisen puute kostautuu laaduttomana ja heikosti toimivana järjestelmänä, joka säästöjen sijaan vain aiheuttaa lisää kuluja.

Sosiaali- ja terveyssektori on tärkein kaupunkilaisten hyvinvointiin vaikuttavan kunnan palvelu. Meillä ei ole varaa ohjata sitä heikosti toimivilla tietojärjestelmillä.

Alla kuvaan valitun mallin ja mahdollisia vaihtoehtoisia hankintamalleja pääpiirteissään, yleistäen ja yksinkertaistaen paljon tuodakseni esiin nykytilan riskejä ja vaihtoehtoja.

A) Ostaminen monoliittisesti (tällä hetkellä valittu malli)
Kuvaukset tarpeista ja prosesseista ovat heikot. Hankkeessa mukana olevien sote-asiantuntijoiden tulisikin tehdä enemmän määrittelytyötä (esim. 6kk – 1 v.) ennenkuin niiden pohjalta uskaltaa monoliittiohjelmistoa lähteä hankkimaan. Nyt Hankeilmoitus ja kuvaukset ovat sillä tasolla, että epäonnistuminen on todennäköistä eli kustannukset eivät pidä, ohjelmisto ei toimi tai ohjelmisto ei toimi siten kuin sen tarvitaan toimivan.

Pahimmillaan budjetti ylittyy pahasti eikä ohjelmisto toimi tarpeeksi hyvin tai oikein, mutta sitä ei voi palauttaa. Softan ostamista ei voi verrata minkään fyysisen kohteen, kuten talon tai sillan tai auton, ostamiseen. Ohjelmiston taitamaton ostaja päätyy periaatteessa toimivan, mutta käytännössä erittäin huonosti toimivan tuotteen käyttäjäksi ilman todellista reklamointimahdollisuutta ja saa lisäksi maksaa jokaisesta haluamastaan korjauksesta tai parannuksesta, jos niitä ylipäätään on mahdollista tehdä.

B) Ostaminen / tuottaminen osissa
Riskittömämpi kuin monoliittinen, mutta kuvauksien ja suunnittelun pitäisi olla samoin merkittävästi paremmalla tasolla, ainakin ensimmäisenä aloitettavista osista ja kokonaisarkkitehtuurista. Mutta näiden tekeminen on paljon pienitöisempää kuin yllä mainittujen prosessien.

C) Ostaminen itse tehtynä iteratiivisen kehitysmallin mukaan
Riskittömämpi kuin monoliittinen ja tällöin prosessit voidaan kehittää ohjelmaa kehitettäessä. Tilaajalla on hyvä hallinta kustannuksista ja siitä, mitä ohjelmiston tulee tehdä nyt, ja mitä uutta tai tarkempaa siihen olemme keksineet olennaiseksi seuraavien kehitystyövuosien aikana. Avasin tätä mallia hieman enemmän taannoisessa yleisluontoisessa postauksessani.

Perusedellytyksenä jokaisessa mallissa onnistumiselle on kuitenkin se, että hanke (sekä kaupunki että HUS) osaavat ostaa ja hankkia ohjelmistoja. Osaaminen on nyt hyvin heikkoa, ja päättäjien tulisikin varmistua riittävästä osaamisesta hyvissä ajoin ennen hankeilmoituksen (tarjouspyyntö) kirjoitusta.

Eli, perusosaaminen ensin kuntoon ja sitten hankeilmoitus uusiksi, oli valittu malli mikä hyvänsä.

Nykytilanne Apotissa on pelottava. Ohjelmistojen ostamisen osaaminen puuttuu, veronmaksajien piikki on poliitikkojen toimesta avattu, sote-sektori hukkaa jo nyt resursseja tehottomiin nykyisiin järjestelmiin, hankintalaki pakko-ohjaa huonoon valintaan politrukin lailla ja koko hankkeen johdossa on kokoelma omnipotentteja ja ylimielisiä lääkäreitä.

Kuinka tehdä Apotti avoimella lähdekoodilla

Julkisen ja yksityisen välillä on eroja, joten kunnan tai valtion ei kannata toimia samoilla periaatteilla ohjelmistojen hankinnassa. Julkinen ostaa järjestelmänsä pidempään käyttöön kuin yksityinen ja julkisella on tarve optimoida investointinsa tasaisemmin ja pidemmälle ajanjaksolle. Julkisella on myös tarve toimia avoimesti kansalaisia kohtaan ja kansalaiset ovat samalla sen (pitkälti käyttämätön) voimavara ohjelmistohankinnoissa. Julkista ohjelmistohankintaa ohjaa myös julkisuuslain, hallintolain, henkilötietolain ja substanssilakien antamien reunaehtojen, hyvän hallintotavan ja hyvän tiedonhallintatavan noudattaminen.

Suomalaisten julkisten IT-hankintojen historia on surullisen kallista veronmaksajille – vaikka samaan aikaan julkisen sektorin tehokkuus kärsii monelta osalta kunnollisten järjestelmien puutteesta. Toisaalta Verohallinto on myönteinen esimerkki. Lisäksi Valdassa on ymmärretty luovuttaa kun epäonnistuminen näyttää todennäköiseltä ja hyödynnetty sen sijaan projektin hyviä saavutuksia muissa tiedonohjaushankkeissa.

Espoon kritiikki Apotti-järjestelmästä tuo perusongelman hyvin esiin:

Espoon mukaan asiantuntijalausunnot osoittavat, että Apotti-hankintaan liittyy isoja taloudellisia ja toiminnallisia riskejä. Asiantuntijoiden näkemykset eivät tue Apotin kaltaisen monoliittisen asiakastietojärjestelmän hankintaa esitetyllä tavalla.

Mutta seuraavasta perustelusta olen vain osittain samaa mieltä:

Apotti-hankinnassa mukana olevilla seitsemällä organisaatiolla ei ole yhteistä strategiaa, johtamisjärjestelmää tai palvelujen tuottamisen toimintamallia. Riskinä olisi, että hankittava järjestelmä määräisi liikaa toiminnallisia ratkaisuja. Asiantuntijoiden mukaan  toiminnan muutoksia ei saada aikaan tietojärjestelmän kautta vaan uudistamalla ensin toiminnallisia prosesseja.

eli vaatimus prosessien yhtenäistämisestä ennen yhteistä hankintaa on työläs ja kallis. Laki antaa jo nyt hyvän pohjan yhteisille prosesseille ja rajoittaa virkamiesten liiallista sooloilua.

Lisäksi ongelmien ratkaisuksi tarjottu “modulaarinen” rakenne ei kuitenkaan ole olennaisin onnistumisen edellytys, sillä myös modulaarisesti toteutetut ohjelmat voivat kärsiä ongelmista “hankinnan, käyttöönoton ja toiminnan” suhteen.

Tällaisen yhteishankkeen ohjelmistotuotannolliset riskit ovat mielestäni parhaiten hallittavissa iteraativisella kehitysmallilla, joka pohjautuu täyteen avoimuuteen ja julkisen lähdekoodin käyttöön. Tällöin eri organisaatioilla tarvitsee olla summittainen käsitys ohjelman pääpiirteistä sekä toimiva yhteistyö kehityksen suunnan ohjaamiseksi. Avoin lähdekoodi mahdollistaa myös eroavienkin tarpeiden hallinnan samassa projektissa. Ohjelmiston kehittyminen käytettäväksi demoversioksi tukee yhteisten prosessien kehittämistä ja palvelee samalla palautteen ja lisäohjauksen muodossa ohjelmiston kehitystä.

Kehitystyö olisi avoimessa säiliössä (repository), jotta siihen voisi laaja yleisö kommentein ja koodein osallistua. Softan viimeisin versio pyörisi useina julkisina testiversioina, jolloin tulevat käyttäjät ja ketkä vain kiinnostuneet kansalaiset voivat raportoida virheitä, käytettävyyshuomioita ja kehitysideoita.

Kehitykseen sopivaa tai sopivia yrityksiä voisi hankinnan aluksi kilpailuttaa ensimmäisten vaatimusten tuottamisessa julkisesti toimivaksi demoksi. Samalla tekijöiden taidot ja tavat tulevat paremmin arvioitua kuin kilpailutuspapereita täyttäessä.

Jos hankinnalla tulee budjetti- tai aikataulupaineita voidaan toimittajien määrää fyysisestä sijainnista riippumatta lisätä tai vähentää kunhan sopimukset on laadittu tämä huomioiden.

Samoin hankkeeseen osallistujien määrä voisi vaihdella joustavasti ja uusia partnereita voisi saada eri puolilta maailmaa. Jos partnereiden määrä kasva merkittävästi niin silloin kehitys- ja ennen kaikkea ylläpitokustannukset pienenevät minimaalisiksi. Ylläpitohan on tunnetusti n. 90 % prosenttia järjestelmän kokonaiskustannuksista hankinnan kustannusten ollessa n. 10 %.

Mutta rajoitteitakin toki on. Hyvällä tarkoituksella tehdyt lait ja asetukset julkisista hankinnoista sekä VM:n “ohjaus” eivät vanhakantaisuudessaan kaikilta osiltaan ehkä mahdollista veronmaksajien varojen optimaalista käyttöä. Jos näin on, lakia olisi syytä muuttaa tinkimättä kuitenkaan niissä säädetyistä laatukriteereistä.

Tuntuu kuitenkin siltä, että tämän Apotti-MUMPS-hankkeen kohdalla ollaan jo menty metsään. Paetkoon siitä laivasta ken voi. Pitää selvittää mitä asialle voi vielä tehdä.