E-veselības klupieni un kritieni (10)

Kopumā esmu visnotaļ veselīgs cilvēks un ārstu apmeklējumi man ļoti ilgu laiku nebija dienaskārtībā. Bet, pieaugot ģimenei, parādās arī nepieciešamība ar jaunajām atvasēm apmeklēt veselības iestādes, pieteikties uz vizītēm, sēdēt rindās, veikt analīzes. Tā kā mans ikdienas darbs ir bijis saistīts ar IT risinājumu izstrādi, tad, protams, gribot negribot sēdi tajā rindā un domā, kā šo visu varētu uzlabot.

Šis raksts ir vairāku šādu pārdomu un pētījumu rezultāts.

Sabiedrībā ar diezgan lielu regularitāti parādās neapmierinātība ar dažādiem valsts pasūtītajiem IT risinājumiem un to kvalitāti. Elektroniskās deklarēšanas sistēma (EDS), Latvija.lv un čempione, protams, ir e-veselība. Par to, cik daudz naudas iztērēts, par to, cik daudz laika tās izveidei bija nepieciešams, un, protams, par to, ka tas viss beigās ne pārāk labi strādā. It kā jau viss ir, bet reizē nav. Tāda paradoksāla situācija, un, šķiet, neviens nespēj pateikt, ko vajadzēja darīt citādi.

Lielākā bariņā jautrāk

E-veselības izstrāde ir ļoti labi dokumentēta. Ir pieejamas visas specifikācijas, auditi, ieteikumi. Par e-veselības izstrādes sākumposmu ir pieejams detalizēts dokuments Pasaules veselības organizācijas mājas lapā — “Informatīvais ziņojums par pamatnostādņu „e-Veselība Latvijā” ieviešanu 2008.-2013. gadā un pamatnostādņu „e-Veselība Latvijā” īstenošanas plāna 2008.-2010. gadam ieviešanu”. Un vēl viens ziņojums Ministru kabineta lapā — “Informatīvais ziņojums par pamatnostādņu “E-veselība Latvijā” ieviešanu 2014.-2017. gadā, gala atskaite”. Līdz ar to ir iespējams arī izsekot procesam līdzi.

Neliels ieskats tipiskā programmatūras izstrādes procesā. Kā jau jebkurā programmatūras procesā, viss sākas ar prasību specifikāciju — tāds sava veida iepirkumu saraksts ar vēlmēm, ko mūsu sistēmai vajadzētu varēt paveikt, kādas problēmas atrisināt. Šeit arī pirmais pasūtījums, tiek piesaistīti speciālisti, kas veic tirgus izpēti — notiek intervijas ar iesaistītajām pusēm, apzina to problēmas un vajadzības. Rezultāts ir prasību specifikācija, kur šī informācija ir apkopota.

Kad prasību specifikācija ir gatava, nākamais posms ir tehniskās specifikācijas izstrāde. Ja prasību specifikācija ir par to, kas būtu nepieciešams, tad tehniskā specifikācija jau par to, kā tam ir jāstrādā, ar lielu detalizācijas pakāpi. Visas e-veselības prasību un tehniskās specifikācijas ir publiski pieejamas. Kopā ir 47 dokumenti, kuros ir aprakstīts, kā šai sistēmai būtu jāstrādā un kādi uzlabojumi jāveic.

Papētot jau minēto “Informatīvo ziņojumu” no 2014. gada, ir grūti pateikt, kurš ir atbildīgs par pamata dokumentu. Meklējot pēc “SIA”, ir redzams, ka dažādas specifikācijas, vadlīnijas, papildinājumus, auditus ir izstrādājuši daudzi un dažādi uzņēmumi:

• - SIA AA-projekts
• - SIA „Datorzinību centrs”
• - SIA „ABC software”
• - SIA „Metrika”
• - SIA „Corporate Solutions”
• - SIA „Ernst & Young Baltic”
• - SIA „Tieto Enator Alise”
• - SIA „PricewaterhouseCoopers”

