Avainsana: hus

It-hankintaprojekti sairastaa

Kauppalehti julkaisi tänään Debatti-palstallaan oheisen mielipidekirjoituksen, jonka kirjoitimme yhdessä työpaikkani Codenton toimitusjohtajan, Petri Aukian kanssa.

Alla myös teksti muodossa, jossa sen lähetimme. KL teki tavanomaiseen tapaan pientä journalistista editointia.

Debattikirjoituksemme Kauppalehdessä 24.9.2012

Suomeen on syntynyt julkisen sektorin it-järjestelmien osalta hankintakulttuuri, jolla on kahdenkymmenen vuoden epäonnistumisen historia. Voitaisiin kai sanoa, että it-projekteissa on systemaattisesti epäonnistuttu jo niin pitkään, ettei kukaan enää odota muuta.

Tällainen toimintatapa ei tuota IT-alan ”Nokioita”, yrityksiä, jotka omalla alallaan ylittäisivät kansainväliset rajat ja tavoitteet. On toimittava toisin, jotta saadaan muodostettua kansallisia voittajayrityksiä ja niiden tyytyväisiä asiakkaita.. Esimerkiksi Posti, joka Nokian kanssa aikanaan loi NMT-verkon ja oli aikoinaan nousukiito Soneran menestykseen.

Menestymättömyyden vertailukohtaa voi hakea vaikka urheilusta: jos kestävyysjuoksussa ei ole viime vuosikymmeninä hurrattu kansainvälisillä kentillä, kukaan ei ole pettynyt, jos mitaleita ei tule. Eivät edes valmentajat ja urheilijat itse. Tehdään niin kuin on aina ennenkin tehty, sillä niin ei mene ainakaan enemmän pieleen.

Vähän sama asenne näyttää olevat myös it-hankinnoissa. Julkinen sektori ostaa sinnikkäästi samoilta tahoilta, arvioinneissa käytetään vanhoja tuttuja menetelmiä ja projektit vedetään läpi aivan niin kuin ennenkin. Tehdään varman päälle – niin ei ainakaan voi saada potkuja. Mutta ei myöskään kehitytä.

Erityisen huono menestys on terveydenhuollon it-järjestelmien suhteen.

Viimeaikoina esille ovat olleet HUSin tietojärjestelmäprojektit. Muutenkin otsikoissa on ollut, kuinka suomalaiset terveydenhuollon järjestelmät maksavat 50 kertaa enemmän kuin Viron. Näyttää siltä, että suomalaisten terveydenhuoltojärjestelmien hankinta vaatisi vähän tervehdyttäviä toimenpiteitä, sen verran sairasta homma on.

Kuten monesti aiemminkin julkisen sektorin it-mokien yhteydessä, syyttävä katse suuntautuu järjestelmätoimittajaan. Se ei ole ehkä toiminut asiallisesti, mutta laillisesti kuitenkin. Ostajapuoli kuitenkaan voi paeta vastuutaan alihankkijan selän taakse. Vastuu valinnoista ja päätöksistä kuuluu kuitenkin aina ostajalle. Mikä tietysti edellyttää sitä, että ostajalla pitäisi olla riittävästi osaamista.

Suomalaiseen it-hankintakulttuuriin on juurtunut ajattelumalli, jossa ostetaan ensin mahdollisimman halvalla ja maksetaan toimittajalle sitten enemmän tulevina vuosina erilaisten räätälöintien ja järjestelmäpaikkailujen muodossa. Osittain saattaa olla kyse siitä, että pitää ostaa halvalla. Tällöin myös järjestelmätoimittaja lähettää paikalle halvimmat eli kokemattomimmat tyyppinsä. Osittain on kyse ihan kulttuurista: uskotaan, että näin näiden it-projektien kuuluu mennäkin. Ei kuitenkaan kuulu. Tapa on kallis ja tuottaa huonoa laatua.

Iso-Britanniassa muutama iso it-talo haaskasi vastaavaan terveydenhoitohankkeeseen pari miljardia ennen kuin hanke keskeytettiin.

Yritykset voivat toki hassata rahansa aivan vapaasti sellaisiin investointeihin kuin haluavat, mutta kun leikitään veronmaksajien rahoilla, pitäisi toimia tarkemmin. Esimerkiksi HUS on kuuluisa siitä, että se ylittää vuodesta toiseen budjettinsa. Ja kunnat kaivavat rahat jostain muualta, veronmaksajien taskuista jos ei muuta.

Ostajan osaamista on se, että ostettavat asiat pitäisi kyetä pilkkomaan alaprojekteihin. Väitämme, että yli 100 miljoonan ohjelmistohankkeet epäonnistuvat aina. Kun ne palastellaan järkeviksi kokonaisuuksiksi, onnistumisen mahdollisuudet ovat paljon paremmat. Sadan miljoonan kokonaisuuden työntäminen alihankkijan vastuulle on merkki osaamattomuudesta.

Jokaiseen it-projektiin pitäisi kuulua myös se, että toimittaja voidaan vaihtaa kesken kaiken itse projektin kärsimättä, jos työt eivät etene.

Toivon mukaan julkisella sektorilla ja alalla herätään nyt siihen, ettei kahdenkymmenen vuoden järjestelmäperinteitä enää voida ylläpitää. Ostamisen osaamisen tasoa pitää nostaa. Kyse ei ole pelkästään veronmaksajien rahoista vaan myös siitä, että tietoyhteiskunta tarvitsee toimivia ja ketteriä järjestelmiä.

Otso Kivekäs, asiantuntija, Codento

Petri Aukia, toimitusjohtaja, Codento

Apotin riskit

Sain käsiini APOTTI-hankkeen riskianalyysin, joka terveyslautakunnan kokousmateriaaleissa salattiin. Se on julkinen dokumentti, joten jaan sen tässä, olkaa hyvät. Postausta on muokattu.

Mitä raportti sanoo?

Tämä on bisnestason analyysi siitä, mitä riskejä hankkeen toteuttamiseen liittyy. Teknisiä riskejä tai hankittavaan järjestelmään liittyviä riskejä ei ole analysoitu. Tämä on ilman muuta virhe, mutta valitettavan yleinen sellainen.

Työmenetelmänä on ollut haastatella hankkeen johdossa olevat henkilöt ja rakentaa yhteenveto heidän esiin tuomistaan huolista. Tästä lähtökohdasta riskianalyysi on sinänsä hyvin tehty, mutta siis hankkeeseen nähden liian suppea.

