Andres Aavik: robot pole süüdi

Rahvastiku vähenemine tekitab vajaduse protsesside automatiseerimise järele, kus inimtööd asendav robot ehk infosüsteem peab olema lihtsasti arusaadav ja kasutajasõbralik. Kui süsteem ei toimi või on keeruline, siis pole süüdi robot ise, vaid põhjuseid tuleb otsida protsessides ja inimestes, kes on roboti loomise taga.

8. jaanuari Postimehes oli juttu ehitisregistrist, mille kasutamine on nii keeruline, et nõuab tavakasutajatele eraldi koolituse tegemist või ametniku sekkumist (Heidit Kaio «Uue bürokraatia koidik – näide suhtlemisest robotinäolise Eestiga»). Ehitisregister pole ainus riigi infosüsteem, mis kasutajatel karvad turri ajab. Ma ei nõustu Heidit Kaioga, kelle sõnul töötavad inimnäota robotid meie vastu. Robot teeb seda, mida inimene õpetab, ja kui infosüsteem ei toimi, siis on süüdi samuti inimesed ehk tellijad ja protsessid, mille käigus kasutajasõbralike e-teenuste asemel sünnivad käpardlikud lahendused.

Uus infosüsteem tellitakse tavaliselt juhul, kui vana süsteemi peetakse iganenuks või on võimalus töövoogu digitaliseerida, parandades kliendi kasutajakogemust või protsessile kuluvat aega. Tööjõupuuduse ja väheneva rahvaarvu tingimustes on automatiseerimisel veel üks lisapõhjus – kui töötajaid pole kusagilt võtta, siis tuleb inimeste tööks jätta vaid need töölõigud, mis eeldavad loovat ülesandelahendamist. Kõik standardiseeritavad ja korduvad protsessid saab korda ajada robotite abil, aga see eeldab, et inimene annab masinale õigeid ülesandeid, ja seda ei peaks oskama mitte lõppkasutaja, vaid infosüsteemi tellija.

Riigihangete puhul on probleem selles, et kokkuhoid ja hinnapõhised ostuotsused teevad riigist halva tellija. Nii ka ehitisregistri uuendamise puhul, kus jäeti projekti kaasamata lõpptarbijad ja tegemata kasutajasõbralikkuse analüüs või parandused. Tellija on läinud lihtsama ja odavama vastupanu teed, kirjutades infosüsteemi tuimalt sisse kõik võimalused, mis inimesega suhtlemisel olemas olid, hindamata nende tegelikku vajadust.

Robotite poole näpuga näitamise asemel tuleks nõuda riigilt targemat tellimist ja peale paberi asendamise ka päris uute ja lihtsamate protsesside väljamõtlemist. Kasutajakogemuse disain ehk UX peab olema kõigi infosüsteemide loomise osa. Samuti nagu peaks kõiki riigi tellitud infosüsteeme enne lõpptarbijat testima professionaal. Et tarkvara ja loogikavead parandataks õigel ajal arendusfaasis ja jääks ära olukorrad, kus kasutaja kulutab tunde, et leida failile õige nimekuju või kast linnukese tegemiseks. Selliseid apsakaid saab vältida, kui kaasata väline partner, kel on kogemust parima tulemuse saavutamisel ja kelle kogemuse najal saab infosüsteem kergesti kasutatav ja kõigile osalistele kasutoov.

Küsimus on siinjuures muidugi selles, kas me oleme ühiskondlikult nõus maksma veidi rohkem, et saada süsteem, mis ei loobi kaikaid kodarasse, vaid aitab meil õhendada riigisektorit ja luua riigiga asjaajamiseks meeldiv kasutajakogemus, kus vajalikud asjad saavad korda aetud paari nupuvajutusega. Esialgne suurem investeering hoiaks kokku väga paljude Eesti inimeste aega ja raha. Kui midagi kiiresti ja radikaalselt ette ei võeta, jäämegi kasutama näotuid roboteid ja mugavad tarkvaralahendused jäävad erasektori pärusmaaks.

