Käesoleval nädalal analüüsin SKAIS2 projekti arendusmudelit. Kuna antud projekti puhul on materjali palju, olen jaganud oma analüüsi etappideks ning üritan igas etapis anda hinnangu, millise arendusmudeliga on tegemist. Meeles tuleb pidada aga seda, et SKAIS2 projekt jäi sellisel kujul poolikuks ning projekt lõpetati kompromisslepinguga töös esinevate probleemide tõttu. Käesolevaks ajaks on see projekt küll lõpetatud, kuid oma analüüsis keskendun just SKAIS2 projekti ajaloole.
Esimesena vaatame üle hankedokumentides olevad nõuded. Kuna tegemist on suuremahulise hankega, peab olema ka vastav dokumentatsioon põhjalik ning üheselt arusaadav. Samas oli hankemenetluse liik Võistlev dialoog (Hankemenetluse seadus §63) , mis tähendab, et esialgu valitakse välja pakkujad, kes sobivad esialgu hankija poolt seatud objektiivsetele tingimustele ning asutakse läbirääkimistele, et leida hankijale sobivaim pakkuja, tuginedes parimale pakutud lahendusele.
Hankedokumentides on selgelt välja toodud alljärgnevad asjaolud:
- leping loetakse täidetuks, kui arendustööd on kasutusele võtmiseks valmis ja üle antud tellijale;
- arendustööd võib üle anda ka etappidega (kui teenuse eripära seda võimaldab);
- tarkvara kasutajakeskne arendamine;
- projekt sisaldab ka disainitöid;
- pakkuja peab esitama ka nõuded tarkvara majutuskeskkonnale;
- lisaks tuleb kirjeldada testimiste keskkonnad;
- testimismetoodika valmimine ning testimisplaani esitamine;
- tarkvara täiendamine vastavalt auditi nõuetele;
- tarkvara dokumenteerimise põhimõtete valimine ja rakendamine, tarkvara dokumentatsiooni, kasutajajuhendite koostamine;
- riigi infosüsteemi haldussüsteemi (RIHA) andmekogu registreerimiseks vajaliku dokumentatsiooni ettevalmistamine, sh andmekogu andmeobjekti semantiline kirjelduse, andmekooseisu ning teenuste kirjelduste ettevalmistamise;
- haldamise nõuete läbiviimine ja koolituste läbiviimine
- hooldustööd
- projektijuhtimine, kvaliteedihaldus ja riskihaldus;
- hankedokumentides on välja toodud olemasoleva süsteemi kirjeldus ning ootused uuele süsteemile;
- lisaks on erinevate dokumentidega nõutud kvaliteedimeetmete kirjeldused, kinnitused kvalifitseeritud meeskonna olemasoluks ja muud dokumendid kvalifikatsiooni tõendamiseks
Lähtudes hankedokumentides esitatud nõuetest, on tegemist klassikalise kosemudeliga, kus iga etapp viiakse lõpuni, enne kui alustatakse uut. Kogu dokumentatsioon koostatakse suures osas juba võistleva dialoogi käigus ning range dokumenteerimise nõue tuleneb välja ka hankedokumentidest. Mis on ka iseenesest mõistetav, kuna hankemaht on suur, projekt on pikaaegne ning seetõttu võivad vahepeal muutuda meeskonnaliikmed. Kui aga korralik dokumentatsioon puudub, on ka uuel meeskonnaliikmel keeruline üle võtta pooleliolevad tööd.
Peale hanke võitja väljakuulutamist, esinesid meeskonnajuht ja tarkvara projektijuht ettekandega, kus saab välja noppida käesoleva:
- ettekandes on välja toodud kõik SKA protsessid
- projekti detailne ajakava (skeem lisatud)
- projekti ettevalmistamise skeem
- juhtimistasandid
Eelpool olev detailne ajakava on aga vast kõige huvitavam, kuna antud ajakava annab hoopis mõista, et eesmärk oli kasutada iteratiivset arendusmudelit.
2019 aastal tehti avalikuks audit, millega hinnati tarkvaraarendusprojektide ebaõnnestumisi. Seal on toodud välja huvitavad punktid, millega anti aga ka konkreetne hinnang arendusmudelile.
- Sotsiaalministeeriumil endal puudus tarkvaraarenduse kord ja seetõttu ei olnud nõudeid dokumentide sisu osas. Dokumendid olid siiski valminud koostöös arendaja ning töö tellijaga (projektiplaan, riskide loetelu). Samas riskide maandamise meetmed ei olnud piisavad ning riskianalüüs on puudulik;
- arendusprojektiplaani muudeti mitu korda;
- arendajatele edastatud info oli sageli muutlik ja vastuoluline (sisemise vale tööjaotuse tõttu);
- raamlepingu järgi valiti arendusmudeliks iteratiivne arendusmudel ning hetkest, kui üks arendajatest loobus edasisest arendustööst, jätkati agiilse Scrum-mudeliga. Iteratiivselt toimetades valmisid analüüsi tööd, esimesed suuremad tööd valmisid 2015 aasta veebruariks. Kuna projekt kujunes pikaks, tuli osa töid hiljem uuesti teha.
Lähtudes eelpool toodud infole, oli tegemist esialgu iteratiivse arendusmudeliga ning töö edenedes, mindi üle agiilsele mudelile. Kuid agiilse mudeli üks miinuseid on aga, et see projekt on määratud ebaõnnestuma, kui kliendil puudub täpne ülevaade, mis on vajalik teha või ei suuda edasi anda informatsiooni, mis on vajalik teha.
Ärimudeli otsustamisel tuleb vaadelda, mille ning kelle jaoks on antud arendus tehtud, kes ja kuidas seda kasutama hakkavad ning üritame leida veel mõned iseloomulikud jooned, et jõuda mingile otsusele.
Milliseid tooteid või teenuseid antud arendus pakub? Tegemist on elektroonilise keskkonnaga, kus toimuks täiselektrooniline menetlus (sealhulgas täielik tugi SKA tööprotsessidele, ühetaoline menetlus, protsesside standardiseeritus, infovahetus teiste registritega x-tee kaudu). Tegemist on iseteeninduskeskkonnaga, kus riik pakub e-teenuseid kodanikele ja ka ettevõtetele. Lisaks on võimalik arendusega hallata juurdepääsuõigusi ning statistika koostamist. Kokkuvõttes on arenduse kasutegurid nii riigile kui ka kodanikele.
Keskkonnale tagatakse ligipääs mitmes suunas. Ühelt poolt on sul riigitöötaja, kes vajadusel saab erimenetlustega tegeleda (mis automatiseeritud ei ole või on erijuhud) ning teiselt poolt pääsevad keskkonda kasutama eraisikud ning ettevõtete esindajad läbi autentimisvahendite.
Otseselt tulusid selle projektiga ei saavutata. Üritatakse automatiseerida töid ning seeläbi tööjõu kulusid ning eksimusi vähendada. Kulutused on vastavalt hinnapakkumistele välja toodud. Kuid nagu me teame, siis selle projekti maksumus ületas tegelikult erinevatel põhjustel igasugused ennustused.
Projekti ülevaatest võiks justkui tegemist olla tarkvara kui teenus (SaaS) mudeliga, kuid teenusel puudub igakuine kuutasu nõue. Samamoodi on ka Freemium ärimudeli puhul – inimesed saavad küll kasutada teenuseid kuid teenuste kasutamisel ei ole mingeid piiranguid ning maksimaalse teenuse kasutamiseks ei ole rakendatud lisatasusid. Tundub, et selle konkreetse ärimudeli leidmisel ei saa me vaadata klassikalisi ärimudeleid ning asun otsima vastust küsimusele – millisele ärimudelile vastab SKAIS2 projekt?
Internetiavarustest leidsin, et on olemas eraldi mõiste nagu e-riikluse ärimudelid (e-Government business models). Ning vastavas artiklis väljatoodud ärimudelite juures tundub sobivat kõige enam Direct-to-customer (otse-kliendini) ärimudeliga, kus pakutakse otseteenuseid tarbijatele ja ettevõtetele (sealhulgas spetsiaalselt tehtud lehed). Lisatud on võimalus teha tehinguid (näiteks avaldused. Oluline karakteristik on siinkohal see, et kasutajad aitavad end ise läbi iseteeninduse keskkonna.
Kuigi võib öelda, et SKAIS2 keskkonnal on lisaks omadused, mis vastavad osaliselt mudelile “Value-net-integrators“, nagu näiteks antud projekti raames suudab keskkond vahetada informatsiooni teiste keskkondadega läbi x-tee. Kuid selle ärimudeli puhul ei klapi tingimus, kus arendus on mõeldud kasutamiseks ainult kindlale segmendile ning lisaks ei paku selline ärimudel otse teenuseid kliendile. SKAIS2 aga kindlasti on mõeldud ühe kindla riigiasutuse teenuste tarbimiseks.
Üheselt konkreetset ärimudelit antud projektile on leida keeruline. Kuid nagu me teame, on väga palju erinevaid hübriidärimudeleid ka tekkinud, kus igast ärimudelist on mingi osa võetud kasutusele ja seeläbi loodud uus ärimudel. Usun, et SKAIS2 on unikaalne ärimudel ning kindlasti huvitav arendusprojekt ka teistele riikidele. Loodame, et tulevikus on sellised mahukad projektid edukamad ning õppetunnid sellest projektist laialdaselt arvesse võetud.
Triinu Viikholm blog 