Muuan riskianalyysejä työkseen tekevä ammattilainen kommentoi:

”Mitään analyysiframeworkkiä tai standardia ei ilmeisesti ole sovellettu, vaan tulosten luotettavuudesta on lähinnä PWC:n sana. Jos otetaan vertailukohdaksi kirjallisuudessa tyypillinen viitekehys

  1. Projects – failing to deliver;
  2. IT service continuity – when business operations go off the air;
  3. Information assets – failing to protect and preserve;
  4. Service providers and vendors – breaks in the IT value chain;
  5. Applications – flaky systems;
  6. Infrastructure – shaky foundations; and
  7. Strategic and emergent – disabled by IT.

Tässä PwC:n paperissa on näistä käsitelty kevyesti ensimmäistä ja viimeistä, ei muita.”

Toinen, 20 vuoden kokemuksella riskianalyysejä tehnyt ja lukenut IT-ammattilainen kommentoi analyysiä ”En ole urallani ikinä nähnyt näin kriittistä analyysiä hankkeesta jota ei ole vielä edes aloitettu”. Hän saattoi toki olla hiukan kyyninen.

”Riskienhallintaan vähemmän tutustuneille suomennoksena:

  1. Konsultti pitää erittäin todennäköisenä, että toimintaa ei saada muutettua hankkeen toteutuksen kautta. Tällä on hankkeen hyötyjen muodostumiselle katastrofaaliset seuraukset.
  2. Muutosjohtajuus, hankkeen vaatimat resurssit ja uuden oppiminen ovat kaikki todennäköisesti menossa pieleen.
  3. (Poliittinen) päätöksenteko hankkeessa epäonnistuu. Päättäjille ei saada oikeaa tietoa ja päätökset tehdään väärien tietojen valossa.
  4. Hankkeen hinta tulee karkaamaan käsistä. (Mikä on konsulttiraportissa poikkeuksellisen voimakas ilmaisu)”

Muutamia huomioita

Sitten vähän yksityiskohtaisempi läpikäynti. Alla omia tulkintojani ja suomennoksiani esiin nostetuista riskeistä. Analyysi kun on kirjoitettu kaunistelevalla konsulttikielellä, jota ei siihen tottumattoman ole aina helppo lukea.

4.1. Hankkeen perusteisiin liittyvät riskit

”Haastatellut kokivat hankinnan laajuuden riskinä sekä tunnistivat kokonaisuuden niin suureksi, että sen ymmärtäminen on haastavaa.”

Kyllä näin on. Normaali johtopäätös olisi pilkkoa hanke ymmärrettävän kokoisiin osiin. Isot IT-hankkeet epäonnistuvat lähes aina juuri siksi, että ne ovat liian suuria ymmärrettäviksi.

”Tuottavuuden kasvun odotukset ja laadulliset tavoitteet pitää varhaisessa vaiheessa konkretisoida mittareiksi, jotka sallivat mahdollisimman vähän tulkinnanvaraisuutta. Jos onnistumista ei konkretisoida mittareiksi jää koko hankinnan menestys subjektiivisten arvioiden varaan ja altistuu spekulaatiolle. Hankkeelle tulee asettaa mitattavissa olevat tavoitteet, joiden toteutumista tulee seurata ja johtaa.”

Niin tulisikin. Miksi sitä ei ole tehty? Jos kyse on ennen kaikkea toimintatapojen muutoshankkeesta, miksi niitä muutoksia ei ole lähdetty hahmottelemaan ensimmäisenä?

4.2. Hankintarengasmalliin liittyvät riskit

”Haastateltavat kokivat HUS:in kaikkein kiireisimmän aikataulun riskiksi, sillä sen koettiin aiheuttaneen tarpeetonta kiirettä hankkeen suunnittelussa ja hankintailmoituksen teossa. Tämän riskin koettiin konkretisoituvan juuri nyt hutiloituun hankintailmoituksen julkaisemiseen ja neuvotteluvaiheen aloittamiseen ilman riittävää suunnittelua.”

Konsultti sanoo, että valmistelua ei ole tehty kunnolla ja että hankintailmoituksessa on ongelmia.

4.5 Hankintaorganisaatioon liittyvät riskit

”Ohjausryhmän työskentelyä pidettiin asiaa edistävänä ja pääasiallisesti tehokkaana, mutta tietotekniikan ja hankintaprosessien substanssiosaamisen koettiin olevan riittämätöntä.”

”Kehittämisryhmän työskentelyssä riskejä nousee haastateltavien mielessä asioiden esittelyn ja aikataulun liiallisesta nopeudesta, yhteisen kielen ja ymmärryksen puutteesta ja keskustelun vähäisyydestä. Asioita on tuota kehittämisryhmään nopealla aikataululla ja haastateltavat kokivat että usein esiteltyjä asioita ja dokumentteja on ollut liian myöhäistä muuttaa. Kehittämisryhmän jäsenistä usea totesi että hankintajuridinen ja tietotekninen sanasto on ongelmallista ja yhteisen kielen puute on hankaloittanut asioiden ymmärtämistä. Riskinä on, että kehittämisryhmä ei pysty täysipainoisesti edistämään hankinnan onnistumista, koska jäsenillä ei ole riittävää hankinnan ja tietotekniikan substanssiosaamista.”

Ensinnäkin, niinhän minä sanoin: osaamista tarvittaisiin lisää. Toisekseen, tästä tulee huolestuttavasti kuva, että hanketoimiston yläpuolisessa ohjauksessa ollaan aika tuuliajolla, eikä tosiasiallista mahdollisuutta tai kykyä ohjata hanketta ole. Hanketoimisto työskentelee siis hyvin itsenäisesti, ilman että sen tarvitsisi kuunnella ulkopuolisia. Tämä vastaa kuvaa, joka erityisesti HUS:n toiminnasta on perinteisesti ollut ja josta ehdottomasti pitäisi päästä eroon.

”Riskienhallintatoimenpiteet eivät ole vielä konkretisoituneet työkaluiksi vaikka keskustelu riskeistä ja niiden vaikutuksista onkin moniulotteista.”

Konsulttikielellä tässä lukee, että riskien hallitsemiseksi ei ole tehty mitään.

”Hanketoimisto on mitoitukseltaan minimaalinen verrattuna hankinnan laajuuteen, sen resurssien pieneneminen olisi merkittävä riski ja vaarantaisi hankkeen onnistumisen.”