Eduka tarkvaaraprojekti eelduseks on põhjalik eeltöö ja testimine

Tarkvara loomine või soetamine on Eesti ettevõtetes muutunud üha tavapärasemaks. Samas kuuleb aina rohkem lugusid sellest, kuidas tarkavara arendusel tuleb ette kõrvalekaldeid, süsteem ei saa lubatud ajaks valmis või läheb kogu protsess märksa rohkem maksma kui esialgu plaanitud. Flowiti tegevjuhi Andres Aaviku sõnul tuleb projekti õnnestumiseks silmas pidada järgmisi nüansse:

 

Analüüsi, kas tarkvara loomine on majanduslikult mõistlik

Enne tarkvara soetamist tasub põhjalikult analüüsida, millist protsessi tarkvara peaks asendama, muutma või looma. Vahet tuleb teha selles, kas tarkvara eesmärk on luua uut võimekust, uusi ärivõimalusi või muuta juba olemasolevat protsessi efektiivsemaks. Samuti tuleb välja arvutada oodatav rahaline kulu ja tulu, kui kiiresti peaks projekt end ära tasuma ning kuidas investeeringutega väärtust luuakse. Kindlasti on oluline kalkulatsiooni lisada ka nähtamatud kulud nagu hoolduskulud, tuleviku lisaarendused, turvalisuse tagamine, tehnoloogia areng ning tarkvara platvormide uuendamise vajadus.

Kaasa töötajad ning määra vastutajad

Tarkvara arendusse tuleb kaasata projekti ettevõtte töötajad, kes peavad olema teadlikud, et projekt on ettevõtte jaoks prioriteetne.

Lisaks tuleb äri poolelt määrata projekti eest vastutaja, kellel on õigus ka sisulisi otsuseid vastu võtta. Kui projekt hõlmab erinevaid ärivaldkondi, tuleb määrata vastutaja igast valdkonnast. Samuti tasub kaasata töögrupi näol kõik osapooled, kes suudavad anda projektile sisendit või kelle tööd loodav tarkvara mõjutab, sest vaid nii on protsessist ja tulemusest reaalne kasu.

Koosta lähteülesanne ning riskianalüüs

Enne tarkvara hankimist tasub koostada lähteülesanne ehk taustinfo koos nõuete nimekirjaga, kus on lahti seletatud ootused ärifunktsionaalsuse, turvalisuse, jõudluse, kasutatavuse jms osas.

Samuti tuleb teha riskianalüüs, mis toob välja projekti ohustavad suurimad sisesed ja välised nõrkused ning võimalused riskide maandamiseks. Kindlasti peaks riskianalüüsi hoidma ajakohasena kogu projekti kestel.

Arendamisel pane rõhku tarkvara kasutatavusele

Tarkvara arendamisel peab põhirõhk olema kasutatavusel – mida kergem on tarkvara kasutada, seda efektiivsem on selle kasutaja (töötaja).

Seetõttu on oluline süveneda arendaja esitatud küsimustesse ning vastata neile, sest mis võib esmapilgul tunduda ilmne, ei pruugi seda olla kellelegi väljastpoolt valdkonda. Olulist rolli tarkvara arendamise juures mängivad ka tarkvara demosessioonid. Mida põhjalikum tagasiside demosessioonidel anda, seda paremini saab arendaja ootustele vastata. Demosessioone tasub korraldada vähemalt iga kahe nädala tagant.

Lisaks tasub planeerida aega ning ressurssi vastuvõtutestimisele, mille raames kontrollitakse tarkvara funktsionaalsuse vastavust ärinõuetele. Mittefunktsionaalsete nõuete nagu koormustaluvus ja kasutatavus jaoks on mõistlik kasutada eksperdi abi. Testimisse tasub kaasata ka tulevased kasutajad, mille boonuseks on kasutajate varane tutvus programmiga ja põhjalikum tagasiside, mida arendusel arvesse võtta.

