9. veebruar 2010

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.

Esimene artikkel pöörab tähelepanu sellele, et riik seob ennast pikaajaliselt ühe partneriga ja õõnestab sellega vaba konkurentsi, teine artikkel aga nuriseb selle üle, et riik ei oskagi projekte tellida ning põhjustab seega Eesti IT arengu vähikäiku.

Peab tunnistama, et olin mõlema artikli esmalugemisel kallutatud mõtlema artikli tooniga kaasa ja nõustuma seisukohtadega. Sageli on tekkinud tunne, kas on ikka korrektne see, et Webmedia omab domineerivat rolli näiteks rahandusministeeriumi arendustes ja artiklis mainitud TÜ Kliinikumi projektides.

Olukorda aga veidi erapooletumalt analüüsides on sageli selliste pikaajaliste suhete põhjuseks just partneri ja tellija vahel tekkinud hea töörütm ning positiivsed tulemused. Sarnaselt Webmediale on ka teistel IT-firmadel olemas oma partnersuhted. Näiteks artiklis mainitud Fujitsu Services ASi (endine Cell Network) seostatakse sageli X-tee arendusprojektidega, Helmest haridusministeeriumiga, Net Groupi majandusministeeriumiga jne. Sellistes suhetes ei tasu alati korruptiivse maiguga tegevusi otsida, vaid tuleb mõista, et pikaajaliste partnerlussuhete taga on rahulolu. Projekti edukaks kulgemiseks on vaja tugevat partnerlussuhet ning usaldust tellija ja täitja vahel.

Teiselt poolt vaadates võiks küsida, kas väljakujunenud partnerlussuhte efektiivsus on alati kontrollitud. Kas partneri esitatud jätkuarenduste hinnad on konkureerivad ja arendustööde arhitektuur ajas edasi arenev ning efektiivne? Kui 5- 10 aasta jooksul arendatakse välja infosüsteem, mille arhitektuur oma põhikomponentides ei muutu, on arendusfirmale tegemist hea projektiga. Rahul võib olla ka klient, kuna võimalikult stabiilse arhitektuuri hoidmine võib olla halduskulude mõistes efektiivne.

Antud lähenemine võib tekitada siiski aja jooksul probleeme. Näiteks olukorras, kus partnersuhe ja koostöö ei laabu endises rütmis. Samuti siis, kui ajas uuenev tehnoloogia annab võimalusi efektiivsema arhitektuuriga arendusteks. Sellisel juhul on pikaajalisest koostööst (5-10 aastat) väljumine riskantsem või kulukam, kui pidev konkureeriva kompetentsi hoidmine. Minu hinnangul on arenduste osas heas seisus artiklis kritiseeritud Põhja-Eesti Regionaalhaigla (PERH), kes on otsustanud mõni aasta tagasi moodulite haaval lagundada olemasolevat monoliitset kesksüsteemi ESTER teenustel põhineva arhitektuuriga komponent-rakendusteks. Selline lähenemine võimaldab PERH-il hoida majas paralleelselt kahte või enamat arendajafirmat, kes omavahel konkureerides hoiavad hinnataseme kontrolli all, kuid PERH-i jaoks laiendab see valikuvõimalust (spetsiifiline kompetents on mitmes firmas) ja sisuliselt on võimalik igal ajahetkel partnereid vahetada uute riigihangete raames. BizTalk sõnumivahetusel ja veebiteenustel põhinev arhitektuur hoiab samas modulaarse infosüsteemi ühtse tervikuna.

05.02 artiklis toodud probleemkoht autoriõiguste osas vajab tähelepanu. Siin tuleb selget eristada, kas hangitakse nö valmistoodet, mida teenusepakkuja tellijale litsentseerib või on tegemist arendustööde tellimisega. Juhul, kui hanke raames ostetakse arendustööd (ehitajaid, kes müüri laovad), siis on tellijal õigus ja riigi puhul paraku ka kohustus saada endale töö osas varalised õigused selleks, et jätkuhangetes oleks järgmisel firmal võimalik näha ja kasutada rakenduse lähtekoodi ning arhitektuurseid komponete. Juhul, kui hangitakse litsentseeritav tarkvara, peab tähelepanu juhtima tarkvara liidestusvõimaluste standardsusele. Sellisel juhul on jätkuhankes osaleval ja seda võitval konkureerival ettevõttel olemas võimalus arendada lisafunktsioone litsentseeritava rakenduse koodibaasi trügimata. Ka siin aitab hästi teenustel põhinev arhitektuur ning modulaarsed kasutajaliidesed.

Mida siis riik saaks teha, et tarkvaraarendusfirmad oleksid rahul, et oleks tagatud aus konkurents, et oleksid kaasatud kõik platvormid ja et hangitud projektid jõuaksid ka tulemusliku lõpuni, olles efektiivsed ja ka korduvkasutatavad näiteks ekspordi eesmärgil?