Tik tālu esam tikuši. Mēs zinām, ko gribam, un mums ir plāns, kā to visu uzbūvēt. Tagad mums ir vajadzīgs nākamais, trešais, iepirkums, kad aicināti pieteiksies tie, kuri spēj šo visu uzbūvēt. Kā varam redzēt pēc tehniskajām specifikācijām, projekts nav mazs. Summas projektam ir atvēlētas lielas (Eiropas Reģionālās attīstības fonda līdzekļi ar nelielu budžeta piešprici), un, protams, mums ir nepieciešami arī atbilstoša kalibra uzņēmumi. Jau iepriekšminētajā dokumentā ir redzams, ka programmēšanas darbi ir uzticēti šiem uzņēmumiem:

- „SIA In-volv Latvia”

- SIA “TCon”

- SIA „Lattelecom Technology”

- SIA „Agile&Co”

Otrās kārtas izstrādes procesā un kļūdu labošanai ir bijuši piesaistīti vēl šādi uzņēmumi:

• - SIA “Softikom”
• - SIA “Meditec”
• - SIA “Lattelecom”
• - SIA “Proof IT

Par dizaina un lietojamības prasībām e-veselības iepirkumos informācija ir ļoti skopa. Precīzāk, es neko nevarēju atrast, meklējot vārdus “dizains”, “lietojamība”. Vārds “saskarne” tiek lietots kontekstā ar datu pieejamību no citām sistēmām. Dizaina un lietojamības prasību neesamība nav nekas neparasts valsts sektorā, jo parasti dizains un lietojamība nav prioritāte. Tāpat pietiek jau par ko uztraukties, un bez dizaina beigās jau neviens nav palicis. Tagad ar valsts iestāžu mājas lapu vienoto dizainu un funkcionalitāti šķiet, ka šis ir mainījies. Privātajā sektorā šis ir vēl viens paliels process, kur tiek zīmētas idejiskās skices, veidoti dizaina paraugi, analizēta lietojamība, veidoti lietojamības un dizaina standarti un vadlīnijas.

Beidzot varam ķerties vērsim pie ragiem. Sākas pats programmēšanas process, kad cilvēki ik dienu kaut ko pieprogrammē, palaiž, veic gan slodzes, gan lietojamības testus atbilstoši plānam un prasībām, ja, protams, šādas lietas ir atrunātas tehniskajā specifikācijā. Tiek labotas kļūdas un atkal pārbaudīts — līdz koridora galā atskan: “Priekšniek, gatavs!” Pasūtītājs meistaram samaksā naudu, sabiedrība sāk ar apbrīnu lietot jauno rīku, sniedz pozitīvas atsauksmes, visi priecīgi, un dzīvo ilgi un laimīgi. Priekškars!

Svarīgs nav galamērķis, svarīgs ir ceļš

Bet kāpēc tad viss nenotiek tik skaisti? Ja jau viss ir bijis atrunāts un aprakstīts? Šeit ir vairāki potenciālie iemesli — darba apjoms, iesaistīto pušu skaits, pieejamie līdzekļi un metodoloģija.

Darba apjoms. E-veselība ir sadalīta trijos lielos posmos, kuros ir jāievieš viss nepieciešamais — e-receptes, e-pieraksts, e-kartiņas, e-zāļu reģistrs. E-viss. Problēma nav tā, ka kaut kas nebūtu paredzēts. Problēma ir tā, ka paredzēts ir viss. Un nav tā, ka kaut ko no šī nevajadzētu. Mēs taču gribam būt e-valsts, un, protams, tie nolāpītie igauņi… Taču beigās visa ir tik daudz, ka pazūd mērķis. Ko tad mēs gribam sasniegt? Par mērķi ir kļuvis uzbūvēt sistēmu atbilstoši prasību specifikācijai, nevis atrisināt konkrētu sabiedrības problēmu.

To arī secinājusi Valsts kontrole:

“Tā ir orientācija uz procesu — mēs darām un darām, bet nav ieinteresētības sasniegt rezultātu, nav arī atbildības par to, ka šis rezultāts netiek sasniegts. Un vēl viena problēma, ka arī rezultāts sākotnēji bija tik izplūdis, ka nebija skaidrs, ko tad vajag sasniegt. Un šādi tas rezultējies,” paskaidroja valsts kontroliere Elita Krūmiņa.”

