Apotti-hankkeen tavoite on tärkeä, mutta esitetyt hankintamallit ja teknologiat järjettömän kalliita ja vanhanaikaisia. Mitä jos Apotti toteutettaisiin ketterästi?
Kustannusarviosta
Koko Suomen kattavaa 1,8 miljardin kustannusarviota on verrattu Mars-luotaimeen. Vaikka itse Apotti maksaa “vain” 350–450 miljoonaa euroa, se on monen mielestä liikaa. Hankkeessa ei tehdä rakettitiedettä vaan tallennetaan, näytetään ja siirretään potilastietoja.
Järkyttävän kokoista kustannusarviota on perusteltu IT-asiantuntijayhtiö Gartnerin tutkimuksella, jonka mukaan potilastietojärjestelmän modernisointi maksaisi jopa 1,4 miljardia kutakin erillisjärjestelmää kohti ja kestäisi 10–14 vuotta. Huh!
Gartnerin tutkimus perustuu tietysti projekteille, jotka on kehitetty perinteisillä projektimenetelmillä, määrittelemällä kaikki sisältö etukäteen ilman priorisointia ja kehittämällä kokonaisuutta “kerralla valmiiksi” kuin Iisakinkirkkoa. Ei ole uutinen, että näin hankitut ja kehitetyt järjestelmät maksavat liikaa, valmistuvat myöhässä ja ovat surkeita.
On olemassa vaihtoehto. USA:n puolustusministeriö siirtyi vuonna 2010 uuteen tapaan hankkia IT-järjestelmiä. Ketterillä menetelmillä päästään edullisempaan ja parempaan lopputulokseen jopa kolme kertaa todennäköisemmin. Ilmeisesti uusista menetelmistä ei kuitenkaan olla Apotti-hankkeessa kiinnostuneita. Kysehän on vain miljardeista.
Tilannetta voisi verrata siihen, että ryhmä sytyttää nuotiota tuhannen euron seteleillä. Koska tapa on jatkunut vuosikymmeniä, Mr. Gartner -niminen asiantuntija arvioi, että nuotion sytyttäminen maksaa 1,4 miljardia euroa. Harmi vaan, ettei herra Gartner ole huomannut, että viereisellä nuotiopaikalla käytetään sytytysnestettä ja sanomalehteä. Niillä nuotio syttyy jopa kolme kertaa todennäköisemmin, edullisemmin ja mukavammin.
Supistaisin Apotin budjetin 50-100 miljoonaan euroon (koko maan laajuisena), minimoisin sen vaatimukset ja priorisoisin vaatimukset kunnolla. Apotilla ei lennetä Kuuhun vaan pyöritetään viiden miljoonan ihmisen potilastietoja. Vertailun vuoksi Facebookissa on 200 kertaa enemmän käyttäjiä. Sadalla miljoonalla eurolla pitäisi saada niin käsittämättömän hieno järjestelmä, ettei mitään rajaa. Tällainen asenne ja osaaminen hankkeessa pitäisi olla, eikä Gartnerin muiden tuhlailulla perustelema rahan polttaminen.
Hankintamallista
Apotin hankinnassa tuntuu kilpailevan kaksi ajatusta: Perinteinen vesiputoustoteutus ja valmiin lisenssin räätälöinti. Koska perinteisestä hankintamallista on (onneksi) negatiivisia kokemuksia, on ainoaksi mahdollisuudeksi jäänyt koko systeemin ostaminen valmiina lisenssinä, joka räätälöidään. Räätälöinti onkin ihan fiksua, jos rahalle saa vastinetta. Harmi vaan, ettei rahalla tunnu olevan mitään arvoa (viitaten edelliseen esimerkkiin rahan polttamisesta), kun kymmenien miljoonien eurojen lisenssi, joka on teknologialtaan suljettu ja valmiiksi vanhentunut, on hankintalistan kärkipäässä. Samalla menetetään arvokas tilaisuus tukea kotimaista ohjelmistoteollisuutta.
Koko sisällön etukäteen määrittelemisen sijaan (joka on tämän kokoluokan projektille joko mahdotonta tai järjetöntä) hankkisin Apotin palvelukseen osaamiseltaan sopivia ammattilaisia, jotka toteuttaisivat järjestelmän. Siis ei sisältöä, vaan ihmisiä. Uutta mallia on käytetty suomalaisessa julkishallinnossa onnistuneesti useamman vuoden ajan. Tällöin järjestelmää voitaisiin kehittää jatkuvasti, alkaen käyttäjille kriittisistä toiminnoista ja laajentaa toimintoja käyttäjien ehdoilla. Näin turhia toimintoja ei pääsisi syntymään ja käytettävyys ja laatu säilyvät korkeammalla.
Korostaisin myös kulttuurin luomista. Tämän kokoluokan hanke vaikuttaa tuhansien ihmisten työhön, jolloin sen lisensointi voisi olla ongelmallista: Ihmisten tulisi nopeasti mukautua järjestelmään ja suuri osa toiminnoista jäisi helposti käyttämättä ja heikentäisi käytettävyyttä. Kehittämällä Apotti iteratiivisella mallilla ja “omalla” henkilöstöllä saataisiin uuden työkulttuurin kehitys lähtökohtaisesti osaksi hanketta. Terveydenhallinnon uutta toimintakulttuuria ei voi ostaa, se tulee joka tapauksessa kehittää itse. Kehittämällä järjestelmää ja toimintakulttuuria käsi kädessä saataisiin paras lopputulos.
Arkkitehtuurista
Minulla ei ole riittävästi tietoa arkkitehtuurin suunnitteluun. Innostuin kuitenkin pohtimaan, kuinka toimisin juuri nyt, jos Apotti-startupillani olisi 100 miljoonan euron pikku budjetti.
Apotin vetäjänä lähtisin rekrytoimaan seuraavia tiimejä, jotka toimisivat yhteisissä tiloissa ja kommunikoisivat päivittäin keskenään. Varsinaisissa ohjelmistokehitystiimeissä olisi lisäksi ainakin yksi erikoisosaaja (ja siten yhteyshenkilö) kullekin alla kuvatulle erikoistiimille:
Tietokantatiimi sisältäisi tietokantasuunnittelun huippuammattilaisia. Tiimin tehtävänä on kerätä rakenteelliset tiedot kaikista tällä hetkellä olemassaolevista kotimaisen terveydenhuollon tietojärjestelmistä. Tietojen avulla mallinnetaan yksi keskitetty tietovarasto. Ensimmäisen tietomallin prototyypin aikataulu on 4 viikkoa. Tietokantatiimi tuottaa muiden tiimien ja hankejohdon kanssa jatkuvasti käytävän keskustelun perusteella päivitetyn tietomallin aluksi 2-4 viikon välein.
Käyttöpalvelutiimi sisältäisi Cloud Computing -palveluiden ja ylläpidon huippuammattilaisia. Tiimin tehtävänä on suunnitella, toteuttaa ja ylläpitää Apotin tuotekehitys-, staging- ja tuotantoympäristöjä pilvipalveluina (joko omana pilviklusterina tai kansallisen pilvipalvelun päälle). Lisäksi tiimi vastaa tuotannon virheilmoitusten valvonnasta ja vastaanotosta.
Lakitiimi sisältäisi juridiikan ammattilaisia, joiden tehtävänä on varmistaa, että Apotti voidaan toteuttaa kaikille turvallisesti ja iteratiivisesti. Tiimin asiantuntijat eivät listaa ohjelmistokehittäjille ongelmia, vaan potentiaalisia ratkaisuja. Lakitiimissä ymmärretään, että vaikka Suomen laki edellyttäisi tarjoamaan tietyn palvelun, kyseistä palvelua ei tarvitse välittömästi automatisoida täydellisesti, vaan ensin voidaan toteuttaa vain muutama tärkein osa (jotka kattavat usein jopa 80% käyttötapauksista) ja käsitellä poikkeukset käsityönä. Sitten laajennetaan.
Integrointitiimi sisältäisi testausautomatiikan huippuammattilaisia, jotka vastaavat Apotin automaattisen koonti- ja testiympäristön kehittämisestä ja ylläpidosta yhteistyössä muiden tiimien kanssa. Mikäli ohjelmistovirheitä ilmenee toteutuksen tai stagingin aikana, tiimi raportoi asiasta kyseiselle kehitystiimille.
Kehitystiimit (useita) sisältäisivät ohjelmistokehityksen, laadunvarmistuksen, käyttöliittymäsuunnittelun, juridiikan, käyttöpalveluiden ja tietokantojen huippuammattilaisia. Jokaisessa tiimissä on vähintään yksi jokaisen alan osaaja, joka toimii yhdyshenkilönä mahdolliseen erilliseen tiimiin. Esim. kunkin kehitystiimin tietokantavastaava tapaa päivittäin muiden tiimien tietokantavastaavat varsinaisen tietokantatiimin luona (tai esim. skypessä). Lyhyessä 15 minuutin tapaamisessa tarkistetaan tilanne ja sovitaan tärkeimmistä riippuvuuksista.
Hanketoimisto tukisi hankkeen onnistumista tarjoamalla tiimeille mm. laadukkaat työnteon puitteet ja tuoteohjauksen.
Oma Apottini olisi täysin Internet-pohjainen, kuten Facebook, Youtube tai Twitter. Nykyaikana on älytöntä suunnitella Desktop-pohjaista järjestelmää, jossa käyttäjille tulisi asentaa paikallinen ohjelmisto (poislukien mobiilisovellukset, jotka jokainen osaa asentaa itse). Rahaa säästyy rutkasti, kun ylläpito ei juokse tuhansien käyttäjien koneilla.
Nuutti Hyttisen kuva EPIC Systems Corporationin tarjoamasta potilastietojärjestelmästä, jonka ydin on kehitetty 60-luvun MUMPS-kielellä. Käyttöliittymänä on Visual Basic 6, jonka virallinen tuki lopetettiin 2008. Teknisen iän lisäksi käyttöliittymä vaikuttaa sekavalta, sisältänee turhia ominaisuuksia ja vaatinee räätälöintiä, asennuksia ja koulutusta.
Rajaisin Apotin vaatimukset ensiversioissa kunkin osajärjestelmän muutamaan tärkeimpää toimintoon, joiden avulla osajärjestelmän käyttäjät voisivat siirtyä Apottiin. Esim. Mitkä olisivat “Diagnoosi” -osajärjestelmän tärkeimmät kolme toimintoa lääkärille, joka on tekemässä potilasdiagnoosia? Lisäksi minimoisin integraatiot muihin järjestelmiin, koska ne ovat usein hitaita ja kalliita ja priorisoisin integroinnit alkaen arvokkaimmista, kuten KELA:n integrointi. Avoimet ja turvalliset HTTP-sovellusrajapinnat olisivat itsestäänselvyys.
Käyttäjille arvokkaiden vaatimusten (kehitysjonon) keräämiseksi perustaisin intressiryhmiä, jotka edustaisivat monipuolisesti Apotin käyttäjiä (esim. lääkäreitä, hoitajia, potilaita ja terveydenhoidon toimistotyöntekijöitä). Intressiryhmät antaisivat haastatteluja ja osallistuisivat Apotin suunnitteluun, testaamiseen ja parantamiseen koko projektin ajan.
Apotin teknologiaksi valitsisin nykyaikaisen, avoimen, maksuttoman ja hyvämaineisen kehyksen. Mieleen tulee jokin Internet-kieli, kuten PHP (sopivalla esim. MVC-kehyksellä), Ruby on Rails tai Java. Valittua teknologiaa laajennettaisiin tarkasti valituilla laadukkailla kirjastoilla. Toteutus tehtäisiin iteratiivisesti 2 viikon jaksoissa, joiden lopuksi toiminnot esiteltäisiin ja siirrettäisiin nk. staging-ympäristöön, jossa intressiryhmät saisivat testata sitä seuraavat 2 viikkoa. Tämän jälkeen toiminnallisuus julkaistaisiin tuotantoon.
Apotin raportit toteutettaisiin (ensimmäisten karujen versioiden jälkeen) erittäin käyttäjälähtöisesti, jolloin esimerkiksi verikokeen tulokset olisi helposti tulkittavissa:
Lähde: Wired Magazine, Blood Test Gets a Makeover.
Uskon, että iteratiivisella kehitysmallilla Apotti voitaisiin ottaa asteittain käyttöön 2 vuoden sisällä kehittämisen aloittamisesta ja se olisi “valmis” 5 vuoden sisällä aloituksesta. Samalla terveydenhuollon kulttuuri olisi kehittynyt uudelle tasolle yhdessä järjestelmän kanssa, käyttäjät olisivat todennäköisesti erittäin tyytyväisiä ja Apotin ylläpito ja jatkokehitys olisi verrattain edullista. Ylläpitoon käytettäisiin DevOps-tyyppistä mallia, jossa ylläpidosta, jatkokehityksestä ja laadusta vastaisi yhteistyötä tekevä pieni organisaatio.
Toivotan Apotille ja sen parissa työskenteleville onnea ja energiaa! Lähden mielelläni lounaalle, jos haluatte keskustella ketterän kehityksen mahdollisuuksista.
Comentarios