Lahtise eelarvega projektid?

Lugedes 08.02 EPL artiklist Kalle Arula (RIA direktori asetäitja) seisukohti, et IT arendustööde tellimuses ei ole võimalik kõiki detaile ette näha ja et pakkuja teeb edukaks tema arhitektuuriline nutikus, olen tema seisukohaga suures osas nõus. Tõepoolest ei ole võimalik kõiki üksikasju kindlaks määrata projekti hankimisel, kuid kuidas käituda alltoodud näite korral:

Näide: rakenduse lähtematerjalides on öeldud, et rakenduses peab olema loodud punane nupp. Samas on jäänud spetsifitseerimata see, kus see nupp ekraanil asuma peaks, kui kõrge ja kui lai, millisele värvikoodile punane värv vastab ning kuidas nupp peab reageerima siis, kui sellele vajutatakse või kui sellest hiirega üle liigutakse.

Nimet Pakkuja loeb lähteülesandest välja ühte ja tellija eeldab teist ning enne, kui nupp lõpuks graafilises keskkonnas disainitud ja esitletud, ei saa olla kindel, et lahendus on sobiv. Antud olukorras on tellija tavapärane käitumine see, et hakatakse täpsustama detaile ja võetakse seisukoht, et tellijal on õigus täpsustada, kuna lähteülesandes ei olnud ju täpselt kirjeldatud, milline see nupp olema peaks. Täitja vastuvaidlemise korral viitab tellija lepingule ja tuletab meelde võimalusi selle ennetähtaegseks lõpetamiseks.

Sageli lähevad arendusfirmad sellistel juhtudel kliendi spetsifikatsiooni täitma, kaotades projekti jaoks aega ja ressurssi rohkem, kui eelarves planeeritud. Kui selliseid „punaseid nuppe“ esineb rakenduses aga rohkem, siis jõuavad projektid välja konfliktideni (RIA VS SmartLink; Andmevara VS Helmes jt). Konflikti põhjustajaks ei ole aga mitte vähene kompetents, vaid sageli piiranguid seadev hankemenetluse liik. Lääne-Euroopa ja Skandinaavia arendusprojektides on valdavaks saanud lahtise eelarvega projektid, kus määratakse tööde orienteeruv maksumus, aeg ja ressurssi hulk, kuid antakse vabad käed infosüsteemi arenduse vältel muudatusi teha. Näiliselt võib selline hankemeetod tunduda riskantne, kuid praktika näitab, et kui projekti juhitakse korrektsete meetoditega (nt agiilne arendus) ja kui tellija võib täitja vähese efektiivsuse korral lepingu katkestada ja järgmise partneriga jätkata, on ka lõpptulemus parem.

Nagu ka eelmiste probleemide lahenduseks, pakun siin ennekõike teenustel põhineval modulaarsel arhitektuuril üles ehitatud infosüsteeme, mis annavad võimaluse mitmel konkureerival ettevõttel paralleelselt töid teostada ja seega ühe partneri riski maandada.

Kokkuvõttes eelpool toodud seisukohti, arvan, et tarkvaraprojekte on võimalik teha hästi. On oluline kogu protseduuri juures mitte unustada, et edukates projektides ei ole klient kuningas vaid osapooled on partnerid ja projekt on edukas siis, kui mõlemad pooled sellest võidavad. Partnerlussuhte loomiseks on vaja partneritele anda võimalus. Selle tekkimiseks on omakorda vaja teha muudatusi arhitektuurilises mõtlemises. Riik ei tohi osta töid lepingutega, mis seovad neid täitja külge aastateks puhtalt selle põhjendusega, et turul ei ole valida samasuguse kompetentsiga konkureerivat partnerit. Avatud, teenustel põhineva arhitektuuriga infosüsteemid annavad selleks võimaluse ja annavad ka platvormivabaduse, laiendades oluliselt konkurentsi ka erinevaid platvorme (.NET, JAVA, PHP) viljelevate partnerite seas.

Samal ajal ei tohiks igal võimalusel kritiseerida korduvalt õnnestunud edukaid partnerlussuhteid ning asuda otsima korruptsioonikahtlust. Korruptsioon on meil õnneks siiski kurb erand kui tavareegel. Hangete seisukohalt võiks riik sagedamini kaaluda avatud konkursiga läbirääkimistega pakkumismenetlust, kus ostetakse sisse parima hinna- ja kvaliteedi suhtega kompetentsi, mitte projekti tervikuna, mis loob tugevama aluse kahepoolsele partnerlusele ning ka edukate projektide hulgale.

Autor: ituudised.ee - Äripäeva IKT uudiste teemaveeb