Lai šo sistēmu uzbūvētu, ir nepieciešams piesaistīt dažādas puses — ir pasūtītājs, ir prasību specifikācija, tehniskā specifikācija, programmētāji. Katrs dara savu darbiņu. Paralēli tiek izstrādāti daudzi risinājumi, kuriem jāstrādā kopā un ir nepieciešama koordinēta komunikācija. Jo vairāk iesaistīto pušu, jo process kļūst smagnējāks un lēnāks. Ir vienkārši kaut ko palaist garām. Rezultātā e-veselības pirmajās lietošanas dienās tā vienkārši nestrādāja, jo sistēma nespēja vienlaikus apkalpot tik lielu lietotāju skaitu (kurš nemaz nebija tik liels mūsdienu standartiem). Kurš ir vainīgs? Neviens. Tehniskajā specifikācijā nebija rakstīts, ka sistēmai jāspēj nodrošināt konkrētu vienlaicīgu pieslēgumu skaitu. Prasību specifikācijā tas nebija minēts. Meklējot tehniskajās specifikācijās vārdus “noslodze”, “vienlaicīgi” nespēju atrast šādu informāciju. Varbūt tas ir kādā no 47 dokumentiem.

Daudzas iesaistītās puses izšķīdina atbildību. Kā saka, mēs tikai darījām savu darbiņu, tie otri vainīgi. Un tā pa riņķi.

No programmatūras izstrādātāju perspektīvas, ja kāda prasība vai funkcionalitāte nav tehniskajā specifikācijā, tā vispār neeksistē. Ja kaut kas ir vajadzīgs, tad jāveic labojumi, jāraksta jauns darba uzdevums, un tam ir jauna tāme. Un, spriežot pēc publiskās informācijas, ap 2016. gadu tieši tas arī ir noticis. Izrādās, ka daudzas lietas nav ņemtas vērā, projekts kavējas un var būt nepieciešami papildu līdzekļi.

Kāpēc vispār mums to visu vajadzēja darīt tādā mērogā? Jo ir pieejami līdzekļi. Eiropas reģionālās attīstības fonda līdzekļi trim kārtām. Kopumā investēti 14,3 miljoni, no kuriem Eiropas finansējums ir 11,3 miljoni. Ieraugot nullītes pie apvāršņa, nav vairs jautājums vai mums to vajag. Jautājums ir, kā mēs šo varam paņemt. Un paņemt var, uzņemoties visu ieviest uzreiz.

Problēmas problēma

Metodoloģija. Lai tiktu galā ar lielo darba apjomu, protams, pats process tiek sadalīts posmos. Kad viens ir noslēgts, tad ķeramies pie nākamā. Programmēšanā šo sauc par Ūdenskrituma modeli. Ieguvums ir tas, ka ir kontrole pār procesu un skaidrs, kurā risinājumu izstrādes stadijā esam, kurš un ko tagad dara, kad konkrētais posms ir noslēdzies. Negatīvais aspekts ir tas, ka par to, ka izstrādātajā sistēmā ir problēmas, ir iespējams pārliecināties tikai projekta noslēguma posmā, kad to sāk izmantot gala lietotājs.

Ļoti spilgti šo problēmu apraksta pats metodoloģijas autors:

… Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. […] In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs .

Viņa secinājumu rezumējums ir šāds — testēšanas fāze, kas ir tuvu izstrādes procesa beigām, ir pirmā reize, kad tiek testēta svarīgāko komponenšu reāla kopdarbība. Ja šie testi nespēj tikt galā ar dažādiem ārējiem faktoriem, neizbēgami būs nepieciešama sistēmas dizaina pārstrāde. Tas nozīmē, ka process ir atgriezies sākuma fāzē un ir sagaidāms līdz pat 100% pieaugums patērētajā laikā un/vai izmaksās.

E-veselību sāka izstrādāt 2007. gadā. Pēc 7. gadiem Valsts kontrole diezgan pamatoti secināja, ka kaut kā nav sanācis (Valsts kontroles ziņojumu “Vai projekts „E-veselība Latvijā” ir solis pareizajā virzienā?” vairs nevar atrast internetā) — iztērējām 14,5 miljonus un nekā nav. Pirmais galaprodukts ir e-receptes, kuras visiem bija jāsāk obligāti lietot 2018. gada sākumā. 11 gadus pēc darbu sākšanas lietotājs beidzot pieskaras galaproduktam. Diezgan, tā sakot, episks ceļojums. Te mazie IT kantori lauž krēslus un bļauj: “Es tādu **** varētu uztaisīt divos mēnešos un burtiski 100 reizes lētāk!” Nebūs melots, bet šeit ir “bet”. Nav jau arī tā, ka izstrādātāji būtu pilnīgi idioti, kas neko nesaprot no programmatūras izstrādes organizēšanas un nezina, kas ir Agile izstrādes principi. Bet viss iepirkums un atskaišu sistēma ir veidota tā, lai tā būtu pārskatāma un būtu iespēja sekot līdzi. Un “ūdenskritums” tieši to arī nodrošina.