Konsultin mielestä hanketoimisto ei ole tehtäviensä tasolla.

4.6 Kilpailuttamiseen, neuvotteluvaiheeseen ja sopimukseen liittyvät riskit

”Koska valmiita järjestelmiä tällä puolelle on hyvin rajallisesti ja ulkomaisissa järjestelmissä ei ollenkaan, ei järjestelmätoimittajien voida ajatella pystyvän demonstroimaan valmiita ratkaisuja.”

Konsultti huomauttaa, että tässä ei olla ostamassa valmista järjestelmää vaan järjestelmä räätälöidään joka tapauksessa HUSin ja kuntien käyttöön. Senhän toki tiesimmekin, mutta päinvastaistakin kuvaa yritetään julkisuuteen antaa.

”Sosiaalihuollon asiantuntijaryhmän perustaminen hanketoimiston alaryhmäksi on välttämätön ja kiireellinen riskienhallinta toimenpide. Ryhmän tulisi valmistautua neuvottelumenettelyyn luomalla tavoitetila ja määrittelemällä hankintaa niin konkreettiseksi että se on kommunikoitavissa palveluntuottajaehdokkaille.”

Konsultin mukaan hankkeessa ei siis tunneta sosiaalihuollon vaatimuksia, eikä järjestelmä luultavasti tule niitä palvelemaan. Miksi sosiaalihuoltoa edes yritetään tuoda mukaan samaan hankkeeseen, kun onnistumisen edellytyksiä ei tunnu olevan?

”Suuressa osassa haastatteluita nousi esille riskinä prosessien määrittelemättömyys ja tavoiteltavan IT-arkkitehtuurin kuvauksen puute.”

Hankkeen tavoitteita ei siis oikeastaan ole määritelty. Riski, jota on kansalaiskeskustelussa pidetty merkittävänä.

”Riskiä hankeorganisaation erimielisyyksistä liittyen määrittelyyn tulisi hallita antamalla selvitys siitä miksi nykyiseen toimintamalliin on päädytty.”

Haastateltavat siis ihmettelevät, miksi hanketoimisto toimii sammutetuin lyhdyin. Vahvistaa valitettavasti ylläkin jo syntynyttä kuvaa ongelmallisesta johtamistavasta.

”Suurimpana kustannustenhallinnan riskinä pidettiin sitä, että palvelun oston hinta muodostuu kokonaisuutena paljon ennakoitavaa suuremmaksi. Tämä liittyy olennaisesti ”jälkilypsyn” mahdollisuuteen, eli siihen ettei palvelutasosopimuksessa ole huomioitu kaikkea vaan järjestelmätoimittaja pystyy rahastamaan muutos-, räätälöinti- ja päivitystöillä loputtomasti.”

Kyse on toimittajaloukusta. Valitulla toimintamallilla se on mahdotonta välttää. Välttämisen tapoja olen käsitellyt aiemmin. Niihin kuuluu ennen kaikkea hankkeen pilkkominen, keskeisten osien kontrollin pitäminen itsellä ja avoimuus.

Riskianalyysi ei sen sijaan tarjoa tähän näitä yleisesti tunnettuja vastauksia, vaan ehdottaa, että palkataan hankintakonsultti. Analyysin kirjoittanut PriceWaterhouceCoopers onkin tiettävästi palkattu hankkeen hankintakonsultiksi.

4.8 Implementaatioon liittyvät riskit

”Sekä muutosjohtajuutta että operatiivista muutosta tulee toteuttaa systemaattisesti koko hankkeen ajan. Kaikkialla ei ole vielä otettu muutoksen ensimmäistäkään askelta, nämä organisaatiot tulee tunnistaa riskien hallitsemiseksi ja niiden toimintaan vaikuttaa ensi tilassa.”

Suomeksi: konsultin mukaan hanke on ainakin osin tuuliajolla.

4.9 Viestintään liittyvät riskit

”Viestintään liittyviä riskejä voidaan hallita tehokkaimmin toimimalla proaktiivisesti. Hanketoimiston tulee aktiivisesti huolehtia oikean ja ajantasaisen tiedon levittämisestä sekä hankintarenkaan päätöksenteolle, hankintarenkaiden osapuolille, lehdistölle ja muille kiinnostuneille sidosryhmille.”

Riski selvästikin on toteutunut ja sen hallinta epäonnistunut. Hanketoimsito ei ole kyennyt toimittamaan julkisuuteen oikeaa ja ajantasaista tietoa, vaan päin vastoin keskeisiä päätöksenteon asiakirjoja on pyritty pimittämään julkisuudelta. Esimerkiksi hankintailmoitus ja tämä riskikartoitus jaettiin Helsingin terveyslautakunnassa vain paperilla, jottei niitä levitettäisi julkisuuteen. Erittäin huono käytäntö, mutta valitettavasti ei ainutlaatuinen.

Avoimempi tiedotuskulttuuri olisi varmasti auttanut hanketta paljon. Esimerkiksi väärinkäsitykset 1,8 miljardin euron hinnasta olisivat voineet jäädä syntymättä. Vielä ei ole myöhäistä reagoida tähän riskiin!

4.10 Johtamiseen ja organisointiin liittyvät riskit

”Merkittävimmät johtamiseen ja organisointiin liittyvät riskit johtuvat siitä ettei hankinnan parissa työskentelevien asiantuntijoiden rooleja, vastuita ja valtuuksia ole kuvattu. Tämä riski ei koske vain ohjaus- ja kehittämisryhmään sekä hanketoimistoa vaan kattaa myös kussakin kunnassa työskentelevien asiantuntijoiden toimintaa hankkeessa.”

Suomeksi: konsultin mielestä hanketta ei ole suunniteltu kunnolla, vaan se on kaikilla tasoillaan  tuuliajolla tai vähintään aivan liian keskeneräinen päätöksiä varten.

”Ohjausryhmään kohdistuu riski siitä, että heidän panoksensa hankkeen läpiviemiseen jää pinnalliseksi ”tuen antamiseksi”. Tukemisen sijaan vaativa hanke vaatii johdolta todellista sitoutumista ja panostusta hankalienkin asioiden läpivientiin. Lisäksi johdon tulee investoida aikaansa aihealueeseen perehtymiseen, jolla parhaiten vältettäisiin riski siitä että päätöksiä tehdään vajavaisin tiedoin.”