Nõua arendajalt parimatele praktikatele vastavat teostus

Projekti õnnestumiseks tuleb arenduspartnerilt küsida detailset arendusgraafikut, mis võimaldab jälgida projekti käiku ning saada võimalikult varakult teada kõrvalekalletest. Lisaks on vajalik arendajapoolne riskianalüüs, kust potentsiaalsed projekti ohustavad probleemid ning nende maandamisviisid arendaja poolt ära kaardistatakse.

Samuti tasub kokku leppida etapiviisiline tarne, sest varajane tutvus arendatava programmiga võimaldab anda täpsemat tagasisidet ning jaotada vastuvõtuga seotud töökoormus pikema perioodi peale. Lisaks peab arendaja järgima häid arendustavasid nii koodi kirjutamises, koodihalduses kui projektihalduses ning tegelema aktiivselt kvaliteedijuhtimisega. Mida varem viga avastatakse, seda kergem ja odavam on seda parandada.

Ära ei tohi unustada ka dokumentatsiooni, mis peab olema eelkõige kvaliteetne ning kirjeldama lühidalt ning täpselt, kuidas süsteem on üles ehitatud, sest see on aluseks edaspidistel uuendustel ja täiendustel. Samuti aitab dokumentatsioon ära hoida ka niinimetatud tarnija lõksu jäämist, kus kogu teadmus, kuidas tarkvaralahendus on üles ehitatud, kuidas seda edasi arendada või vigu parandada, on vaid ühe arenduspartneri käes. Maja ehitades ei oleks ka keegi nõus, et kõiki hooldustöid tuleks kogu kasutatava eluea jooksul tellida ühest ettevõttest.

Kui ettevõttes puudub eelnev tarkvara arenduse kogemus tasub projekti kaasata ka kolmas osapool ehk järelevalve, kes oskab seista Sinu õiguste ja vajaduste eest ning toetab ühise keele leidmisel. Rääkimata tehnilisest korrektsusest.

IT-innovatsioon – iga ettevõtte jaoks paratamatu

Autor: Andres Aavik, Knowit Estonia tegevjuht

Ettevõttete käibe kasvu prognoosid aastaks 2015 on aastataguse seisuga võrreldes oluliselt pessimistlikumad, mistõttu peavad ettevõtted varasemast enam  mõtlema innovatsioonile ning uutele lahendustele ja teenustele, mille abil haarata seni avastamata või lihtsalt täitmata turuniše (vt. ka Äripäev 26.01.2015 „Madalseis viib juhtide mõtted innovatsioonile“). Tänases Euroopa majanduskliimas ei ole eesmärk mitte ainult kasv, vaid tihti ka seniste tasemete hoidmine. Seega oleme me kõik täna otseselt või kaudselt sunnitud mõtlema äriinnovatsioonile. Nagu Charles Darwin seda defineeris – ellu ei jää kõige tugevamad ega ka kõige intelligentsemad, vaid kõige kohanemisvõimelisemad – me peame kohanema vajadusega pidevalt innoveerida, et mitte jääda ajale jalgu.

Muu maailmaga võrreldes on Eesti ettevõtted väiksemad ja tihti pole neil piisavalt ressurssi, et panustada piisavalt „järgmisele läbimurdele“. Alati ei leidu ka eraldi inimest, rääkimata tervest osakonnast, kes täiskoormusega arendus- ja uurimistööga tegeleks. Paljuski tuleb lootma jääda igapäevatööga hõivatud kolleegidele ning end jooksvalt turu ja valdkonna arengutega kursis hoida. See seab omakorda piirid jätkusuutlikule äri planeerimisele: kas tegevusi mõeldakse 1,5 või 15-20 aastat ette?  See, mis juhtus ettevõtetega nagu Atari, Netscape, Palm, AOL, Apple („esimesel ringil“), tundub meie jaoks täna justkui liiga kauge ja ebatõenäoline, kuid nende kogemused on see, mida peame arvestama, millele mõtlema ja mida tuleb ennetada.

