Riigi IT-projektide suurim häda on läbimõtlematus

Vägisi meenub muinasjutt : mine sinna, ei tea kuhu ja too seda, ei tea, mida. Kui asi on tõepoolest nii nagu sellest auditist nähtub, siis tuleb ikka väga tõsiselt kahelda nii mõnegi persooni pädevuses ja küsida, miks on hõivatud töökoht, millele võimed ei vasta.

See häda ei ole iseloomulik ainult riigi IT-projektidele. Nendega seotud skandaalid jõuavad lihtsalt rohkem avalikkuse ette. Erasektoris on täpselt samasugused jamad. Viimasel ajal on paljud minu kliendid palunud abi kraavi jooksnud CRM tarkvara juurutuste päästmiseks. Olen tänaseks meie IT valdkonna probleeme näinud mitmest küljest - olles ise IT lahenduse tellija ja nüüd ka IT lahenduse tellija nõustaja.

Suurim probleem Eesti IT valdkonnas on harituse (mitte hariduse) puudumine. Suur hulk IT spetsialiste on oma oskused omandanud valdavalt katsetamise ja praktika käigus. Akadeemiline IT haridus tundub olevat igav. Mis on selle tagajärg - süsteemse lähenemise puudumine, mis kõigepealt paistab välja sellest, et ei tunta elementaarseid termineid ja kasutatakse neid valesti?

Kogu IT valdkond räägib enne töö alustamist mingist müstilisest analüüsist ja eelanalüüsist. Mis asi on analüüs? Võtame lahti sõnastiku http://www.eki.ee/dict/ekss/index.cgi?Q=anal... mis ütleb, et analüüs on "(alg)osadeks lahutav uurimine, eritlus."

Mida siis eelanalüüs peaks tegema - algosadeks lahutama kliendi tellimuse!? Aga seda ju ei ole, on kõik osapooled korduvalt tõdenud. Lähteülesanded on üldsõnalised, segased, vastuolulised, puudulikud. Analüüs saab tuvastada ainult seda, et lähteülesanne puudub.

Millest tegelikult on puudus, on süntees - "(alg)osade ühendamine, nendest terviku koostamine" teisisõnu, süsteemi kirjeldamine tervikuna. Ei oska seda teha tellija, paraku ka paljud IT firmad.

Kui aga inimesed saavad juba alusmõistetest (fundamentaalterminitest) erinevalt aru, mis on siis võimalused ühise keele leidmiseks tellijal ja täitjal!?


Toon paar näidet.

Näide 1. Mobiilparkimine - vildakas lähteülesanne.

Süsteem küsib, mitme krooni eest tahad parkida. Kas parkija mõtleb, et "mul on XX krooni, rohkema eest ma parkida ei saa"? Ei mõtle, parkijal on vaja parkida mingi kindla kellaajani. Mida kasutaja peab tegema, et nii juhtuks - lugema tahvlilt, mitu krooni maksab 15 minutit parkimist (!), korrutama neljaga, lahutama tasuta parkimise limiidi, kui see on olemas, sisestama limiidi. Kas häda oli eelanalüüsis - terviku osadeks lahutamises? Ei olnud - häda oli sünteesis, ehk mõtlemises, kuidas tegelikult asi PEAKS käima.

Näide 2

Ettevõte tellis endale CRM süsteemi veebiarendajalt. Kui ligi aasta oli tööd tehtud, avastas arendaja, et süsteem on nii keeruline, et "me ise ka enam ei saa aru, kuidas see töötab". Tegu ei ole alustava IT firmaga. Kas häda oli analüüsis - ei olnud. Puuduvad elementaarsed protsessikirjeldused (plokkskeemid), kuidas süsteem peaks mingeid tegevusi täpselt tegema, millist infot kasutama, millist infot väljastama. Ei ole analüüsi, on sünteesi, lähteülesande puudumise probleem.

Näide 3

Ettevõte CRM moodul on juurutatud, tellija tuleb minu juurde ja küsib: "mida ma nüüd sellega teen" Loen läbi eelanalüüsi dokumendi. Selles on kirjas "kui müügiprotsess õnnestub standardiseerida, saab selle teostada workflow'na"!? Kogu süsteemi mõte oligi, et müügiprotsess automatiseeritakse. Analüüs tõdes, et ei ole mida automatiseerida. Mida edasi tehti? Kas keegi alustas müügiprotsessi standardiseerimist - koostas korraliku protsessikaardi, töövood (flowchart), kirjeldas sisendid-väljundid? Ei - CRM tarkvara juurutati, pandi käima nii nagu ta karbist välja tuleb ja anti kliendile. Loomulikult küsib klient: "mis ma siis nüüd sellega peale hakkan"