Suomeksi: konsultin arvio on, että johtoryhmä ei ole tilanteen tasalla.

Liite 1: : Haastatellut asiantuntijat

”Hanketoimisto antoi 21 henkilön listan haastateltavista henkilöistä. Näistä Lasse Lehtonen (HUS) ja Mikko Rotonen (HUS) kieltäytyivät haastattelusta. Tapio Korhosen (Helsinki) kanssa ei saatu sovittua sopivaa haastatteluaikaa hänen kiireisen kalenterinsa vuoksi.”

Siis hankkeen projektipäällikkö ja hanketoimiston keskeisin puuhamies kieltäytyvät riskienhallintakonsulttien haastattelusta. Aikatauluongelmat voi ymmärtää, sellaista sattuu, eikä aina voida jäädä odottamaan jokaista. Mutta suora kieltäytyminen on varovaisesti sanoenkin hyvin erikoista.

Jos aiemmat kriittiset huomautukset voisikin ajatella konsulttien ylivarovaisuudeksi (ja tulkintani niistä ylireagoinniksi), niin tässä kohti viimeistään syntyy kuva, että hankkeen johtamisessa on nyt jotain pahasti ongelmallista.

Mitä raportti ei sano

Vielä merkittävämpää kuin riskianalyysin sisältö on, se mitä siinä ei ole.

  • Teknisiä riskejä ei ole käsitelty juuri lainkaan.Selvästikin tarvitaan vielä erillinen riskianalyysi siitä, miten itse järjestelmän mahdollisiin ongelmiin varaudutaan. Tätä on syytä käsitellä jo ennen hankintaa, koska riskeihin täytyy reagoida jo kokonaisarkkitehtuurissa (jota ei ole ainakaan julkaistu, jos on suunniteltu).
  • Vertailua saman kokoluokan epäonnistuneisiin hankkeisiin (esimerkiksi NHS) ei ole tehty. Miten aiotaan välttää brittien virheet?
  • Vaihtoehtoja yhteen toimittajaan sitoutumiselle toimittajaloukon välttämiseksi ei ole käsitelty.
  • Riskiä, että järjestelmää joudutaan vaihtamaan uudestaan ei ole käsitelty lainkaan. Muuan IT-ostopäällikköä siteeratakseni ”ensimmäinen mitä kysyn on aina, että miten systeemistänne pääsee sitten aikanaan eroon”. Nyt HUS aikoo käyttää satoja miljoonia päästäkseen eroon Uranuksesta. Paljonko Apotista luopuminen tulee maksamaan?

Yhteenveto

Hankkeesta tulee tämän raportin perusteella ongelmallinen kuva. Vaikuttaa siltä, että hanketta ajetaan kuin käärmettä pyssyyn, eikä osaaminen ole riittävällä tasolla näin suureen hankkeeseen. Valittu toimintatapa on koettu ongelmalliseksi, mutta halukkuutta keskustella siitä ei ilmeisesti hankkeen johdossa ole.

Hankkeen johtajaa Lasse Lehtosta lainatakseni, ”Kritiikki ei vaikuta hankintaan”.

Tältä pohjalta täytyy sanoa, että riittävää riskianalyysiä hankkeen käynnistämiseksi ei ole tehty. Sitä ei tosin tarvitakaan, koska jo tämä kevyt analyysi osoitti johtamisessa ja toimintatavoissa merkittäviä puutteita, jotka täytyy korjata jotta hankkeella olisi onnistumisen mahdollisuuksia.

Apotti potilastietojärjestelmien portilla

Helsingin terveyslautakunta päättää huomenna 11.9. käynnistää kilpailutuksen tietojärjestelmähankinnasta, jossa HUS ja alueen kunnat käyttävät yhteensä noin puoli miljardia euroa terveydenhuollon IT:n kokonaisvaltaiseen uusintaan. Tai siis luultavasti ei päätä, vaan hanke jää pöydälle ainakin kolmeksi viikoksi.

Tässä tekstissä käyn läpi hankkeen taustan, merkittävimmät riskit ja mitä sille pitäisi tehdä.

Taustalla on tavoite hankkia koko maan terveydenhuoltoon yhtenäinen tietojärjestelmä. Sitra selvitti tätä SIRIUS-hankkeessa, jossa selvityksen tehnyt Accenture päätyi suosittamaan, että ostakaa koko roska Accenturelta.

Alkujaan HUS:n ja kuntien hanke oli nimeltään SIRIUS 2, mutta kun Hesari uutisoi Accenturen roolista Siriuksessa, vaihtui nimeksi nykyinen APOTTI. Hankkeilla kun ei kuulema ole juuri mitään tekemistä keskenään. HUS:in hanketta vetävä hallintoylilääkäri Lasse Lehtonen ilmoitti että ”Kritiikki ei vaikuta 
HUS:n potilastietojärjestelmän hankintaan”.

Nyt päätöstä tekee siis Helsinki. HUS, Espoo, Vantaa, Kauniainen, Kirkkonummi, Kerava tekevät sitten kukin tahoillaan saman päätöksen. Tätä ennen kuntien virkamiestyöryhmä on ensin sen suljettujen ovien takana hyväksynyt. Menettelyä voi syystäkin pitää epädemokraattisena, mutta tätä kuntayhteistyö käytännössä on. Ei mennä siihen nyt, tulee vaan paha mieli.

Apotti Saint Dominic of Silos.

Kyse ei ole pelkästä IT-hankkeesta. Päinvastoin, tavoitteena on uudistaa toimintatavat ja prosessit yhdenmukaisiksi ja järkeviksi. Tavoite on kiistatta hyvä. Pitää pyrkiä hyvään toimintaan, ja tietojärjestelmä on tässä vain apuväline. IT-hankkeiden hyödyt tulevat juuri toimintatapojen muutoksista; pelkkä vanhan toimintatavan siirto tietokoneelle ei tuo minkäänlaisia säästöjä vaan ainoastaan lisätyötä.

Yhtenä esimerkkinä hankkeelle on ilmeisesti toiminut USA:laisen Veterans Health Administrationin (VHA) uusiutuminen maan surkeimmasta terveyspalvelujen tuottajasta kärkijoukkoon vuosikymmenessä. VHA:ssa toteutettiin merkittävä toimintatapopjen uudistus, jonka yhteydessä vanha ja huonosti toimiva tietojärjestelmä päivitettiin pala kerrallaan nykyaikaiseksi. Venkatesh et al. kuvaavat artikkelissaan hyvin muutosta ja niitä toimintatapoja, joilla siihen päästiin.