Uute toodete ja teenustega turule tulemine ei ole komistuskiviks ainult tehnoloogiaettevõtetele. Pigem on mure suurem ettevõtetes, mille tänased tooted ja teenused ei ole piisavalt infotehnoloogiliste lahenduste tuge saanud. Neis napib ka piisavalt IT-valdkonna kogemusi ja kompetentsi astumaks järgmist sammu. Täna ei ole selleks enam olemasolevate äriprotsesside toetamine, vaid täiesti uute lahenduste loomine, mida senised ärisuunad, tegevusalad ja muidugi kogemused toetavad. Teisisõnu – läbimurdeks innovatsioonis ei piisa enam traditsioonilisest arendustegevusest. Mitmed Skandinaavia ettevõtted on sellele juba olulist rõhku asunud panema ning tulemuseks on paradigmamuutus, kus IT-konsultatsiooniettevõtted ei tooda enam etteantud kirjeldustele vastavaid tükke, vaid töötavad koostöös klientidega välja täiesti uusi äriprotsesse ja lahendusi etteantud probleemidele. Üha vähem on IT-ettevõtete palgal süsteemianalüütikuid ja üha rohkem äri- ning juhtimiskonsultante. Seega on infosüsteemide arendus liikunud toetavalt tegevuselt ärile palju lähemale, rohkem integreerunud – kompetentse ja võimekusi kasutatakse ära palju varasemas staadiumis kui seni. Traditisiooniline „meie teeme, teie loote lahenduse, et me saaksime seda teha digitaalselt/internetis/pilves“ lähenemine on kiirelt hääbumas, sest sellest jääb väheks. Kui mitte täna, siis juba mõne aasta pärast.

Tehnoloogia ja äri lähenemine ei ole aga eesmärk omaette. Sarnane põimumine ettevõtte ja kliendi vahel on toonud paljudele väikese ja keskmise suurusega ettevõtetele tohutu  konkurentsieelise.  Hea näitena võib tuua Rootsi sariettevõtja ja Skandinaavia tuntuima konsultandimüügi teemalise bestselleri „Försäljning i Konsultföretag“ autori Johan Sköldi, kes ei kirjuta müügipakkumusi kontoris arvuti taga, vaid teeb seda kliendi juures. Koos arutatakse pakkumine rida realt läbi ning tulemuseks on lahendus, mis mõlemale poolele maksimaalselt väärtust loob. Tõenäoliselt on Eestis selleks veel liiga vara ja traditsiooniline marginaalide arvutamine ning numbrite edasi-tagasi põrgatamine on liialt juurdunud. Või on need üksikud säravad tähed avalikkuse eest varjus püsinud? Tegelikult teame kõik, et umbisikuline keeruliste toodete ja teenuste müük on samuti hääbumas. Siis kui keegi lõpuks mõtleb välja,  kuidas skaleerida tõeliselt keeruliste toodete ja teenuste individuaalset ja personaliseeritud müüki, on võimalused piiritud.

Töövahendeid väiksemal või suuremal määral innoveerimiseks on palju. Viise, kuidas neid edukalt kombineerida ning oma konkurentsieeliseks pöörata, oluliselt vähem. Alustame lihtsamatest asjadest ning kuulame, kuidas teised oma äri arendavad. Astume läbi iduettevõtete ürituselt, seminarilt, konverentsilt, joome konkurendiga kohvi. Ja siis paneme selle kõik 15 aasta perspektiivi ning mõtleme mida täpsemalt on vaja täna ära teha selleks, et meie ettevõte 20 aasta pärast ei oleks seal, kus Atari, Netscape ja Palm.