Olen huviga jälginud Sotsiaalkindlustusameti infosüsteemi kaasajastamise projekti SKAIS2, sest oma karjääri jooksul olen istunud nii ühel kui ka teisel pool lauda - olnud riigiasutuses tellija ja ettevõttes pakkuja.

SKAIS2 stsenaarium on riiklike süsteemide arendamisel pigem reegel, kui erand: kokku lepitakse tähtaeg, kuid tegelikult pole selget nägemust eesmärgist ehk sellest, mida selle aja jooksul valmis tehakse või kuhu tahetakse jõuda. Näitlikustades võib öelda, et soovitakse teele asuda, teadmata, kuhu kavatsetakse jõuda, mida on vaja ning kui raske või keerukas saab kandam olema. Täiendavaid piiranguid lisab valitud riigihankemenetlus, mis välistab sageli vajaliku paindliku ja efektiivsema lähenemise.

Seega soovin jagada tänastele tellijatele retsepti mahukate infosüsteemide edukaks realiseerimiseks.

Eelneva kahekümne aasta jooksul olen juhtinud Politsei põhiinfosüsteemide väljavahetamist ja nullist uute lahenduste loomist, vedanud rahvusvahelises ettevõttes tootmis- ja juhtimisinfosüsteemi Go-Live protsessi ning juhtinud rahvusvahelises finantsettevõttes digilahenduste realisatsiooni uute rahvusvaheliste turgude jaoks. Täna soovin aidata Thorgate'i klientidel tehnoloogia abil äriprotsesse optimeerida ja automatiseerida.

Et jutt ei jääks liiga ümmarguseks, teen oma mõtted n-ö puust ja punaseks.

Ainuke õige viis, kuidas ideaalis nii tähtsaid ja mahukaid projekte nagu SKAIS2 (igakuiselt seotud rohkem kui poole miljoni inimese heaoluga) teostatakse, on jagada projekt etappideks ehk väiksemateks osadeks. Lõplik toode on küll infosüsteem, kuid me oleme Thorgate´is võtnud aluseks levinud tootearenduse protsessi, mis annab mõistliku raami ja on osapooltele arusaadav. Klient pöördub meie poole idee ja ärianalüüsiga ning meie teeme digitoote-arenduse: analüüsi, disaini ja arenduse. Täpsed mahuhinnangud järgmisele etapile on võimalik anda pärast iga etapi lõppu. Samas käivad tööd tsükliliselt - näiteks disaini etapist on võimalik minna tagasi analüüsi ja arendusest disaini etappi.

Veel täpsemaks minnes aitab tulemuslikkuse saavutada võimalikult väikeste funktsionaalsuste ja võimalikult väikeste sammude kaupa eesmärgi poole liikumine, kogudes teel olles pidevalt tagasisidet, et loodava lahenduse käigus vajadusel suunda muuta, riske maandada ja kahjusid kontrolli all hoida.

Toote disainimisel on võimalik kogu loodava lahenduse arhitektuur ja äriprotsessi osised lahti võtta ja üles leida võimalused süsteemi efektiivistamiseks, seda siis automatiseerimise ja erinevate integratsioonide kaudu. Lihtsustatult on nutikas kasutada vähem tööjõu ja rohkem e-riigi poolt pakutavaid võimalusi panna arvutid rutiinseid ülesandeid täitma. Nii jääb inimestele vaba aeg, mida on võimalik kasutada sisuliste teemadega tegelemiseks. Eesmärk ei ole muuta tööprotsessi täitjaid infosüsteemi vangideks vaid anda neile vajalikul hetkel piisavalt informatsiooni õigete otsuste tegemiseks.

Riiklike lahenduste puhul võib vaja olla lahenduse loomise käigus muuta või täiendada seadust või hakkab kehtima uus seadus, mille nõuded on vaja samuti äriprotsessi modelleerida.

Lahenduse arhitektuuri loomisel saab tehnilise disaini ehitada väikeste teenuste kogumitele, mida üksikuna on lihtne muuta ja mis suhtleb teiste osistega standardsete masinliideste (API) kaudu. Selline lahendus teeb omakorda edasise haldamise kulu väiksemaks ja lihtsamaks. Kui mõni komponent ei rahulda enam kasvanud süsteemi vajadusi, siis on võimalik lasta sobival partneril see täiendada või asendada.

Aga meeles tuleb pidada, et IT ja tehnoloogia on eelkõige vahend sisuliste (äriliste) eesmärkide saavutamiseks ning ei ole eesmärk omaette. Kuniks see nii pole, on tehnoloogia alati süüdi, kahjuks.

Kokkuvõtteks: suurte projektide edukuse aluseks on

• selge projekti eesmärk ja selleni jõudmise teekond ning projekti edukuse hindamise kriteeriumid, mis on kogu arendusmeeskonna eesmärgiks.
• tasakaalus arendus juhtmeeskond - olemas on nii tootejuht (äriline vastutaja), valdkonna tippjuht (sponsor), äripoole projektijuht, IT projektijuht.
• MVP (Minimum Viable Product) lähenemine ehk alustada minimaalsest elujõulisest tootest ja ehitada toodet funktsionaalsuste kaupa edasi. Näiteks Maanteeamet lansseeris e-teeninduse esialgu vaid kahe teenusega.
• tootedisain kasutajamugavuse disainist, sisu ja äriprotsessideni. Esialgu hinnatakse ning teostatakse analüüsi ja UX’i etapp, mille jooksul valmistatakse skemaatiliselt ette kõik süsteemi loogilised vaated, lepitakse kokku funtsioonaalsused ja pannakse paika üldine projekti skoop.
• lahenduse arhitektuur peab olema paindlik ja võimalikult lihtsasti muudetav. Et oleks võimalik ebasobiv komponent vajadusel välja vahetada nii, et see ei mõjuta terviksüsteemi toimimist. Võti on siin mikroteenuste kasutamine ja teenusepõhine arhitektuur. Teenuste (API) loomisel ja uuendamisel on mõistlik kasutada versioneerimist.
• kasutatavuse analüüs ehk lõppkasutajate tagasiside süsteemile ja vajadusel järgmisesse arendustsüklisse muudatusvajaduste kirjeldamine.

VIRGO RIISPAPP
(töötab tehnoloogiajuhina digitoote-agentuuris Thorgate)