Apotin tavoitelista on myös melkoinen toiveiden tynnyri. Tavoiteltu järjestelmä muun muassa:

  • tarjoaa uusien innovatiivisten palvelujen käytön, asiakkaan oman osallistumisen ja sähköisen asioinnin. Asiakkaan vahvempi osallistuminen lisää tyytyväisyyttä ja voimaantumista vähentäen ulkopuolisen tuen tarvetta.
  • toteuttaa parhaalla mahdollisella tavalla asiakkaan ja potilaan hoidon toteuttamista koko hoitoprosessin ajan riippumatta siitä, missä organisaatiossa kukin hoitoprosessin vaihe tapahtuu.
  • tarjoaa sosiaali- ja terveydenhuollon prosessien tehokkaan ja taloudellisen integraation muiden organisaatioiden ja heidän asiakkaidensa prosessien kanssa.
  • mahdollistaa sen, että kulloisessakin hoitotilanteessa asiakkaan ja potilaan ajantasaiset tiedot ovat luotettavasti käytettävissä.
  • tarjoaa hoitoprosessin eri hoitotapahtumien tuen, ohjauksen ja seurannan.
  • tukee uusien hoitoprosessien aktiivista kehittämistä ja edistää hoitoprosessin laatua, asiakas- ja potilasturvallisuutta sekä kustannustehokkuutta.
  • tukee ammattilaista päätöksenteossa ja ohjaa standardin mukaisiin ratkaisuihin vähentäen toimintatapojen vaihtelua ja parantaen asiakas- ja potilasturvallisuutta sekä hoitotuloksia.
  • mahdollistaa avoimet rajapinnat, joiden kautta kokonaisratkaisuun voidaan liittää tulevaisuuden tarpeita palvelevia lisätoiminnallisuuksia tai vaihtaa yksittäisiä ratkaisun osia.
  • sisältää tiedonsiirtorajapinnan muihin tarvittaviin, kuten esimerkiksi hallinnollisiin järjestelmiin.
  • on käyttäjäystävällinen.
  • toteuttaa sähköisesti modernin käyttöoikeushallinnan, tietoturvan ja suojan sekä niihin liittyvät sujuvat käytännöt (hoitoketjujen hallinta / roolien mukaiset käyttöoikeudet).
  • mahdollistaa yhteisen järjestelmän hallinnan ja hyödyntämisen usean erillisen järjestelmän sijasta.
  • tukee vuoden 2011 alusta voimaan tulleen kotikuntalain muutoksen (1377/2010) ja terveydenhuoltolain (1326/2010) vuonna 2014 voimaan tulevan maanlaajuisen vapaan hakeutumisen sujuvaa toteuttamista.
  • tuottaa hallinnolle ja tutkimukselle tarpeellisia tietoja

Onnistuneiden hankkeiden tavoitteet ovat yleensä kapeasti määriteltyjä ja täsmällisiä. Jos olisin päättämässä asiasta, kysyisin että täsmälleen miten jokainen näistä tavoitteista aiotaan saavuttaa ja miten sitä mitataan.

Minulla on hankkeen suhteen muutama spesifi huoli, niistä alla kolme tärkeintä:

  1. Yritetäänkö tässä ulkoistaa vastuuta?
  2. Riittääkö osaaminen?
  3. Onko valittu teknologia järkevä?

Vastuun ulkoistus

Lääkärilehdessä Lehtonen toteaa, että ”sairaanhoitopiirillä on huonoja kokemuksia järjestelmän kehittämisestä. Se haluaa ostaa valmiin tuotteen ja palvelun, jossa toimittaja vastaa ylläpidosta. Kehitysriski on silloin toimittajalla.”

Näkemys on sivistyneesti sanoen vaarallisen naivi ja herättää epäilyksen, ymmärretäänkö HUSissa oikeasti mitä ollaan tekemässä. Ei tilaajan tarpeisiin laajasti muokattavaa järjestelmää yksinkertaisesti voi ostaa noin.  Tälläinen ”avaimet käteen”-toimitus antaa käytännössä toimittajalle avaimet käteen suoraan tilaajan kassaholviin.

Missään organisaatiouudistuksessa ei voida määrittää etukäteen kaikkia tarpeita. Päinvastoin, ja kuten mainittu VHA:n esimerkkikin osoittaa, on syytä edetä askel kerrallaan. Siksi nykyään suuretkin tietojärjestelmähankkeet pyritään tekemään ns. ketterillä menetelmillä, joissa ei sitouduta täsmälliseen määrittelyyn, vaan opitaan vaatimukset projektin aikana.

Tietenkin voidaan ajatella, että ketteryyttä sovelletaan toimittajayrityksen sisällä, ja HUS vaan saa mitä haluaa: toimivan järjestelmän. Mutta kuinka toimittava yritys voisi päättää sairaanhoitopiirin toimintaprosesseista, jota tässä siis ensisijaisesti haluttiin uudistaa? Ei mitenkään.

Vastuuta omista tietojärjestelmistään ei voi koskaan ulkoistaa. Tietojärjestelmiä tuntemattomalle syntyy helposti houkutus kuvitella että kokonaistoimitus ratkaisee ongelmat. Että IT-toimittaja kyllä hoitaa nämä IT-ongelmat. Mutta ei ole hoitanut tähän mennessäkään, vaan päinvastoin terveydenhuoltoalan IT:tä pidetään katastrofina.

On syytä myös huomata, että yllä mainittu Veterans Health Administration omistaa itse potilasjärjestelmänsä (VistA) lähdekoodin ja jakaa sitä avoimena lähdekoodina. En sano, että VistA mitenkään välttämättä sopisi HUSille, mutta oman tietojärjestelmänsä hallinta on VHA:n onnistuneen muutoksen ytimessä.

HUS ja kunnat sen sijaan tähätäävät malliin, jossa tilaajalla ei ole hallintaa tietojärjestelmään, vaan kaikki kontrolli on sysätty toimittajalle. Tämä asettaa HUSin täydelliseen toimittajaloukkuun. Mikään määrä määrittelyjä tai sopimusehtoja ei voi tätä loukkua välttää, mistä HUSilla pitäisi olla jo pitkä kokemus.

