21. veebruar 2018

Tähelepanu! Artikkel on enam kui 5 aastat vana ning kuulub väljaande digitaalsesse arhiivi. Väljaanne ei uuenda ega kaasajasta arhiveeritud sisu, mistõttu võib olla vajalik kaasaegsete allikatega tutvumine.

Pole just suur uudis, et tarkvara tellijad ja kasutajad on rahulolematud IT-arendajate ning nende tehtud tööga. Tellijale näitab arendajale näpuga “nad ei saa üldse aru, mida me tahame”, arendaja näitab näpuga tellijale “nad ise ka ei saa aru, mida nad tahavad”, lahkarvamused on kerged tekkima. Kahjuks ei piirdu probleem ainult tuliste emotsioonide ja lahkarvamustega. Tööd tehakse ringi, tekivad lisatööd, lisaeelarved, tähtajad lähevad lõhki ja kogu selle “lõbu” peab ikkagi tellija kinni maksma. Halvemal juhul jäävad süsteemid üldse lõpetamata (SKAIS’i mäletate) või saab tellija endale süsteemi, mida kasutajad ei taha kasutada ja mille kohta iga päev vihaseid või iroonilisi märkusi tehakse.

Tervishoid on valdkond, kus IT süsteemide tellimine on eriti keeruline ja kriitiline. Tellija ootustele mittevastavate süsteemide probleem oli üks teemadest, millega Connected Health klaster pidas vajalikuks tegeleda. Klastri liikmetel on kogemust nii süsteemide arendamise kui tellimisega ja üsna hea ettekujutus sellest, miks probleemid tekivad ning mida nende vältimiseks teha. Esialgsed oletused probleemidest tellija organisatsioonis pandi kirja ja seejärel kutsus TTÜ Tervisetehnoloogiate instituut ja Connected Health klaster kokku tervise valdkonna tarkvara tellijate ja arendajate ümarlaua. Sellel osales mitukümmend asjatundjat, kelle seas oli Terviseamet, Sotsiaalministeerium, Lõuna-Eesti Haigla, Ida-Viru Keskhaigla, Regionaalhaigla, Viljandi Haigla, Medicum, Tartu Ülikooli Kliinikum, Ida-Tallinna Keskhaigla, Medisoft, Pärnu Haigla, Tallinna Lastehaigla, SYNLAB Eesti.

Nende ühine arvamus oli, et süsteemidega rahulolematus tuleneb probleemidest kolmes valdkonnas:

1) protsessid:

süsteem ei tee seda mida peaks, teeb vales järjekorras, automatiseerituse tase on madal,funktsionaalsus on puudulik või vale,kasutajaliidesed kehvad, ülekoormatud liigsega, ebaloogilised, halvasti jälgitavad, raskesti kasutatavad, põhjustavad liigset navigeerimist ja ajakulu,

2) andmemudel:

andmed on puudulikud, liiased, raskesti analüüsitavad, andmekvaliteeti on keeruline juhtida, süsteemides on „mitu tõde“,andmeseosed ja andmeüksuste (data entities) hierarhiad on ebaloogilised,

3) juhtimine:

kasutajad ei taha süsteemi kasutada, sest süsteemi kasu on ebaselge või ebapiisavalt selgitatud, primaarsed ja sekundaarsed kasusaajad teadvustamata,muudatuste juhtimine kehvasti teostatud, kasutajate motivatsiooniga ei tegeleta,koolitus ja tugi on ebapiisav,süsteemi arendusprotsessis paratamatult asetleidvad muudatused ja täpsustamised on teadvustamata ja ebapiisavalt juhitud.

Kõige rohkem probleeme on seotud protsesside valdkonnaga ja peamine põhjus - tellijal on protsessid kaardistamata ja korrastamata. Üldlevinud praktika kohaselt koostatakse lähteülesannet sõltuvalt organisatsiooni suurusest ja süsteemi ulatusest, sisaldades kümmekond kuni sada kasutuslugu, mis peaks kirjeldama, kuidas süsteem peab protsesse toetama. Seda tööd juhib reeglina arendaja, intervjueerides erinevaid tellija võtmeisikuid. Paraku on kasutuslugudel põhinevatel lähteülesannetel terve tüüpilisi puudujääke:

Kasutuslugusid on liiga vähe - kui tööprotsess on kirjeldamata, pole kellelgi ettekujutust, mida süsteem üldse tegema peab. Lähteülesandes kirjeldatakse küll “kõige olulisem funktsionaalsus” aga mitte töö kui tervik. Ei ole harv juhus, kui pooled protsessi tegevused on kasutuslugudega katmata. Mida see endaga kaasa toob - lisatöö ja lisakulu prototüübi loomise ajal, mis kõik tuleb tellijal kinni maksta. Ja paraku ei lahenda lisatöö probleeme, sest tööprotsess on endiselt kirjeldamata, vastuolud ja ebaefektiivsus on endiselt töökorraldusse “programeeritud”.Kasutuslood on sisemiselt vastuolulised, sest ei põhine tööprotsessil (sest see on kirjeldamata). Tulemuseks on vaid osaline arusaam tööprotsessist kui tervikust, puuduvad olulised tegevusteks vajalikud sisendid või väljundid, nõuded on vastuolulised ja omavahel kokkusobimatud. Need probleemid ilmnevad kahjuks juba töötava süsteemi loomise või veel hullem - süsteemi kasutamise ajal ja on peamiseks kasutajate rahulolematuse allikaks.Kuna protsess on kirjeldamata, on täielikult puudu tellija poolne arusaam sellest, kuidas süsteemis peaks olema andmed organiseeritud, mis andmed millega kokku kuuluvad, milline on tunnuste hierarhia. Reeglina disainib andmemudeli arendaja andmebaasi arhitekt, tehes seda juba süsteemi arendamise käigus, vastavalt sellele, kuidas neil on mugavam andmeid organiseerida. Klassikaline näide - diagnoos “südameinfarkt”. Kui süsteemist hakatakse tegema päringuid, mis haigusi patsientidel esineb, selgub, et näiteks neerus, ajus või isegi reielihases (dr House) esinevate infarktide statistikaks tuleb teha kõvasti lisatööd. Siis avastatakse, et ajuinsulte ja -infarkte ei ole võimalik eristada, jälle lisatöö. Paraku on andmebaas juba ammu valmis,  selle muutmine on väga kallis ja nii veetakse lisatöö ja - kulu analüütikute töölauale.

Ümarlaual osalejad tõdesid, et tellijatel on põhjendamatult suur lootus, nagu suudaks arendajad süsteemi lähteülesande koostamise käigus aru saada, kuidas tööprotsessid täpselt toimivad ja toimima peaks. Selleks, et saada süsteeme, mis teeks seda mida tellija soovib, tuleb tööprotsessid tellijal endal kaardistada, kirjeldada ja korrastada.  Teine suur probleem - enamus tellijaid pole endale isegi teadvustanud, et nemad peavad juhtima ja vastutama andmemudeli ja sellest tuletatud andmebaasiarhitektuuri eest.

Süsteemide kasu ja muutuste juhtimise teemad kolmanda probleemide allikana on küll olulised, kuid siin kasutatavad lahendused ja võtted on samad nagu mistahes muutuse ellukutsumisel. Tellijatel jääb pigem vajaka arusaamast, kui oluline on muudatuste järjepidev juhtimine.

TTÜ Tervisetehnoloogiate instituudi juhtimisel koostasime neljapäevase spetsiaalse koolitusprogrammi tervishoiuvaldkonna juhtidele ja asjatundjatele, kes oma töös peavad IT süsteemide lähteülesandeid koostama ja süsteeme tellima. Targa IT Tellija koolitusprogramm algab juba 16. märtsil ja selle kohta rohkem infot leiab TTÜ Avatud Ülikooli kodulehel.   

Autor: Indrek Saul Connected Health klaster