Spožā nākotne

Kā tad veidot sistēmas, lai galarezultāts nebūtu čiks? Vienkāršā atbilde ir veidot mazākus produktus. Mazāki produkti nozīmē skaidrāku redzējumu, par to, kas ir galarezultāts. Mazāku produktu izstrādē ir nepieciešams mazāk iesaistīto un atbildība netiek izšķīdināta. Mazākus projektus var ātrāk nodot gala lietotājam. Mazāku produktu izstrādei var pieteikties plašāks pretendentu skaits, ir lielāka konkurence un tie ir ekonomiski izdevīgāki. Neveiksmes gadījumā zaudējumi ir mazāki.

Piemēram, E-veselības gadījumā pirmais produkts varēja būt sistēma, kur pierakstīties pie ģimenes ārsta. Prasību specifikācija — lietotājs ielogojas ar saviem Latvija.lv datiem un var pierakstīties vizītē pie sava ģimenes ārsta. Ir apskatāms kalendārs, aizņemtie pieņemšanas laika logi. Viss! Pirmajai versijai nekas vairāk. Vai šī sistēma ir sarežģīta? Nē! Vai šī sistēma iepazīstina ar E-veselības konceptu gan ārstus, gan gala lietotāju? Jā! Vai šādu sistēmu ir sarežģīti izstrādāt? Nē! Un šis ir būtiski. Ja rezultāts nav labs, tad ir iespējams nomainīt piegādātāju un to pārbūvēt daudz ātrāk, nevis tērēt 14 miljonus un pie neveiksmīga/apšaubāma rezultāta nonākt 10 gadus vēlāk. Vai tas izmaksātu dārgi? Visdrīzāk ne.

Kad ir novērstas kļūdas ar kalendāru un cilvēki ir apraduši, tad varam ieviest e-receptes. Jau tajā pašā saskarnē, pie kuras lietotāji ir pieraduši. Un atkal var sākt ar kaut ko maziņu.

Šis, protams, ir vienkāršots piemērs. Ja mērķis ir izstrādāt šīs daudzās e-viss sistēmas, tad ir jābūt arī lielās bildes redzējumam un atbildībai. Un arī uz šīs bildes trūkumu norāda Valsts kontrole:

“VK secinājusi, ka projekta neveiksmju pamatā ir organizatoriskas dabas jautājumi, neprasmīga projekta plānošana un pārvaldība, kā arī atbildīgo amatpersonu kontroles un intereses trūkums. Sākot izstrādi, Veselības ministrija nenovērtēja IT izmantošanas un pieejamības līmeni valstī. VM nav pienācīgi veikusi projekta uzraudzību, jo uzraudzības sanāksmes ir notikušas retumis un bijušas formālas.”

Un šī laikam arī ir lielākā problēma ar e-veselības izstrādi. Nebija neviena, kuram būtu, tas, ko angliski sauc par “skin in the game”. Valsts sektoram bija jāapgūst Eiropas nauda un jāizstrādā e-veselība, konsultantiem jāizdara viņiem uzticētais darbs un programmētājiem jāuzprogrammē tas, kas ir prasību specifikācijā. Bet neviena, kam būtu atbildība par rezultātu.

Noslēgums

Šādi mega risinājumi tiek būvēti kā mājas, bet programmatūra nav māja. Tas ir instruments, kuru lieto cilvēki. Tas ir kā dzīvs organisms. Tas nekad nav “gatavs”, jo vienmēr būs jaunas idejas, jauni lietojumi, uzlabojumi, kas jāveic. Darbs pie E-veselības sākās gadā, kad parādījās pirmais iPhone un mums gandrīz visiem kabatā bija kaut kas ar podziņām vadāms. E-receptes tika līdz pirmajiem lietotājiem, kad mums katram kabatā jau bija maziņš dators, kas spēj skaitīt mūsu soļus, parādīt, kur braukt, ierakstīt, nofilmēt, nostraumēt, nosūtīt, parādīt video un, starp citu, ir iespējams arī piezvanīt. Kur ir E-veselības aplikācija? Nuuuu, tehniskajā specifikācijā tas nebija iekļauts.