Kompetenssi

Sairaalamaailma on kuuluisa siitä, että lääkärintutkinto on avain etenemiseen, eikä muita kuin lääkäreitä haluta päästää johtopaikoille. Tämä näkyy myös Apotti-hankkeessa.

Apotin ohjaus- ja kehittämisryhmissä on yhteensä 47 jäsentä, joista nopeasti googlaten:

  • 19 lääkäriä
  • 23 erilaista hallintohenkilöä, juristia tai ekonomia
  • 5 joiden työtehtävä liittyy tietohallintoon tai -tekniikkaan. Heistä
    • 2 valtiotieteen maisteria
    • 1 ekonomi
    • 1 tradenomi (logistiikka)
    • 1 jonka koulutus ei selvinnyt.

Näyttäisi siltä, että hanketta vetämässä ei kenties ole yhtäkään IT-alan minkäänlaista tukintoa suorittanutta henkilöä. Muutamilla toki on alan työkokemusta, mutta varsinaista koulutusta ei.

Suomalainen lääkärinkoulutus on vaativa ja korkeatasoinen. Se ei silti pätevöitä märittelemään suuria tietojärjestelmiä. Sitä varten on olemassa ihan omaa koulutustaan.

Teknologia

Apotti-hanke tähtää vahvasti yhteen monoliittiseen järjestelmään. Siis sellaiseen, joka tarjoaa ulospäin vain kauniisti toimivia rajapintoja ja käyttöliittymiä, eikä sisäisestä toteutuksesta tarvitse kenenkään olla kiinnostunut. Esimerkiksi hankkeessa kaikki tiedot halutaan tallettaa yhteen loogiseen tietokantaan (hankesuunnitelma, kappale 2.2.2).

Siis samassa kannassa kaikki tiedot, sisältäen muun muassa:

  • hoitokertomukset
  • asiakkaiden laskutustiedot
  • sosiaalihuollon asiakastiedot (kyllä, joku on nekin tunkenut osaksi hanketta)
  • sairaalan toiminnanohjaus sisältäen laitteistojen käytön

Moderneissa järjestelmissä vastuu pyritää pilkkomaan mahdollisimman pieniin osiin, jotta kukin osajärjestelmä voi tehdä yhden asian hyvin. Esimerkiksi SOA-arkkitehtuuri perustuu tähän periaatteeseen. HUS on valitsemassa vanhanaikaisen monoliittisen arkkitehtuurin, jossa kaikki integroidaan tiukasti yhteen. Tai mikäli pellin alla onkin hyviä rajapintoja, HUS ei halua niitä tietää, vaan ne ovat toimittajan sisäinen asia.

IT-alan yleinen kokemus on, että modernit arkkitehtuurit toimivat paremmin kuin vanhanaikaiset.

Ajatus yhtenäisestä järjestelmästä on ymmärrettävä, kun seuraa suomalaisten potilastietojärjestelmien kaaosta. Mutta ongelma ei ole järjestelmien hajanaisuus. Tanskassa vastaava kokonaisuus toimii hyvin. Ongelma on ostamisen tavassa ja osaamattomuudessa.

Yhteenveto

Onnistuvan laajan tietojärjestelmähankkeen lähtökohtana täytyy nähdäkseni olla:

  1. vahva oma osaaminen tietojärjestelmän kehittämisessä
  2. sen mahdollistama asiakkaan hallintaote siihen, mitä ja miksi kehitetään.

Epäonnistuvat hankkeet taas tunnistaa usien seuraavista merkeistä:

  • Vaatimusmäärittely on maailmojasyleilevä: samaan hankkeeseen on kasattu kaikki maan ja taivaan välillä.
  • Tilaaja pyrkii ulkoistamaan vastuun omasta järjestelmästään.
  • Suunniteltu toimintatapa on epätarkoituksenmukainen eikä vastaa alan parhaita käytäntöjä.

Mitkään merkit eivät nyt viittaa siihen, että kumpaakaan onnistumisen avainkohtaa olisi saavutettu. Päin vastoin, epäonnistumislistalta löytyy rasteja.

Hankkeen oma riskianalyysi (hankesuunnitelma, kappale 6.7) ei näitä ongelmia tunnista. Se mainitsee kaksi riskiä: johtamisongelmat ja sen että entä jos hanke ei toteudu. Tietojärjestelmään tai hankintaprosessiin liittyviä riskejä ei mainita.

Päätösehdotus

No, mitä terveyslautakunnan sitten pitäisi päättää?

  1. Hankkeessa on syytä ottaa aikalisä, ja valmistella se uudelleen avoimemmin. Aivan erityisesti hanke on syytä valmistella siitä lähtökohdasta että kokonaisvastuu pidetään tiukasti tilaajan hyppysissä.

  2. Erityisesti on syytä katsoa malleja, jossa ei tehdä yhtä mammuttihankintaa, vaan vaihdetaan järjestelmiä pala kerrallaan perustuen tilaajan hallitsemaan kokonaisarkkitehtuuriin ja ketterään hankintaan.

  3. Tähän mennessä tehdyt selvitykset ja vertailut julkaistaan kaikki. Ainakin seuraavat dokumentit pitää julkaista
    • Touko–kesäkuussa 2012 tehdyn ulkoinen riskiarvio (viitattu hankesuunnitelmassa, kappale 6.7.)
    • HUSin selvitykset muissa Euroopan maissa tehdyistä vastaavista
    • myös dokumentit, joiden olemassaolo ei toistaiseksi ole vuotanut julkisuuteen pitää julkaista

  4. Perehdytään tarkasti Viron ja Tanskan kokemuksiin ja mitä niistä voitaisiin oppia. Teetetään molemmista konsulttiselvitykset, mikäli olemassaolevat (julkaistavat) selvitykset eivät ole riittäviä.

  5. Tarvittaessa hankkeen johtoa vahvistetaan riittävällä tietojärjestelmäosaamisella. Konsultit eivät riitä korvaamaan oman osaamisen puutteita.

Suomen, Viron ja Tanskan ”eHealth-profiili” EU:n ”eHealt Benchmarking III” -raportissa

Terveydenhuollon IT on Suomessa historiallisesti ollut suljettu luostari, jossa lääkärit päättävät keskenään mitä ja miten tehdään. Tuloksena on ollut katastrofi toisensa jälkeen. Se on ollut maan tapa.

