Soten tekninen velka

Kirjoitan blogissani sotesta ohjelmoijien käyttämän teknisen velan käsitteen kautta.

Laitan tähän kopion koko tekstistä, ihan periaatteen vuoksi.

Uudet hyvinvointialueet perivät monet edeltäjäkuntiensa veloista. On kuitenkin pirullinen velan muoto, joka tulee määrittämään suuren osan hyvinvointialueiden arjesta eikä näy lainkaan taseessa.

Ohjelmoijilla on tapana puhua teknisestä velasta. Sitä otetaan, kun teknisessä toteutuksessa oikaistaan, jotta saadaan asiakkaalle tuote ulos mahdollisimman pian. Velalla saadaan siis valmis tuote, mutta velka alkaa myös kasvaa korkoa. Huonot ratkaisut puraisevat nilkkaan seuraavaa ominaisuutta rakennettaessa ja viimeistään harmi tulee, kun esimies tajuaa, että teknistä velkaa otettaessa tiimille on välittynyt selvästi, ettei laadulla ole niin väliä.

Tekninen velka on luonnollisesti vertauskuvallista. Kyse on teknisistä puutteista ja ennen kaikkea organisaation itselleen aieheuttamasta kyvyttömyydestä muuttua. Sote-alalla tekninen velka ei ole ainoastaan rahallista, vaan myös potilasturvallisuus- ja tehokkuuskysymys. Jos järjestelmiä olisi helppo jatkokehittää, voitaisiin potilasturvallisuutta vaarantavat virheet ja henkilökuntaa jatkuvasti ärsyttävät käytettävyyskukkaset liiskata alta aikayksikön.

Liisa Hyssälä arvioi twiitissään, että jo hänen aikanaan maassa oli 4 200 erilaista sote-alan ICT-järjestelmää. Esimerkiksi Länsi-Uudenmaan alueella järjestelmiä on yli 30. Näitä ei aiotakaan yhdistää lähiaikoina, koska pelkästään kartoitukseen ja minimitason integraatioon menee koko varattu aika. Tämä jos mikä on teknistä velkaa: yhteensopimattomat järjestelmät estävät kehittämästä toimintaa koko hyvinvointialueen laajuisesti.

Asiat voisivat olla toisin. Vuonna 1991 lakkautetun lääkintöhallituksen tehtäviin kuului potilastietojärjestelmien koordinointi ja valvominen. Keskusvirastolla oli laaja toimivalta ohjata ja määrätä sote-toiminnan toteuttamisesta kunnissa. Nykyään vastaavia tehtäviä toteuttaa pääsääntöisesti THL, jonka tehtävät rajautuvat kuitenkin kuntien ja sairaanhoitopiirien tukemiseen tehtävissään.

Jos jokaisen potilastietojärjestelmähankinnan kohdalla kysyttäisiin, olisiko mahdollista hyödyntää jonkin toisen vastaavassa tilanteessa olevan kunnan järjestelmälisenssiä, jakaa oppeja eri toimittajien hankinnoista ja ehkä jopa jakaa kansallista lisenssipoolia eri järjestelmiin, oltaisiin varmasti eri kypsyyden tasolle. (Tiedän, hankintalainsäädäntö ei mahdollista huonon toimittajan rokottamista huonojen kokemusten perusteella. Ceterum censeo, sekin pitäisi korjata.)

Tykkään puhua paljon kokeilukulttuurista, ja ensi kuulemalla keskusvirastot ja kokeilukulttuuri ovat keskenään ristiriidassa. Näin ei kuitenkaan ole: laadukkaassa kokeilukulttuurissa kokeilut ovat hyvin suunniteltuja, niille on asetettu selkeät tavoitteet, niitä arvioidaan ja niiden opit levitetään systemaattisesti kaikkialle. Tällaista toimintaa varten tarvitaan prosessin omistaja, jolla on isännän elkeet, mielellään myös valtaa. Tarvitaan halukas toteuttaja ja vastuullinen kokeilun tilaaja.

Kun isäntää ei ole, kissat hyppivät pöydällä ja teknistä velkaa kertyy. Onneksi hyvinvointialueita on vähemmän kuin kuntia, joten jatkossa toivottavasti koordinointi ja yhdessä oppiminen on helpompaa.

Teknisen velan ratkaisuksi ehdotetaan usein ns. greenfield-projektia, jossa lähdetään rakentamaan uutta ratkaisua tyhjältä pöydältä. Tätä vastaan on helppo argumentoida sillä, että meillä on jo toimiva järjestelmä ja uusi projekti tekisi vain kaikki samat virheet uudestaan. On myös todennäköisesti totta, että uusi järjestelmä kokisi toisen järjestelmän syndrooman, eli se paisuisi “kaikki vanhat viat korjaavaksi” Iisakin kirkoksi, joka ei valmistu koskaan.

