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ä.