Nyt on kyse siitä, onko apotti tullut luostarin portille avaaman sen ja kutsumaan rahvaan tutustumaan saleihin. Vai onko hän ehkä tullut nostamaan salvan säppiin, jotta mokailu ja sikailu voisi jatkua entiseen malliin.

Vastausta emme vielä tiedä, mutta se portti on avattava. Maan tapa on nyt tullut tiensä päähän.

Toimittajaloukku ja kuinka se vältetään

Taannoinen kirjoitukseni sairaaloiden tietojärjestelmistä sai jonkin verran huomiota, ja myös Hesari innostui aiheesta eilen kirjoittamaan. Eniten huomiota on saanut Accenturen toiminta ja sen moraaliset aspektit. Se on lopulta kuitenkin vain sivujuonne. Oikea ongelma on siinä, miten tietojärjestelmiä ostetaan, ei siinä miten niitä myydään.

Tilanne ei juuri muuttuisi, vaikka järjestelmäksi valittaisiinkin Cerner ja toimittajaksi Logica, tai vaikka Effica ja Tieto. HUS on joka tapauksessa ostamassa yhtä järjestelmää yhdeltä toimijalta, joka samainen toimija tulee sitten toimittamaan myös järjestelmän kustomoinnit, uudet versiot ja tulevaisuudessa tarvittavat lisätoiminnallisuudet. Koska on vain yksi toimittaja, joka voi ne toimittaa.

Tätä kutsutaan toimittajaloukuksi (engl. vendor lock-in). Se tarkoittaa tilannetta, johon varomaton tietojärjestelmän ostaja joutuu valittuaan järjestelmälle toimittajan: kaikki muutostyöt on pakko ostaa samalta toimittajalta, ja tämä voi rahastaa niillä lähes miten haluaa. Myös huono laatu ja hitaus ongelmien korjaamisessa kulkevat yleensä käsi kädessä toimittajaloukon kanssa.

Alalla vuosikymmeniä toiminuttu myyjää lainatakseni, ”Suomessa on haluttu rakentaa järjestelmä, jossa tuotteet myydään halvalla ja raha tehdään ylläpidolla sekä muutostöillä”. Toimittajan vaihtaminen ei siis ratkaise ongelmia.

Koska koen tietynlaista vastuuta myös ratkaista esiin nostamani ongelmat, esittelen tässä kolme tapaa, jolla HUS voisi yhden toimittajan loukun välttää.

Lähtökohta on, että tietojärjestelmä ei koskaan ole valmis tuote. Sitä ei voi ostaa valmiina ja ”vain käyttää”, vaan käyttöönotto on raskas prosessi, jossa sekä muutetaan järjestelmää että muutetaan organisaation toimintatapoja. Ja käyttöönoton jälkeen muutostarpeet jatkuvat. Unohtuneita tarpeita huomataan, ja uusia syntyy.

Mutta tässä ne kolme optiota HUS:lle

Optio 1) sorsat käteen

Mikäli HUSilla olisi pääsy ja käyttöoikeus ostamansa järjestelmän lähdekoodiin, voisi sairaanhoitopiiri teettää haluamansa muutokset kenellä haluaa, tai vaikka tehdä ne omassa IT-organisaatiossa. Tällöin muutostyöt eivät olisi yhtä hitaita ja kalliita, koska niitä tilattaessa vallitsisi ainakin jossain määrin aito kilpailutilanne.

Toki järjestelmän alkuperäisellä tekijällä (ja muilla sen kanssa työskennelleillä) olisi etulyöntiasema, mutta se olisi merkittävästi nykytilannetta pienempi. Toimittajan vaihtamisen kustannus ei olisi satoja miljoonia, vaan ehkä vain satoja tuhansia, joten mahdollisuudet rahastamiseen tai slarvaamiseen olisivat selvästi pienemmät.

Tämä on se ratkaisu, jota aiemmassa kirjoituksessani ehdotin. Käytännössä tämä vaatisi yhtä lisäehtoa tietojärjestelmän kilpailutukseen: ”Osana kauppaa ostaja haluaa järjestelmän koko lähdekoodin, tarvittavat ohjeet ja koulutuksen sen käyttöön sekä oikeuden tehdä itse tai teettää muutostöitä vapaasti haluamallaan toimittajalla.” Juridisesti sitovana ehto olisi varmasti paljon pidempi, mutta olennainen sisältö on tuossa.

On epävarmaa, suostuisivatko ulkomaiset toimijat kuten Epic tai Cerner tällaiseen ehtoon. Voi olla, että eivät. Kotimaiset toimijat luultavasti suostuisivat: jos kukaan ei heiltä enää ostaisi tietojärjestelmää kuin sikaa säkissä, joutuisivat he myymään sitä sisuskaluineen kaikkineen. Palkinto on liian suuri, jotta Tieto tai Logica heittäisi pyyhkeen kehään.

Optio 2) open source

Toinen vaihtoehto on avoin lähdekoodi. HUS voisi vaatia ehtona, että ostettavan järjestelmän koko lähdekoodi julkaistaan avoimella lisenssillä. Tämä poikkeaa ensimmäisestä vaihtoehdosta siinä, että myös muut kuin HUS pääsisivät käyttämään koodia. Eniten hyötyisivät muut sairaanhoitopiirit, jotka saisivat HUSin järjestelmän käyttöönsä ilmaiseksi, mutta myös HUS hyötyisi, koska avoimuus tehostaa kehitystyötä monin tavoin. Sitä paitsi HUS saisi sitten muiden muutostyöt myös itselleen käyttöön.

Kehityksen lähtökohtana voisi toimia jokin nykyinen potilastietojärjestelmä, valmis avoimen lähdekoodin järjestelmä, kuten USA:n veteraaniterveydenhuollon VistA, tai se voitaisiin kasata tyhjältä pöydältä. Yksikään ratkaisu ei ole ongelmaton. Nykyiset järjestelmät ovat juuri niitä, joita kovasti kritisoidaan, eikä toimittajien halukkuudesta avata koodinsa ole mitään varmuutta. VistA taas sisältää samaa arkaaista MUMPS-kieltä kuin EPICkin eikä amerikkalaisena välttämättä sovellu suoraan Suomen terveydenhuolto-organisaatioon. Ja tyhjältä pöydältä kehittäminen on aina työlästä ja osin riskaapelia.

Optio 3) pilkonta, rajapinnat ja vahva yhteistyö