Milline peaks olema terviku kirjeldus?

Alustame elementaarsest - iga süsteemi selgrooks on algoritm, plokkskeem, protsessikaart mis kirjeldab, kuidas asjad peaks töötama. Kui see on CMR tarkvara, siis müügiprotsessi detailne kirjeldus. Kui see on parkimise tarkvara, siis parkimise protsessi kirjeldus. Diagrammi, skeemina, mitte tekstilise kirjeldusena. Soovitavalt mõne standardi, nt IDEF alusel.

Niipalju, kui ma olen näinud metsaläinud tarkvara arendusi, on kõikidel neil ühised "omadused" - plokkskeemid on puudu, andmemudelid on puudu, tarkvara kood on dokumenteerimata.

Algoritmid, protsessikaardid, töövood ja andmemudelid on kõik sünteesi ehk lähteülesande koostamise väljundid.

Me võime isegi kokku leppida, et IT valdkonnas tähendab analüüs tegelikult sünteesi, aga sisu sellest ei muutu: ei ole võimalik, et süsteem hakkab tööle, kui lähteülesanne on vilets. Ses suhtes Tarviga 100% nõus.

Riigikontrolli auditist kumab läbi küsimus, mis on odavam – kas teha pikemalt ja korrektsemalt ettevalmistust (Riigikontrolli soovitus) või teha kiiresti, jättes ära tõenäoliselt suhteliselt kuluka kaalutlemise ja vajaduste analüüsi protsessi, kuid samas hakata esimesel võimalusel kasu teenima uue infosüsteemiga kaasnevast efektiivsuse kasvust (tihti riigiasutuste eelistatud variant).

Mina ja minu kolleegid FocusIT-s pooldame samuti Riigikontrolli poolt soovitatavat hea ning piisava eelanalüüsi tegemist. Samuti oleme nõus Indrek Sauli poolt mainitud põhjaliku vajaduste defineerimise ja olemasolevate äriprotsesside eelkaardistuse tegemise olulisusega. Kuid sealjuures ei tasuks unustada, et infosüsteemidega kaasnev efektiivsus tekib ainult siis, kui sellega koos vaadatakse üle ka inimeste töökorraldus – kas kõiki tegevusi on vaja enam vana-moodi teha, mida on võimalik ära jätta, kas kõiki töötajaid on üldse edaspidi vaja tööl hoida jne. Aga mis tihti unustatakse – uus infosüsteem võimaldab üldjuhul koheselt või väga vähese ajaga saada kätte või edastada informatsiooni. Kui müügiprognoose tehakse peale CRM-i juurutamist endiselt üks kord nädalas toimuval müügikoosolekul käsitsi tahvlile, siis pole ju CRM-i süsteemist rahavoogude planeerimisel abi. Ehk efektiivsust ja kasumi kasvu, mida selle kiire info saadavusega oleks võimalik saavutada (nt uue toote kiirem turule toomine, kliendi-sihtgrupi oluline laiendamine, prioriteetide seadmise võimaldamine vms) pole ära kasutatud. Seega iga äriprotsesside kaardistuse juurde peab kuuluma kõigi äriprotsesside kriitilise pilguga ülevaatamine ja vajadusel ümberkorraldamine, sealjuures enne kui IT analüütikud infosüsteemi arenduse lähteülesannet (ehk detailanalüüsi) hakkavad koostama.

Metoodikatest ja nõuetest rääkides peab tunnistama, et kõikvõimalikke nõudeid riigi infosüsteemiga seotud arendusprojektide algatamisele, elluviimisele ja aruandlusele on kehtestatud sadu kui mitte enamgi. Probleemiks võib osutuda nende nõuete leidmine, neist üldse teadlik olemine, ka nõuete kohatine põhjendamatus, vasturääkivus. Üks lahendus sellele probleemile on riigi infosüsteemiga seotud arendusprojektide läbiviijate tihedam suhtlus, ühised seminarid ja infovahetus, ka sotsiaalvõrgustiku loomine RISAP (riigi infosüsteemi arendusprotsess) juures.

FocusIT kogemus näitab, et Eesti ja mitme teise EL-i liikmesriigi avaliku sektori projektides annab parima tulemuse kui:
1) tellijaks on äripoole esindaja, keda lähteülesande koostamisel toetab süsteemianalüütik;
2) kasutatakse iteratiivne arendusmetoodikat, kus täitjad survestatakse vajadusel tellija huve kaitsva järelevalvega;
3) tellijal on võimalus vahetada arendajat mis-tahes ajahetkel.

Enamike probleemide algallikad peituvad halvas kommunikatsioonis - suhtleme rohkem ja maailm muutub paremaks.