Onneksi tähänkin on ratkaisu. Ketterässä kehityksessä järjestelmiä kehitetään jatkuvasti yhteistyössä käyttäjien kanssa niin, että käyttäjät saavat joka kehityskierroksella toimivan järjestelmän käytettäväkseen. Uskoisin, että esimerkiksi suomalaisen Esko-järjestelmän väki voisi olla hyvin kiinnostunutta tekemään yhteistyötä yksittäisten osajärjestelmien korvaamiseksi. Korvaaminen voidaan vaikka tehdä yhdessä yksikössä niin, että ohjelmoijat näyttävät henkilöstölle prototyyppejä vaikkapa kerran viikossa. Kun järjestelmä saadaan toimimaan yksikössä hyvin, toistetaan sama toisessa, ja ohjelmoijat voivat hiljalleen siirtyä taka-alalle kun lastentaudit on liiskattu yhdessä.

Tämä ei ole utopiaa, eikä tietenkään edellytä Eskoa. Se vaatii oikean asenteen hankkijalta, jonka pitää uskaltaa vaatia perinteisestä vesiputousprojektista luopumista. Se vaatii oikean toimittajan, joka sitoutuu tekemään parasta mahdollista yhdessä hankkijan kanssa. Se vaatii henkilöstöä, joka on valmis heittäytymään prosessiin.

Vastuullisella ja laadukkaalla ohjelmistohankinnalla voidaan alkaa siivota vanhaa teknistä velkaa, mutta aivan ensiksi sen olemassaolo täytyy tunnustaa. Kun kuvaamani järjestelmistä aiheutuvat prosessiongelmat myönnetään ja arvioidaan objektiivisesti, on jo paljon luontevampaa keskustella teknisen velan vähentämisestä. Kun tämä keskustelu on käyty, voidaan ottaa modernin ohjelmistokehityksen keinot käyttöön ja tehdä sotesta paljon parempaa kaikille: henkilöstölle, asiakkaille ja veronmaksajille.

6 Likes

Juuri näin. Tulevien 1000+ aluevaltuutetun joukossa valitettavan pieni osa on kovin perillä tämänkaltaisista ajatuksista.

Tietopolitiikka.fi porukalla ollaan tekemässä tiivistä sote-it + alueuudistus 101 paprua, ehkä haluat osallistua sen kommentointiin @jannepeltola ?

Mielelläni, kiitos! Yritän lähipäivinä kirjoittaa tälle vielä jatko-osaa.

1 Like

Hei! Hyviä pointteja. Teen itse töitä digitaalisen terveydenhuollon parissa palvelumuotoilijana. Siirtymisessä ketterämpään tekemiseen on nähdäkseni muutamia käytännön esteitä, jotka pitää ensin ylittää:

  • hankinnat ja ostaminen asiakkaalla, kuten jo mainitsitkin. Siihen liittyy myös lainsäädäntö ja perityt käytännöt.
  • sote-tekijöiden ajankäyttö. Yleensä kehittäminen tehdään eri porukalla kuin varsinainen tekeminen. Ylimääräistä resurssia kehitysprojekteille ja yhteiskehittämiselle/kokeilulle pitää siis hakea myös työajasta. Käytännössä kehitystehtävien ajaksi ei välttämättä saa sijaista nykyisellään, kun pyritään maksimaaliseen tehokkuuteen ajankäytössä.
  • missä on asiakas? (Potilastieto- yms) järjestelmähankkeiden lopputulos ei tyydytä veronmaksajia, jos ne tehdään ainoastaan henkilökunnan näkökulmasta nykyisten toimintamallien ja (erikoissairaanhoidon) hierarkkisen kulttuurin lähtökohdasta. Siksi prosessiin pitää ottaa asiakasymmärrys aina mukaan.
  • Kulttuurinen ja toimintatavan muutos: ketterä tekeminen ja usein julkaiseminen ei ole käyttäjän näkökulmasta aina miellyttävää ja helppoa, vaan vaatii ymmärrystä ja joustavuutta omaan työhön sekä siihen, että kaikki ei aina toimi täydellisesti eikä kuten aiemmin. Tähän tarvitaan henkisiä resursseja eikä se välttämättä onnistu, jos työkuorma on valmiiksi liian kova. Lisäksi edelleen voimassa oleva hierarkinen toimintatapa ei välttämättä tee helpoksi kokeilla asioita. Kokeilukulttuurissa lähtökohtana on, että jokaisen ideat ovat yhtä tervetulleita.
5 Likes

Lisäisin tähän vielä toisaalla mainitun ’profession käsitteen’, vahva lääkärivalta ei aina edesauta onnistumista IT-hankinnoissa ja k
kehittämisessä.

2 Likes