Tanskassa terveydenhuoltoalan tietojärjestelmät ostetaan pienehköissä osissa: yksi järjestelmä kerrallaan. Eri sairaanhoitopiirit ostavat kuka mistäkin. Alan toimijat – niin yritykset kuin viranomaisetkin – määrittelevät yhteistyössä rajapinnat ja tiedonsiirtostandardit, joita noudattaen järjestelmät toimivat sulavasti yhteen. Kokonaisuutena Tanskassa on ”ekosysteemi” terveydenhuoltoalan tietotekniikkaa tekeviä yrityksiä.

Paperilla järjestelmä kuulostaa melko samantapaiselta kuin Suomessakin. Erona on, että Tanskassa se toimii, kun suomalainen terveydenhuollon IT on katastrofi. Juutit siis ilmeisesti tekevät jotain oikein.

Jari Forsström et al kuvaavat raportissa ”Terveydenhuollon tietojärjestelmät ja Suomi” miten Tanskan ja Ruotsin vastaavat alat toimivat, sekä esittävät näkökantoja siitä, miten potilastietojärjestelmien uudistusta tulisi Suomessa tehdä. Heidän keskeinen johtopäätöksensä on:

  1. Terveydenhuollon kokonaisjärjestelmään sisältyy suuria riskejä.
  2. Hajautetuista ratkaisuista, ohjelmistojen ekosysteemistä, on pohjoismaista hyviä kokemuksia.
  3. Terveydenhuollon tietojärjestelmäkustannuksista noin puolet koostuu henkilötyöstä, joten toimialalla on merkittävä työllistävä vaikutus. Suomalaisen IT-osaamisen taso on korkea ja sitä tulisi voida hyödyntää näin mittavassa kansallisessa hankkeessa.

Käytännössä Suomessa Terveyden- ja hyvinvoinnin laitoksen (THL) pitäisi ottaa vetovastuu ja johtava rooli sairaanhoidon tietojärjestelmäekosysteemin kehittämisestä. Samaan tapaan kuin Tanskan Medcomilla on. THL tosin on taustaltaan tutkimusorganisaatio, eikä muutos ohjaavaksi viranomaiseksi varmasti olisi sille ihan helppo.

Hajautetummassa kehityksessäkin on riskinsä. Jos halua yhteentoimivuuteen ei ole, ei sitä myöskään synny. Standardit voidaan määritellä paitsi hyvin, myös huonosti. Järjestelmiä hankittaessa pitää myös oikeasti ymmärtää, mitä ollaan hankkimassa ja miten se suhtautuu muihin jo hankittuihin järjestelmiin. Tanskassa on saatu aikaan koko alaa koskeva yhteinen henki ja halu tehdä yhdessä järjestelmistä hyviä. Suomesta tämä toistaiseksi puuttuu.

Perinteinen ja moderni terveydenhuollon tietojärjestelmän arkkitehtuuri Forsströmin et. al mukaan. Suomessa käytössä olevat ja Sirius-hankkeessa ehdotetut uudet järjestelmät perustuvat vanhaan monoliittiseen arkkitehtuuriin.

Johtopäätökset

Kaikille kolmelle vaihtoehdolle on yhteistä, että ostaja joutuu tekemään selvästi nykyistä enemmän ja parempaa työtä. Tilaajan puolelle pöytää tarvitaan nykyistä enemmän ammattitaitoa sekä sairaalan hallinnoinnista että erityisesti nykyaikaisesta tietojärjestelmien kehittämisestä.

Tietojärjestelmät muodostavat nykyään organisaation kuin organisaation toiminnan ytimen. Ne ovat se luuranko, jonka varassa organisaatiot liikkuvat. Jos ei tietojärjestelmää soviteta organisaation toimintatapaan, täytyy toimintatavat sovittaa järjestelmään.

On vaarallista fantasiaa kuvitella, että tällaisen ydintoiminnon voisi ostaa valmiina ulkoa ymmärtämättä sen toimintaa itse. Ajatus ulkomaisesta potilastietojärjestelmästä, joka ”vaan toimii” on hopealuoti: fiktiivinen ratkaisu kaikkiin ongelmiin. Se on käärmeöljyä, ei lääketiedettä.

Ihmepillereitä ei ole, vaan terveys perustuu elämäntapoihin; samaan tapaan potilastietojärjestelmän toiminta perustuu organisaation toimintatapoihin. Mikään ratkaisu, jossa ei muuteta sairaanhoitopiirien tapaa ostaa ja tuottaa tietojärjestelmiä, ei tule ratkaisemaan ongelmia.

Kaikki kolme ehdotusta sisältävät myös ongelmia ja riskejä. Yksikään niistä ei ratkaise terveydenhuoltoalan nykyisiä ongelmia mitenkään itsestäänselvästi. Siksi paras mitä osaan suositella on, että jokaista näistä vaihtoehdoista – ja muitakin – tutkitaan tosissaan, ja etsitään paras mahdollinen tapa välttää toimittajaloukku.

Sillä jos jokin on varmaa, niin se, että perinteisenä könttäkauppana ei Suomessa tulla koskaan ostamaan onnistunutta potilastietojärjestelmää. Epäonnistuminen on prosessin sisäänrakennettu ominaisuus.

Tietojärjestelmistä päättää viime kädessä HUSin hallitus. En kehota häiritsemään kenenkään kesälomaa, mutta meillä, jotka ymmärrämme tietojärjestelmiä on vastuu, että he tietävät mistä ovat päättämässä.

Edistääkseni asiaa loin adressin, jonka toivon lukijoiden allekirjoittavan. Siinä vaaditaan HUSin hallitusta selvittämään mahdollisuudet välttää toimittajaloukku. Mitään yksittäistä nimenomaista ratkaisutapaa ei vaadita, ainoastaan katastrofaalisen virheen välttämistä. Addressi toimitetaan alkusyksystä HUSin hallitukselle.

Keskustelualustaksi loin myös Facebook-ryhmän Terveydenhuollon IT korjattava. Liittykää sinnekin, ketkä FB:tä harrastatte ja haluatte aihetta seurata.

Kolmantena tapana vaikuttaa ovat vaalit. Kysykää ehdokkailta, mitä he aikovat tehdä, jotta terveydenhuollon IT-järjestelmien katastrofi saadaan tulevina vuosina korjattua. Erityisesti kysykää tätä sairaanhoitopiirien hallituksissa istuvilta.