Vai esošais risinājums ir bezjēdzīgs un norakstāms? Pirmais programmatūras izstrādes nāves grēks ir sākt izstrādāt kaut ko lielu, būvēt visu uzreiz un darīt to ilgi. Otrais programmatūras izstrādes nāves grēks ir jebkādu esošo risinājumu vienkārši likvidēt un sākt visu izstrādāt no nulles. Rezultātā atkal tiek iztērēti līdzekļi, tiek novērstas esošās kļūdas. Bet ir atkal jaunas kļūdas. Un tās ir vienmēr un dažreiz vēl lielākas nekā iepriekš. Līdz ar to labāk ir risināt zināmās problēmas un pilnīgu sistēmas pārstrādi no nulles paturēt kā pēdējo, galējo variantu.

Izstrādātajā sistēmā noteikti ir lietas, kuras var izmantot. To ir pierādījusi gan Latvija.lv, gan EDS. Abas šīs sistēmas ar laiku ir kļuvušas ērtākas. Būtu jāveic audits. Bet nevis audits, lai saprastu, kas no pasūtītā ir uzbūvēts, bet kas no pasūtītā ir izmantojams. Kaut kur specifikācijās figurē arī API (application programming interface), kas ir saskarne, lai programmatūru izstrādātāji varētu papildināt esošo funkcionalitāti uz esošajiem datiem. Publiski gan nekur neatrodu kā šis strādā. Labs datu un lietotāju vadības API ir mūsdienīgas sistēmas pamatā. Specifikācijās ir atrodams šīs saskarnes apraksts.

Kas tas būtu par rakstu ap IT jomu, ja nebūtu kāds teikums vai divi par igauņiem. Viena no igauņu veiksmes atslēgām ir X-road, kas savos pirmsākumos (2001. gadā) bija vienota pilsoņu digitālā kartotēka. Tāds sava veida Facebook/Google “logins”, tikai valsts līmenī. Tā bija viena no pirmajām lietām, kura tika izveidota un kļuva par atslēgu pārējiem e- risinājumiem, nodrošinot piekļuvi datiem un to apmaiņu. Pašlaik mums ir Latvija.lv, kas nodrošina to pašu. Dažreiz veiksmīgāk, dažreiz ne pārāk. X-road pa šo laiku jau ir kļuvis par igauņu eksporta preci (https://x-road.global/) un apaudzis ar papildu funkcionalitāti.

Ja mēs gribam būt tā informācijas tehnoloģiju lielvalsts, tad mums vajag arī nopietni pret to attiekties un audzēt IT zināšanu bāzi valsts sektorā. E-veselības kontekstā zināšanas pilnībā tika ņemtas kā ārpakalpojums. Rezultātā tika izšķīdināta atbildība un iestājās haoss. Lai tas nenotiktu, valsts pusē ir nepieciešams kāds, kurš var uzņemties atbildību par IT jautājumu attīstību. Valstij ir nepieciešams savs CTO (Chief technology officer) ar komandu, kuri saprot esošo IT infrastruktūras saimniecību, ir ar vīziju par attīstību un, kas nav mazsvarīgi, ir ar atbildību par šo saimniecību. Pašlaik IT sfēra ir sadalīta pa vairākām ministrijām. Par infrastruktūru atbild Satiksmes ministrija, par IT sistēmu ieviešanu VARAM, par IT uzņēmējdarbību Ekonomikas ministrija. Un par pašiem programmētājiem (skaļām bungām rībot) … Kultūras ministrija. Programmēšana ir daļa no radošajām nozarēm.

Mēs, protams, varētu vienkārši visu izmest gružkastē (sveiciens no Liepājas) un nopirkt igauņu risinājumu. Bet IT infrastruktūra ir daļa no nacionālās drošības, un mums būtu jāspēj pašiem audzēt nacionālo kompetenci šajos jautājumos.

Es ceru, ka e-veselības kļūdas kalpos par spēcīgu pamatu labam risinājumam.