Selle aasta viimases blogipostituses keskendun sellele, miks on infosüsteemide arendamisel võtmetähtsusega äriprotsesside kaardistamine ja nendest arusaamine. Olen viimastel aastatel erinevates arendusprojektides osaledes korduvalt saanud kinnitust, et misiganes teenuste, toodete ja süsteemide arendamisel on väga-väga oluline arusaam justnimelt kasutaja äriprotsessidest. Samuti olen kinnitust saanud sellele, et mida põhjalikum arusaam on tellijal või mida paremini arenduspartner endale selle arusaama tekitab, siis seda parem ja eesmärgipärasem on ka loodav lahendus.
Minu lugu
Ma ise töötan hetkel riigisektoris ja tunnetan igapäevaselt, kus ja kuidas me võiks äriprotsesside kaardistusest kasu lõigata. Teatavasti on riigisektoris vaja arendusressurss sisse osta riigihangete kaudu. Riigihanke lähteülesande arusaadavus ja asjakohasus sõltub tihti sellest inimesest, kes on määratud hanke lähteülesannet kokku kirjutama. Ja omast kogemusest tean, et need inimesed ei ole tihti needsamad, kelle tegevuste lihtsustamiseks konkreetset lahendust tellitakse. Väga harva sisaldavad nimetatud lähteülesanded loodava süsteemi äriprotsesside vaadet või kui sisaldavad, siis on need nii üldised või vigased, et nendest pole väga kasu. Nii me jõuamegi olukorrani, kus arenduspartner tuleb realiseerima üks-ühele seda, mis hanke lähteülesandes kirjas. Hoolimata sellest, et see pole lahendus, mis aitab tellijat tema tuleviku äriprotsessides.
Üks näide elust enesest – ühes arendusprojektis küsisin arenduspartneri käest “Miks konkreetset funktsionaalsust vaja on?” ja vastus oli “Sest see oli nii kirjas hanke lähteülesandes”. Selle peale küsisin “Palun seletage, kuidas see funktsionaalsus aitab parandada/efektiivistada lahenduse kasutaja tuleviku töövoogu?”, mille peale saabus vaikus. Väga kõnekas näide! Kahjuks puutun sellega kokku pea igas arendusprojektis. Kuidas siis ikkagi sellist olukorda lahendada ning kes peaks ühes arendusprojektis vastutama äriprotsesside eest? Aga enne veel kui nende küsimuste üle arutlen, räägin natuke sellest, miks minu meelest peaks äriprotsesside kaardistus olema iga IT lahenduse loomisel kohustuslik tegevus.
Äriprotsesside olulisus infosüsteemide arenduses
Olen päris mitmes arendusprojektis omal nahal tunda saanud, kuidas süsteemi arendamisel ei piisa lihtsalt erinevate nõuete (nt. süsteemi funktsionaalsed ja mittefunktsionaalsed nõuded vms) kirja panemisest ja nende järgi arendamisest, vaid tõesti on vaja läbi mõelda ka kasutaja teekond või äriprotsess loodavas lahenduses. Vastasel juhul arendatakse terve rida erinevaid funktsionaalusi, mis ei ole omavahel seotud ning ei aita kasutajat kuidagi tema töö tegemisel. Pigem võib ühelt funktsionaalsuselt teisele liikumine võtta kasutajal hoopis rohkem aega ja seetõttu on süsteem kasutaja jaoks halvasti kasutatav. Samuti võib puhtalt nõuete järgi arendamine tingida selliste üleliigsete funktsionaalsuste arendamist, mida kasutajal tegelikult oma töö tegemiseks vaja ei lähe.
Infosüsteemide arendamisel on oluline mõista töövoogu, kuidas kasutaja loodavat süsteemi kasutama hakkab. Funktsionaalsusest üksi on vähe kasu, kui ei ole teada, mis loogikaga ja järjekorras kasutaja loodavat funktsionaalsust kasutada tahab. Uute süsteemide arendamisel räägitakse palju ka kasutajakesksest disainist ja sellest, kuidas see peab olema integreeritud tarkvaraarendusse. Ka kasutajakeskse disaini põhifookus on sellel, et mõista, kuidas kasutaja tegelikult mingit tegevust teha tahab. Sisuliselt selgitatakse samamoodi välja, kuidas kasutaja hetkeolukorras toimetab, millised mured/probleemid tal sellega seoses esinevad ning kuidas ta soovib tulevikus toimetada. Ainuke erinevus on see, et töö tulemina ei teki tavaliselt äriprotsesside joonised, vaid hoopis kasutajateekond ja prototüüp loodavast süsteemist.
Prototüübi loomisel peaks jälgima seda, et prototüüp ei kajastaks lihtsalt AS-IS äriprotsessi digitaalset versiooni. Sellega mõtlen seda, et lihtsalt ei digitaliseeritaks üks-ühele uue süsteemi jaoks AS-IS tegevusi, vaid ikkagi analüüsitakse AS-IS äriprotsessi ning proovitakse leida ka äriprotsessis endas (st. kasutaja praegustes tegevustes) tõhustamise kohti. Vastasel juhul jõuame sinna, et digitaliseeritakse ka ebaefektiivsusi ning uus süsteem ei pruugi anda seda kasu, mida sellelt loodeti. Mainitud olukorda ilmestab väga hästi üks minu lemmikuid Bill Gates-i tsitaate:
“The first principle for any technology you contemplate introducing into a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will just magnify inefficiency.” Bill Gates
Mainitud tsitaadis ongi rõhutatud seda põhimõtet, millest rääkisin ka AS-IS äriprotsessi analüüsimise blogipostituses – digitaliseerimine/automatiseerimine peaks olema üks viimaseid äriprotsessi efektiivistamise meetodeid. Sellega tagame, et automatiseeritakse efektiivseid tegevusi.
Kes peaks arendusprojektides hea seisma äriprotsesside eest?
Tegelikult peaks iga tellija hea seisma, et nii tema ise kui ka arendaja saaks aru äriprotsessist, mida loodava lahendusega automatiseeritakse. Kõlab ju loogiliselt ja ideaalmaailmas võiks see nii toimidagi! Põhjuseid, miks see reaalses elus nii ei toimi on mitmeid – esiteks ei ole tellijal inimressurssi äriprotsesside kaardistamiseks ning teiseks jääb tihti vajaka ka tellija teadlikkusest ning oskustest. Esimese põhjuse kõrvaldamine on kõvasti keerulisem kui teise põhjuse kõrvaldamine.
Kui tellijal endal ei ole inimressurssi, kes mingit töölõiku võiks teha, siis see üldjuhul tähendab täiendava inimressursi sisse ostmist, kas siis hanke korras või mõnel muul viisil. Ja selleks, et sisse ostetud täiendavat tööjõudu korralikult rakendada, on vaja tellijal anda õiged suunised või lähteülesanne antud töö tegemiseks. Aga selliste juhiste andmine nõuab tellijalt omakorda aega, süvenemist ja panustamist. Ekslikult arvatakse, et kui ressurss mingi töö tegemiseks hangitakse, siis tellija saab kogu vastutuse anda arenduspartnerile ja ise ei pea üldse selle teema peale enda aega kulutama. See arusaam on tegelikult vildakas! Kui sul on vaja mingi töölõik ära teha, siis tuleb ühel või teisel juhul nagunii oma aega sellesse panustada! Küsimus on siin pigem selles, et kas välise ressurssi sisse ostmise lahendus on antud kontekstis kõige aja- ja kuluefektiivsem.
Teise probleemi kõrvaldamiseks piisab tellija teadlikkuse tõstmisest ja koolitamisest. Seda saab edukalt teha nii iseseisvalt kui ka erinevate koolituste kaudu. Oma “Äriprotsesside kirjaoskuse” koolituse olen just kokku pannud selle tagamõttega, et tellijatele õpetada, mis on äriprotsessid, kuidas neid kaardistada, modelleerida ja tõhustada. Olles ise äriprotsessidega seotud pigem IT lahenduste arenduste kaudu, ongi koolituse fookus ja ka peamised näiteid just IT arendustega seotud.
Lõpetuseks tahaksin ka arendusfirmadele südamele panna, et palun proovige uute lahenduste arendamisel mõelda alati äriprotsesside perspektiivist. Kontrollküsimus võiks olla – “Kas ja kuidas arendatav lahendus aitab kasutajal oma tegevusi paremini teha?”. Kui tellija ise teile oma äriprotsesse ei tutvusta, siis palun jõudke selle teadmiseni koostöös temaga. Meile on vaja lahendusi, mis aitavad inimeste tööd lihtsustada ja selle läbi aega kokku hoida, mitte üks-ühele kellegi poolt ma ei tea mis ajahetkel hankesse vormistatud lähteülesande realiseerimist!
Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!
Good to know.
Good luck!