Rubriik: Uncategorized (Page 1 of 2)

Millist rolli mängivad äriprotsessid infosüsteemide arendamisel?

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!

 

Miks on lüüsid äriprotsessides tähtsad ja kuidas neid õigesti kasutada?

Nagu eelmises postituses mainisin, siis on lüüsid (ingl. gateway) äriprotsessides väga olulised elemendid ja seepärast tuleb neid ka mudelites otstarbekalt kasutada. Miks on siis lüüsid ikkagi olulised? Eks ikka selleks, et suuta võimalikult reaalelu lähedasi situatsioone modelleerida. Päriselus ei ole ka meie tegevused sirgjoonelised, vaid sisaldavad vähemal või rohkemal määral erinevaid otsustuskohti. Otsutuskohad, mida protsessimudelites modelleeritaksegi lüüside kaasabil, omakorda defineerivad protsessi edasise käigu ja loogika.

Võtame näiteks ühe väga lihtsa tööprotsessi – seesama hommikusöögi valmistamise protsess, mida oma esimestes postitustes näitena kasutasin. Ka selline lihtne tööprotsess sisaldab väga mitmeid otsustuskohti – näiteks peab kõigepealt otsustama, mida hommikusöögiks üldse süüa soovitakse (omletti, võileiba, putru vms) ja see otsustuskoht määrab ära protsessi edasise käigu – iga eelnevalt mainitud söögi valmistamine eeldab iselaadi tegevusi . Samuti peab mainitud protsessis näiteks otsustama, kas juuakse musta kohvi või kohvi piima ja suhkruga. Nagu näha, siis võib juba väga iseenesestmõistetav ja lihtne tööprotsess sisaldada mitmeid otsustuskohti.

Ma olen korduvalt erinevaid analüüse, hankedokumente vms lugedes märganud, kuidas lüüse kasutatakse ebaotstarbekalt ja kohati isegi BPMN notatsiooniga vastuolus. See võib olla tingitud sellest, et BPMN notatsioon näeb ette 6 erinevat tüüpi lüüse (Exclusive Gateway, Inclusive Gateway, Paralleel Gateway, Complex Gateway, Event-based Gateway, Parallel Event-based Gateway) ning selline valikute paljusus võimaldab ka kasutajatel palju vigu teha. Või siis võib lüüside väärkasutuse taga olla ka lihtsalt modelleerija teadmatus, millises olukorras mingit lüüsi kasutada ja millised on lüüside kasutamisega seotud reeglid.  Seepärast mõtlesin teile põgusalt tutvustada mainitud kuute erinevat lüüside tüüpi ja kirja panna mõned elementaarsed soovitused lüüside kasutamise kohta.

Erinevad lüüside tüübid

Välistav lüüs (Exclusive Gateway) on kõige enim kasutatav lüüsi tüüp ja selle kaasabil modelleeritakse selliseid situatsioone, kus protsessi voog saab jätkuda ainult ühes voos (selles, mille tingimus on täidetud). Paralleelne lüüs (Parallel Gateway) on vastupidise loogikaga ehk selle puhul jätkub protsessi voog alati mitmes paralleelses voos. Kaasav lüüs (Inclusive Gateway) on justkui kombinatsioon välistavast ja paralleelsest lüüsist – see võib teatud olukordades (nt. kui on täidetud vaid ühe protsessi voo tingimus) käituda justkui välistav lüüs ja teatud olukordades (nt. kui on täidetud mitu protsessi voo kriteeriumit) justkui paralleelne lüüs.

Kompleksset lüüsi (Complex Gateway) kasutatakse tavaliselt väga vähe, kuna see on mõeldud üpris spetsiifiiste olukordade kajastamiseks.  Näiteks võib kompleksset lüüsi kasutada koondava lüüsina olukorras, kus lüüsi siseneb 5 erinevat voogu ning lüüs aktiveerub (st protsess jätkub) juhul kui lüüsi sisenevast viiest tingimusest on kolm täidetud. Sündmuspõhiseid lüüse kasutatakse kombinatsioonis BPMN-i sündmuste notatsiooniga ning nende idee on selles, et teatud sündmuste realiseerumisel, kas käivitub protsess (juhul kui sündmuspõhist lüüsi kasutatakse protsessi algatamiseks) või jätkub protsessi voog. Tavalist sündmuspõhist lüüsi (Event-based Gateway) kasutatakse juhul kui protsessi võivad käivitada või seda jätkata küll mitu erinevat sündmust aga need ei pea realiseeruma sama-aegselt. Paralleelsest sündmuspõhist lüüsi (Parallel Event-Based Gateway) kasutatakse juhul kui protsessi peavad käivitama või seda jätkama mitu sündmust korraga. See tähendab, et kõik sündmused peavad realiseeruma, enne kui protsess käivitub või jätkub.

Soovitused lüüside kasutamisel

Soovitus nr 1 – Tasakaalusta lüüside kasutamist

Üldiselt on protsesside modelleerimisel reegel, et kui kasutatud mingit tüüpi lüüsi protsessi voogude jagamiseks, siis tuleb sama tüüpi lüüsi kasutada ka protsessi voogude koondamiseks. Miks ma kasutasin sõna üldiselt? Seda sellepärast, et BPMN notatsiooni järgi ei pea tegelikult koondama välistavat lüüsi. Mina koondan enda poolt loodud protsessimudelites isegi välistavat lüüsi, sest siis on kõik lüüsid mul mudelites kasutatud ühtse loogika järgi ja see jällegi aitab protsessist paremini aru saada.

Soovitus nr 2 – Kasuta lüüse asjakohaselt

Olen näinud selliseid protsessimudeleid, kus lüüsi on sisenenud või sealt väljunud ainult üks voog – sellised lüüsid on tegelikult üleliigsed ja see näitab, et lüüse pole kasutatud otstarbekalt. Lüüsi “idee” on kas tekitada ühest voos mitu (ehk voog hargneb) või koondada mitu voogu üheks (ehk voog koondub). Kui mudelitel esineb ebaotstarbekat lüüside kasutamist, siis võib sellised lüüsid mudelilit eemaldada.

Soovitus nr 3 – Minimeeri kaasava lüüsi kasutamist

Protsessides saab väga palju olukordi modelleerida tegelikult kahe enimkasutatava lüüsi – välistava ja paralleelse lüüsi abil. Seega on esimene soovitus alati mõelda, kas saabki äkki hakkama ainult neid kaht tüüpi kasutades. Kui ikkagi ongi keerukam protsess, mis “nõuab” kaasava lüüsi (Inclusive Gateway) kasutamist, siis palun tee endale selgeks, kuidas seda lüüsi õigesti kasutada! Siinkohal soovitus nr 1 – kõikidel kaasavast lüüsist väljuvatel voogudel peab olema peale kirjutatud tingimus, millisel juhul mingi voog realiseerub! Soovitus nr 2 – kaasavast lüüsist väljuvaid voogusid peab alati koondama!

Soovitus nr 4 – Kasuta võimalikult vähe erinevat tüüpi lüüse

Protsesside modelleerimisel võiks järgida seda printsiipi, et kasutatakse nii vähe kui võimalik erinevaid tüüpe lüüse. Modelleerija ei peaks oma oskuste demonstreerimiseks (vahepeal tundub, et just sel eesmärgil on kõikvõimalikke lüüsi tüüpe kasutatud 🙂 ) kasutama protsessimudelil võimalikult palju erinevaid lüüsi tüüpe. Pigem raskendab erinevate lüüsi tüüpide kasutamine protsessist arusaamist. Samas on teatud keerukamad protsessid, mis “nõuavad” ka väga eriliste lüüside või lüüside kombinatsioonide kasutamist. Üldine soovitus – vali erinevaid lüüsi tüüpe sõltuvalt oma mudeli tarbijast! Kui mudeleid tarbib ettevõtte juhtkond, siis tuleks protsessi lihtsustada ja kasutada vajadusel ainult välistavat lüüsi. Kui mudeleid tarbib teine modelleerija, arendaja vms, siis võid kasutada ka keerukamaid lüüse ja nende kombinatsioone.

Soovitus nr 5 – Jaga ja ühenda voogusid ühetaoliselt

Viimane soovitus on selle kohta, et protsessis voogude jagamiseks ja ühendamiseks ei tohiks kasutada sama lüüsi. Kui protsessis esineb olukordi, kus on vaja näiteks kusagilt protsessi teisest kohast voog uuesti protsessi varasemasse kohta suunata ja kohe mingi järgmise tingimuse alusel voogusid jagada, siis tuleks kasutada kahte järjestikust lüüsi.

 

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus. Koolitusel tutvustan juhiseid heade protsessimudelite loomiseks, sh räägime ka lüüsidest ja nendega seotud reeglitest. Samuti proovime enda modelleeritud mudeleid vastavalt toodud soovitustele parandada.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Juhised heade protsessimudelite loomiseks

Protsessimudelite kujundamine ja viimistlemine võib kogu suures modelleerimise “möllus” tunduda triviaalne, kuid tegelikkuses on see väga oluline samm suurendamaks protsessimudelite arusaadavust ja loetavust. Antud blogipostituses tutvustan just protsessimudelite kujundamisega seotud soovitusi.

5 soovitust protsessimudelite kujundamisel

Mäletan väga hästi seda hetke, kui pidin esimest korda protsessimudelit looma – olin küll tutvunud BPMN notatsiooniga ja midagi justkui valmis modelleerinud aga minu mudel ei olnud absoluutselt loetav. Mõni aeg hiljem, kui oma lõputööd kirjutasin, sattusin ühele  äriprotsesside modelleerimise teemalisele artiklile “Guidelines framework for understandable process models” . Nimetatud artikkel oli minu jaoks silmi avav ning sealt sain praktilisi soovitusi, mida siiamaani protsesside mudeldamisel kasutan.

Minimeeri suurust

Mudeli suuruse minimeerimine tähendab seda, et mudeleid proovitakse hoida nii väikestena kui võimalik ja nii suurtena kui vajalik :). See soovitus on miski, mida on lihtne soovitada aga tegelikkuses väga raske teostada. Ma mäletan ülikoolist, et igasuguste mudelite puhul oli selline üldine soovitus, et mudel on loetav siis, kui sisaldab 7-15 elementi. Minu hinnangul 7 elementi (kui nüüd elementideks lugeda BPMN-is vooelemente) on ilmselgelt vähe ja sellega suurt midagi modelleeritud ei saa . Küll aga olen ise jälginud sellist maksimaalset 25 elemendi piiri – kui näen, et tuleb kõvasti rohkem elemente, siis see on indikatsioon, et pean midagi alamprotsessidena kujutama ja detailsemalt järgmistel kihtidel lahti modelleerima.

Hierarhilised struktuurid

Kohe esimese soovituse jätkuks ongi hierarhiliste struktuuride rakendamise soovitus, mis sisuliselt tähendabki seda, et suurte mudelite sisu modelleeritakse erinevatele mudeli “kihtidele”. Eelmises blogipostituses rääkisin “mammut” protsessimudelitest ning seletasin ka lahti täpsemalt hierarhilise modelleerimise loogika. Hierarhilist modelleerimist võib samastada ka misiganes kaardirakenduses erinevate kaardikihtide kuvamise loogikaga. Kui vaatate mõnda kaardirakendust (nt Maa-ameti X-GIS ), siis on näha, et tegelikult koosneb see väga paljudest erinevatest teemakihtidest. Nendes rakendustest on ühele kihile paigutatud ühe temaatikaga seotud info ning järgmisele kihile mõne teise temaatikaga seotud info jne. Kui sellistes kaardirakendustest korraga kõik erinevad teemakihid sisse lülitada, siis sellel kaardil ei oleks enam miski loetav. Seepärast ongi välja toodud eraldi kihtide paneel, mis võimaldab vastavalt kasutaja soovile ja eesmärgile just temale olulist infot sisse ja välja lülitada.

Muud kujunduslikud nüanssid

Sümmetriline modelleerimine tähendab seda, et näiteks lüüside kasutamine peab olema sümmeetriline.  Iga jagava lüüsi kohta on olemas ka koondav lüüs. Tegevused, lüüsid ja sündmused võiksid olla joondatud. Kõik sellised vormistuslikud nüanssid tagavad “puhtama” mudeli, mis omakorda aitab mudelit paremini lugeda.

Samaaegsuse minimeerimine on oluline pigem sellistes mudelites, kus kajastatakse inimeste tegevusi. Tegelikult ju inimesed ei ole võimelised kahte ülesannet täpselt samal ajal tegema. Kui me räägime mudelitest, kus kajastatakse ka süsteemi vaadet, siis seal on täiesti õigustatud samaaegsuse modelleerimine (sh paralleelsete lüüside kasutamine). Tavaliselt ju kasutataksegi erinevaid süsteeme selleks, et saaks inimeste teatud tegevusi efektiivsemaks teha ja samaaegseks viia.

Viimane soovitus on seotud protsessimudelite orientatsiooniga. Justnagu raamatut loeme vasakult paremale, loeme samamoodi ka mudeleid. Seega on soovitus mudeli algussündmused joondada vasakule ja kõik järgnevad vooelemendid paigutada horisontaalselt üksteisele järgnevalt. Protsessi lõppsündmused peaksid sellisel juhul paiknema paremal. Teiste ujumisbasseinidega suhtlevad sõnumivood võiks paigutada vertikaalselt.

Äriprotsessides on lüüsid väga olulised elemendid, sest need muudavad protsessi edasist käekäiku. Seega on oluline, et neid ka õigesti kasutatakse. Seepärast otsustasin soovitused lüüside kasutamise kohta koondada eraldi blogipostitusse, millest saate loodetavasti lugeda paari järgneva nädala jooksul 🙂

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus. Koolitusel tutvustan juhiseid heade protsessimudelite loomiseks ning proovime ka enda modelleeritud mudeleid vastavalt toodud soovitustele parandada.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Miks on äriprotsessi mudeli suurus oluline?

Tihti “kohtan” infosüsteemide dokumentatsioonis või IT lähteülesandes nö “mammut-protsessimudeleid” (st protsessimudeleid, mis ulatuvad üle mitmete lehekülgede ja sisaldavad sadu elemente). Nende  vaatamisel  tõusevad mul ihukarvad püsti ning mõtlen, kellele küll selline mudel mõeldud on ja kes seda  üldse lugeda suudab?  Minul endal tekib automaatselt selliste suurte mudelite puhul tunne, et ma ei tahagi üldse neisse süveneda, kuna ma ei suuda neile peale vaadates hoomata mudeli skoopi. Tänases blogiposituses räägin, miks on oluline jälgida äriprotsessi mudeli suurust ning milliseid nippe saad kasutada normaalse suurusega mudelite modelleerimiseks.

Miks on oluline jälgida äriprotsessi mudeli suurust?

Üks peamine põhjus on see, et mudel oleks loetav ning selle skoop ja loogika oleksid hoomatavad. Mida see tähendab? Kui mudel sisaldab sadu erinevaid elemente, siis selleks, et see ühele lehele (nt. A4 lehele) või läptopi ekraanile ära mahuks, peab seda kõvasti vähendama. See omakorda tähendab seda, et ilma sisse suurendamata ei ole loetavad äriprotsessi algus- ja lõppsündmuste kirjeldused (need on väga olulised mudeli skoobi mõistmisel), samuti ei ole loetavad tegevuste ega ka otsustuskohtade tekstilised kirjeldused. Kui nüüd nimetatud elementide lugemiseks mudelisse sisse suurendada,  siis ei näe enam tervikpilti. Ja kui korraga ei näe ühel lehel või ekraanil kogu mudeli tervikpilti, siis ei ole kerge hoomata mudeli üldist loogikat – nt mitu osapoolt on seotud, kui palju on protsessi voogudes hargnemisi, kui palju esineb protsessis katkestavaid lõppsündmuseid jne.

Tuletan taaskord meelde, et mudel on teatud üldistus reaalsest maailmast ning sinna ei ole mõistlik modelleerida igat pisikest detaili. Mudeleid kasutataksegi selleks, et reaalsest maailmast luua ülevaatepilt, mille eesmärk on anda lugejale tervikvaade. Tervikvaate jaoks ei ole vaja lahti seletada kõiki antud äriprotsessi detaile. Need võivad tulla antud mudelile juurde mõnel teisel kujul – nt tekstilise kirjeldusena, mõne teise täiendava mudelina või hoopis antud mudeli alamprotsessis.

Nii nagu lugeja ei suuda hoomata suurte mudelite loogikat ja skoopi, ei suuda seda tihti teha ka modelleerija ise. Ja kui modelleerijal ei käi oma mudelist nö jõud üle, siis võib see kaasa tuua notatsioonile mittevastavad vigased mudelid. Paljude elementidega mudelite puhul tekib kindlasti rohkem ja keerukamaid otsustuskohti, mille puhul peab jälgima, kas nad on õigesti koondatud. Samuti tekib vajadus mudeli elemente rohkem paigutada, et elemendid omavahel ei kattuks ning mudel säilitaks arusaadavuse. Olen täheldanud suurte mudelite puhul ka ebaühtlast detailsuse astet. See tähendab, et modelleerija on hakanud ülidetailselt modelleerima ja siis poole peal avastanud, et mudel on juba väga suureks läinud. Selle tulemusena üritab ta mudelit kiiresti “koomale tõmmata” ehk hakkab modelleerima üldisema detailsusastmega. Kui modelleerimisel ei ole läbivalt jälgitud sama detailsuse astet, siis see jällegi raskendab mudeli arusaadavust.

Milliste nippide abil piirata äriprotsessi mudeli suurust?

  • Esimene nipp mudeli suuruse piiramiseks on enne joonistamist läbi mõelda ja ära täita äriprotsesside raamistik (sellest kirjutasin täpsemalt siin). Äriprotsesside raamistiku kaudu mõtleb modelleerija läbi konkreetse modelleeritava äriprotsessi skoobi – st sellega paneb ta paika protsessi algus- ja lõppsündmused, seotud osapooled, protsessi eesmärgi jne. Need kõik annavad modelleerijale ette nö piirid, milles ta võiks modelleerimise raames püsida. Kui nüüd modelleerija ei ole neid piire läbi mõelnud, siis võibki juhtuda nii, et ta hakkab modelleerima ning modelleerib ühte mudelisse kogu maailma kokku.
  • Teine nipp on enne joonistamist paika panna see, kelle perspektiivist mudelit joonistatakse. Sellest, et igal äriprotsessil on mitu nägu/perspektiivi, oli täpsemalt juttu siin.  Tihti paneb modelleerimise eesmärk paika selle, kelle perspektiivist on vaja mudelit joonistada. Näiteks kui eesmärk on süsteemi arendamisel süsteemi kasutajaga valideerida, kuidas tema poolt süsteemis läbiviidavad tegevused omavahel seotud on, siis tuleb modelleerida lõppkasutaja perspektiivist. See tähendab, et tuleb rõhku panna detailsemalt lõppkasutaja tegevustele ning vähem detailsemalt süsteemi tegevustele. Kui aga on vaja arendusmeeskonnale selgitada, kuidas süsteem konkreetset äriprotsessi toetama hakkab, siis on mõistlik detailsemalt lahti modelleerida just süsteemi enda tegevused.
  • Kolmas nipp on hierarhiline modelleerimine. Mida see tähendab? See tähendab seda, et modelleerija modelleerib suuri/keerulisi äriprotsesse kihiliselt. Näiteks esimene kiht on kõige üldisem, selle eesmärk on näidata ära konkreetse äriprotsessi skoop. Mudelis kajastatud tegevused on pigem tegevuste grupid (alamprotsessid). Sisuliselt koosnebki esimese taseme protsessimudel algus- ja lõppsündmustest ning erinevatest alamprotsesside järgnevustest. Teine kiht on selline, millel on nt. üks esimese kihi alamprotsess lahti modelleeritud. Teise kihi algus- ja lõppsündmus on konkreetse alamprotsessi lõppsündmus, osapooltena on välja toodud ainult konkreetse alamprotsessi osapooled ning tegevustena ainult konkreetse alamprotsessi tegevused. Kui on tegemist väga keeruliste protsessidega, siis võib olla vajadus modelleerida eraldi detailselt veel kolmas, neljas, viies jne äriprotsessi kiht.

Hierarhiline modelleerimine

Väga hea näide hiearhilisest modelleerimisest on toodud Jakob Freundi ja Bernd Rückeri raamatus “Real Life BPMN”.

Allaolev joonis kajastab värbamise protsessi kõige üldisemat taset. Joonist lugedes on kenasti aru saada, et värbamise protsess algab sellest kui tekib vaba töökoht ning lõppeb sellega, kui vaba töökoht on täidetud. Näeme, et nimetatud protsessiga on seotud firmasiseselt kaks osakonda – HR ja värbamise osakond. Ning seotud on üks fimaväline osapool, nimelt kandideerija. Samuti näeme, et enamus tegevusi on protsessis modelleeritud alamprotsessidena (tegevustel on kastis pluss märk) ning antud joonisel ei ole nende alamprotsesside loogikat detailsemalt lahti modelleeritud.

Allikas: “Real-Life BPMN” Jakob Freund, Bernd Rücker

Allolev joonis kajastab värbamise protsessi natuke detailsemat voogu. Iga osapool on “tõstetud” oma ujumisbasseini ja seetõttu on neil igalühel oma algus- ja lõppsündmus. Osapoolte vahel on näidatud detailsemalt info liikumist sõnumivoogude vahendusel. Samuti on sisse toodud üks otsustuskoht – kas kandideerimise taotluse laekus?

Allikas: “Real-Life BPMN” Jakob Freund, Bernd Rücker

Allolevalt jooniselt näed sama protsessi, mis on veelgi detailsemalt lahti modelleeritud. Sellelt on näha, et osapooltena on sisse toodud infosüsteem, mis värbamise protsessi toetab ning välja jäetud kandideerija. Seotud osapoolte ujumisbasseinides on täpsustatud konkreetsemad ujumisrajad. Protsessis esineb juba rohkem erinevaid otsustuskohti ning paljud tegevused on lahti modelleeritud (st puudub viide alamprotsessile).

Allikas: “Real-Life BPMN” Jakob Freund, Bernd Rücker

Pikk jutt lühidalt ja konkreetselt – palun mõtle enne modelleerimist läbi, kes hakkavad sinu mudeleid tarbima, sellest lähtuvalt pane paika oma mudeli skoop ning modelleeri hierarhiliselt. Sellega vähendad tõenäosust, et modelleerid mammut-protsessimudelit, mida keegi ei suuda lugeda.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus. Koolitusel tutvustan juhiseid heade protsessimudelite loomiseks, sh. räägin ka hierarhilise modelleerimise olulisusest.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Ühe äriprotsessi mitu nägu

Tänases blogipostituses tahan põgusalt arutleda äriprotsesside perspektiivi teemal. Olen oma koolitustel lasknud osalejatel eri gruppides sama protsessi modelleerida ning alati on tulemuseks erinevad protsessijoonised. Kuidas nii? See on sellepärast, et eri grupid joonistavad sama protsessi erinevate osapoolte perspektiivist. Käesolevas postituses tahangi rõhutada, et lisaks äriprotsesside raamistiku paikapanemisele (kes ei mäleta, siis sellest rääkisin siin postituses) on vaja enne modelleerimist läbi mõelda ka see, kelle vaatest või perspektiivist antud protsessi modelleeritakse.

Sama protsessi mitu nägu

Perspektiiv määrab ära protsessi fookuse ning annab juhise, kes on protsessis nö peamine aktor ning kelle tegevustele rohkem keskenduda. See, milline perspektiiv valida, sõltub omakorda sellest, mida tahetakse protsessimudeliga saavutada. Näiteks antud postituses kasutatud veebitellimuste protsessi puhul võib olla kliendi vaatest joonistatud protsessi eesmärk jõuda arusaamisele, kuidas klient veebipoega suhtleb, et osata selle pinnalt parandada kliendikogemust või kliendi teekonda antud protsessis. Süsteemi (veebipood, majandustarkavara, postiautomaat) perspektiivist joonistatud protsess võib teenida aga hoopis teistsuguseid eesmärke – seda saab kasutada veebipoe ja majandustarkvara kasutusjuhendis, see võib samuti olla alus süsteemi (veebipood ja majandustarkavara) efektiivistamisel või siis hoopis osa süsteemi arenduse lähteülesandest.

Järgnevalt olen lahti modelleerinud veebitellimuste protsessi kahest erinevast vaatest:

  • Esimene joonis kajastab veebitellimuse protsessi kliendi perspektiivist;
  • Teine joonis kajastab veebitellimuse protsessi süsteemi perspektiivist.

Veebitellimuste protsess kliendi vaatest

Esimese protsessi puhul on näha, et kliendi ujumisrajas toodud tegevusi on rohkem kui teises protsessis st. et teatud tegevuste järgnevus ja loogika on detailsemalt lahti modelleeritud kui teises protsessis. Samuti on kliendiga suhtleva osapoolena näidatud veebipoodi mitte kogu süsteemi (veebipood, majandustarkavara ja pakiautomaat), kuna veebipood on see keskkond, millega klient antud protsessis enim kokkupuudet omab. Erinevus teise modelleeritud protsessiga on veel see, et lahti on modelleeritud ka sellised tegevused nagu “toodet pakkuva firma veebilehele minemine” ja “veebilehelt toodete otsimine”, kuna klienditeekonna vaatest on need olulised sammud.

Joonis 1. Veebitellimuste protsess kliendi vaatest

Veebitellimuste protsess süsteemi vaatest

Teise protsessi puhul on näha, et süsteemi basseinis on eraldatud ujumisradadena süsteemi komponendid – pakiautomaat, veebipood ja majandustarkvara. Süsteemi tegevusi on püütud detailsemalt lahti modelleerida ning neid ka vastava komponendi ujumisrajale paigutada. Samas on osasid kliendi tegevusi kajastatud pigem lakooniliselt – nt on lihtsalt näidatud, et kliendile saadetakse arve, kuid pole kliendi poolel lahti modelleeritud arve tasumise tegevust. Nö uus info, mis “koorub välja” teiselt jooniselt on see, et kliendi tellitud kaupa ei pruugigi olla selles laos, kust veebipood oma tellimusi välja saadab, vaid kauba peab näiteks mõnest poest veel lattu tellima. Samuti on detailsemalt lahti modelleeritud toote kättesaamise tegevus. Jooniselt on näha, et tegelikult on kliendil võimalik kaubale ise poodi järgi minna või siis oma tellimus pakiautomaadist kätte saada.

Joonis 2. Veebitellimuste protsess süsteemi vaatest

Nagu nägime siis aitab äriprotsessi perspektiivi valimine ja äriprotsessi eesmärgi läbimõtlemine, teha otsust, mida protsessimudelil millise detailsusega kajastada. Mudelite loomise juures on alati kõige keerulisem otsustada, millise detailsusega modelleerida! Tasub silmas pidada, et mudel on alati reaalse maailma tõlgendus või lihtsustus ning teatavasti läheb tõlkes ka infot kaduma. Seega ei ole mudelile mõistlik (ja tihti ka võimalik!) panna kogu reaalse maailma infot. Paratamatult peab tegema otsuse, mis on antud perspektiivist ja eesmärgist lähtuvalt kõige optimaalsem.

The same process may look completely different for each participant, and how it looks depends on its perspective. This results in different process models” Jakob Freund, Bernd Rücker (allikas “Real life BPMN“)

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus. Äriprotsessi perspektiivi küsimuse “otsa põrkame” kohe kui hakkame koolitusel ka ise äriprotsesse kaardistama. Koolituse käigus saamegi arutada sama protsessi erinevaid perspektiive ja seda, kuidas see mõjutab meie protsessimudeli detailsust.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Protsessi parendamine ehk kuidas AS-IS protsessi põhjal TO-BE protsessi disainida?

Viimases blogipostituses tutvustasin äriprotsesside väärtuspõhist analüüsi ja seda, kuidas leida protsessist üles väärtusetud sammud, mis tuleks kõrvaldada. Seda võib käsitleda ühe meetodina, kuidas saab olemasolevat protsessi parendada. Tänases blogipostituses tahan teile tutvustada ühte laiapõhjalisemat protsesside parendamise metoodikat, mida mina isiklikult oma töös väga palju kasutan. See lähenemine pärineb Susan Page-i raamatust “The Power of Business Process Improvement” ning seal on seda tabavalt nimetatud “Improvement Technique Wheel“, mida mina siin postituses nimetan edaspidi protsesside parendamise tsükliks.

Sõna tsükkel viitab iteratiivsele tegevusele, mis omakorda viitab tegevuste korduvale läbimisele. Protsesside parendamine ongi oma olemuselt korduv tegevus, mida tuleks teatud aja tagant uuesti ja uuesti läbida.

Mis on protsesside parendamise tsükkel?

Protsesside parendamise tsükkel on oma olemuselt sammude jada, mis on organiseeritud ringi kujuliselt ning mis võimaldab viimase sammu lõppemisel alustada uuesti esimesest sammust. See sisaldab kuute erinevat sammu ning igas sammus proovib protsessi analüüsiv isik leida kontrollküsimuste või muude meetodite abil protsessist üles parendamist vajavad kohad.

Veel enne kui läheme iga sammu kontrollküsimuste ja meetodite juurde, tahan üle rõhutada, et protsesside parendamise tsüklit soovitatakse alustada alati bürokraatia eemaldamise/vähendamise sammust! Miks nii? Seda sellepärast, et nö viimane samm selles tsüklis on automatiseerimine ning seda tuleks teha kõige lõpus. Ei ole ju mõtet automatiseerida ebaratsionaalset protsessi.

Väga tavapärane on see, et soovitakse kiiresti mingit protsessi parendada ning arvatakse, et kui arendada IT-süsteem, siis see justkui  võluväel aitab protsessi paremaks teha. Kui ikkagi enne pole protsessi korralikult analüüsitud ja protsessis esineb nö väärtusetuid samme või protsess on väga-väga keeruline, siis ei aita kahjuks arendatav süsteem mitte kuidagi protsessi parendada. Sellisel juhul raisatakse palju raha ja automatiseeritakse lihtsalt rumalusi. Väga hästi näitlikustab seda ka Bill Gatesi järgnev tsitaat “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.” 

 

Samm 1 – eemalda/vähenda bürokraatiat

Kindlasti tekitab mõiste “bürokraatia” erinevates inimestes väga vastakaid tundeid, kuna neil võib olla sellest erinev arusaam. Antud juhul mõtlen mina bürokraatia all protsessis esinevaid nö “igaks juhuks” tegevusi, mida ei ole otseselt vaja teha protsessi enda eesmärgi ja protsessi kliendi vaatest ning mis võivad olla protsessile lisatud näiteks mingi täiendava dokumenteerimise või aruandluse eesmärgil.

Selleks, et leida olemasolevast äriprotsessit üles sammud, mis esinevad seal bürokraatia tõttu, võib kasutada järgnevaid kontrollküsimusi:

  • Kui palju esineb protsessis selliseid kohti, kus teatud isikud peavad andma kinnituse, et töö saaks jätkuda? Juhul kui selliseid kohti esineb palju, siis tuleb analüüsida, miks neid nii palju esineb? Siin saab väga hästi kasutada 5 Whys meetodit – https://kanbanize.com/lean-management/improvement/5-whys-analysis-tool . Kui olete tuvastanud kinnituste rohkuse põhjuse, siis järgmine samm on proovida protsessis nende arvu vähendada.
  • Kas protsessis tehakse otsuseid õige koha peal?
  • Kas protsessis genereeritakse ebavajalikku paberitööd?
  • Kas protsessis osalevad inimesed saavad neile vajalikku informatsiooni?
  • Kas me teame, kas üldse ja mida inimesed tegelikult teevad neile saadetud infoga? Kuidas nad seda infot kasutavad?
  • Kas keegi loeb/vaatab aruandeid/raporteid, mida protsessi raames toodetakse? Aeg-ajalt tuleb ette ka olukordi, kus saadetakse kellelegi mingit infot või aruandeid/raporteid, kuna seda on alati nii tehtud aga tegelikkuses adressaat seda infot oma töös ei kasuta.
  • Kas esineb olukordi, kus üks inimene kontrollib teise inimese tööd? Kui esineb, siis miks ta seda teeb? Kas see nõue tuleneb mingist auditeerimise reeglist või lihtsalt ei usaldata teise töö tulemit?
  • Kas protsessis esineb mittevajalikke reegleid? Tuleks otsida selliseid reegleid, mis piiravad protsessi läbimist.
  • Mis juhtub, kui töötaja teeb protsessis vea?

Bürokraatia vähendamiseks on väga hea kasutada SALT kriteeriumit.

  • S (Statutory) – tegevus toetab seadusandluse loomist või riiklikku seisukohta
  • A (Audit) – tegevus on vajalik protsessi vastavuse ja täpsuse hindamiseks (auditeerimise eesmärgid)
  • L (Legal) – tegevus toetab seaduse täitmist
  • T (Tax) – tegevus on seotud riikliku maksupoliitikaga

Kui tegevus vastab kõigile SALT kriteeriumi punktidele, siis selle peaks protsessis säilitama. Samas puhtalt auditi tegevuste tõttu ei ole mõtet ebaefektiivseid tegevusi protsessi alles jätta.

Samm 2 – eemalda väheväärtuslikud tegevused

Selles sammus viiaks sisuliselt läbi äriprotsessi väärtuspõhine analüüs, millest kirjutasin pikemalt oma eelmises blogipostituses (loe täpsemalt sellest postitusest). Ehk eemaldatakse protsessist kogu “prügi” ja jäetakse alles ainult väärtuslikud tegevused. Rõhutan veelkord üle, et protsessi tegevuste väärtuse hindamisel on väga heaks sisendiks äriprotsesside raamistik, kuhu kogusime kokku protsessi kliendi ja seotud osapoolte soovid ning ootused. Seega soovitan soojalt seda lähenemist kasutada! Kui sa enam ei mäleta, kuidas koostada äriprotsesside raamistikku, siis loe sellest täpsemalt siit.

Samm 3 – eemalda dubleerivad tegevused ja/või andmed

Dubleerimine esineb siis, kui mitmed protsessiga seotud osapooled ei ole omavahel integreeritud (st et nad ei koordineeri omavahel seotud tegevusi, ei suhtle omavahel jne) ja erinevad osapooled viivad läbi täpselt samu tegevusi (nt. sisestavad täpselt samu andmeid kuhugi andmebaasi, genereerivad täpselt samu raporteid, koguvad välistelt osapooltelt täpselt samu andmeid jne). Inglise keeles on selliste isolatsioonis funktsioneerivate üksuste kohta väga hea väljend – silos. Organisatsioonides, kus sellised isoleeritud silod esinevad, on tavapärased olukorrad, kus samadest andmetest esinevad kergete erinevustega eri versioonid ning keegi ei tea enam, milline on see kõige õigem andmestik (nö single source of data). Kaheldava kvaliteediga andmete pealt sünnivad ka kaheldava väärtusega otsused, seega võivad  probleemid andmete ühtsuse ja kvaliteediga ettevõtetele/asutustele väga kalliks maksma minna!

Selleks, et leida äriprotsessist üles dubleerimist, otsi kohti, kus saaks:

  • Luua tegevuste tarbeks ühtse andmeallika (single source of data);
  • Elimineerida mitme töötaja sama töö tegemist;
  • Elimineerida kohad, kus toimub dubleeriv andmesisestus ja andmete haldus;
  • Minimeerida dokumentide põhiste lähenemist, hoiustamist.

Samm 4 – lihtsusta protsessi

Simplicity is the key to happiness in the modern world” Dalai Lama. Väga tabavalt öeldud:) Mida lihtsam on protsess, seda paremini saavad protsessiga seotud osapooled aru, mida neilt oodatakse ning kui seotud osapooltel on arusaam, mida nad tegema peavad, seda vähem esineb ka protsessis vigu/seisakuid ja dubleerivaid tegevusi. Samas lihtne ei tähenda alati seda, et selleni oleks kerge jõuda! Ka tarkavaraarenduses on nii, et pealtnäha väga lihtne ja intuitiivne lahendus võib tähendada seda, et selle saavutamiseks on väga palju vaeva nähtud – nt korduvalt lihtsustatud protsessi, mida antud tarkvaralahendus peaks toetama, korduvalt valminud lahenduse kasutatavust testitud, tagasisidest lähtuvalt korduvalt lahendust ümber tehtud jne.

Selleks, et äriprotsessi lihtsustada, võib kasutada järgnevaid kontrollküsimusi:

  • Kas on võimalik lihtsustada protsessi mõnda sammu?
  • Kas on võimalik lihtsustada mõnda andmesisestuse vormi?
  • Kui palju e-maile saadame mingis protessi sammus? Kas neid on vaja nii palju saata? Kas saaks vajaliku info kuidagi operatiivsemalt adressaadini toimetada?
  • Kust otsitakse/saadakse infot, et täita protsessis mingit kindlat sammu?
  • Kas protsessis esineb takistusi? Kui jah, siis millest need tingitud on?
  • Kas protsessis esineb ebavajalikke tööde üleandmisi?
  • Kas protsessis kasutatavat vormi/malli saab struktureerida ja/või standardiseerida?
  • Kas on teada, kui palju vigu protsessis tehakse? Kui tehakse palju vigu, siis mis on selle põhjus?
  • Kas protsessist saab teatud tegevused eemaldada või teiste tegevustega kombineerida?
  • Kas protsessi teatud tegevuste täitmiseks peab ühendust võtma mõne teise osapoolega?
  • Kas protsessis osalejad saavad üldse aru protsessist ja sellest, mida neilt oodatakse?
  • Kuidas kasutatakse protsessis andmeid ja raporteid?

Protsessi lihtsustamisel võiks jälgida KISS (Keep It Simple, Stupid) printsiipi, mille kohaselt peaks protsessi lihtsustama isegi niipalju, et see tunduks  rumalana 🙂

Samm 5 – vähenda protsessi tsükli aega

Protsessi tsükli aeg on kogu protsessi läbimiseks kuluv aeg. Oluline on  lisaks tegevuse enda kestvusele/ajale, sisse arvestada ka ooteajad tegevuste vahel. Tavaliselt ongi protsessides igasugused ooteajad erinevate tegevuste vahel või erinevatele osapooltele tööde üleandmiste vahel selleks “kurja juureks”, mis tingivad protsesside venimise ja pikad tsükli ajad.

Selleks, et vähendada äriprotsessi tsükli aega, võib kasutada järgnevaid kontrollküsimusi:

  • Kas protsessis on võimalik vähendada tööde üleandmisi?
  • Kui kaua peab protsessis erinevate tegevuste vahel ootama? Kui palju aega kulub protsessis tööde üleandmisele ühelt osapoolelt teisele?
  • Kas väärtuslikke tegevusi on võimalik optimeerida?
  • Kas on võimalik eemaldada tegevused, mis ei lisa väärtust?
  • Kas on võimalik vähendada ajamahukate tegevuste kestvust või eemaldada need protsessist?
  • Kas on võimalik tegevusi paralleeliseerida?
  • Kas on võimalik tegevusi kombineerida? Näiteks koondada loogilised tegevused kokku nii, et nende koos läbimine tooks kaasa ajaefektiivsust.

Samm 6 – automatiseeri

Lõpuks jõudsimegi kuuenda sammu ehk automatiseerimise juurde 🙂 Siin sammus on tehnoloogial ja IT arendustel väga oluline roll. Aga veel enne kui, hakkate suure hooga uusi IT-lahendusi tellima ja arendama, tasuks analüüsida, kas juba ettevõttes/asutuses kasutusel olevatest tehnoloogiatest/töövahenditest saab midagi automatiseerimise eesmärgil kasutada? Tavapäraselt on ettevõtetes/asutustes olemas nt. standardsed kontoritöö vahendid (nt. Ms Excel, Ms Access jne), mis võivad väiksemate automatiseerimise vajaduste puhul vägagi sobivad olla. Ettevõttes juba kasutuses oleva tehnoloogia valimise eeliseks on see, et ettevõttel on juba antud tehnoloogiaga kogemusi ning tehnoloogia juurutamine ja kasutusele võtmine on kiirem.

Teine perspektiiv, mida uute IT-lahenduste arendamisel alati kaaluda, on see, kui suur grupp inimesi antud IT-lahendust kasutama hakkaks? IT-lahendusse investeeringu tasuvuse vaatest on vahe, kas seda lahendust hakkab kasutama 2 inimest (sellisel juhul võib investeeringu tasuvusperiood olla väga pikk!) või 50 inimest. Kui planeeritava IT-lahenduse sihtgrupp on väike, siis võiks protsessi terviku või protsessi konkreetse sammu automatiseerimist kaaluda ikkagi olemasolevate töövahendite/tehnoloogiate abil.

 

Postituses kasutatud allikad

  • The Power of Business Process Improvement” Susan Page
  • https://kanbanize.com/lean-management/improvement/5-whys-analysis-tool

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus. Nimetatud koolitusel tutvustan ka protsesside parendamise tsüklit, toon konkreetseid näiteid projektidest ning katsetame näidisprotsessi peal protsesside parendamise tsükli metoodikat.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

Äriprotsesside väärtuspõhine analüüs

Oma kõige esimeses blogipostituses lubasin eraldi  kirjutada väärtusetu (Non-value adding) ja väärtust loova (Value-adding) töö kohta. Seega antud blogipostitus tutvustab, mis on väärtuspõhine analüüs, käsitleb väärtust loova ja väärtusetu töö olemust ning toob välja nende olulisuse äriprotsesside parendamisel.

Olen oma töös alati instiktiivselt lähtunud sellest, et iga tegevuse puhul tuleb aru saada, miks ja kelle jaoks seda tehakse. Sellest lähtuvalt olen paika pannud tegevuse fookuse selliselt, et see tegevuse tulemit tarbivale osapoolele võimalikult palju väärtust pakuks. Minu jaoks on selline mõtteviis olnud väga iseenesestmõistetav ja mul polnud pikalt aimugi, et Lean Six-Sigma väärtuspõhise analüüsi (Value Added Analysis) metoodika eesmärk on sarnane. Alates hetkest kui meile ülikoolis Lean Six-Sigma väärtuspõhise analüüsi metoodikat tutvustati, olen olnud selle suur fänn ja see on üks minu lemmikmetoodikaid ka äriprotsesside parendamisel.

Mis on väärtusetu töö?

Väärtusetu ja väärtust loova töö kontseptsioon pärineb Lean Six-Sigma väärtuspõhise analüüsi metoodikast (Value Added Analysis) – https://leanopedia.com/what-is-value-added-analysis/ . Selle metoodika järgi esineb igas äriprotsessis tegevusi või konkreetses tegevuses samme, mis ei loo väärtust seda protsessi/tegevust tarbivale lõppkliendile. Selliseid tegevusi nimetatakse väärtusetuteks tegevusteks või tööks.

Näiteks tööaja raporteerimise protsessi kliendiks on tavaliselt töötaja ülemus, kes tahab teada, milliste tegevuste peale tema töötaja tööaeg kulub. Arendusprojektides võib tööaja raportreerimise protsessi kliendiks olla ka projektijuht, kes saab raporteeritud tundide põhjal indikatsiooni, kui kaugel projekti tegevustega ollakse ja kui palju tunde on kulunud võrreldes planeeritud tundidega.

Väärtuspõhine analüüs on metoodika, mis aitab äriprotsessis tuvastada kliendi jaoks väärtusetuid samme. Samm võib tähendada mingit konkreetset ülesannet protsessis või tööde üleandmise viisi. Väärtuspõhine analüüs koosneb kahest osast – väärtuse klassifitseerimisest ja üleliigse eemaldamisest.

Kuidas äriprotsessides väärtuspõhist analüüsi kasutada?

Äriprotsessidest väärtusetu töö tuvastamine ja eemaldamine on väga süsteemne tegevus – äriprotsessi igat tegevust ja isegi konkreetse tegevuse samme analüüsitakse üksipulgi läbi. Analüüsi põhjal määratakse, kas konkreetne samm loob protsessi eesmärgi täitmisel mingit väärtust või mitte. Selle tegevuse tulemusel määratakse igale sammule üks järgnevast kolmest tunnusest:

  • Väärtust loov tegevus (Value-adding (VA))
  • Ärile väärtust loov tegevus (Business value-adding (BVA))
  • Väärtusetu tegevus (Non-value adding (NVA))

Üldiselt võib väärtusetud tegevused äriprotsessist rahumeeli eemaldada, kuid on üks täiendav kriteerium, mida kaaluda! Lõppkliendile väärtusetute tegevuste puhul tuleks veel valideerida, äkki on tegemist tegevusega, mis loob hoopis ettevõttele endale väärtust. Selliseid tegevusi nimetatakse ärile väärtust loovateks tegevusteks ning nende puhul tuleb kriitiliselt hinnata, kui olulised need ärile ikkagi on.  Kui leitakse, et tegevus on ärile oluline selleks, et täita näiteks ettevõtte strateegilisi eesmärke, siis ei saa neid tegevusi äriprotsessist eemaldada. Sellised tegevused tuleks võimaluse korral automatiseerida.

Näide ärile väärtust loovast tegevusest

Toon ühe näite arendusprojektides tööaja raporteerimise kohta. Arendusprojektides kasutatakse aeg-materjali (see tähendab, et klient ostab arendusfirmalt kokkulepitud tunnihinna alusel arenduse ressurssi) põhistest projektides laialdselt JIRA tarkvara, mis võimaldab iga tööülesande juurde logida sellele kulunud aega. JIRA-sse logitud tundide põhjal esitab arendusfirma kliendile teatud ajaperioodil kulunud tundide eest arve.

Tavapäraselt on arendusfirmades olemas veel lisaks enda tööaja logimise süsteemid, mis võivad olla integreeritud näiteks ettevõtte palgaarvestuse süsteemiga või ressursside planeerimise süsteemiga (ERP). Selline dubleerivate tööaja logimise süsteemide olemasolu tähendab töötaja jaoks tihti dubleerivat ajalogimist mõlemasse süsteemi ning töö raporteerimise protsessi vaatest ka topelt ajakulu. Arendust telliva lõppkliendi vaatest ei oma ettevõtte ajalogimise süsteemi tööaja sisestamise tegevus mitte mingisugust väärtust, samas on see samm oluline ettevõtte enda jaoks. Ja seda selleks, et saada aru, kui palju töötaja on teatud perioodil panustanud, et talle maksta väärilist töötasu (sh näiteks tasu võimalike ületundide eest) või osata järgmisteks kuudeks/kvartaliks planeerida antud töötaja ressurssi.

Seega võib öelda, et ettevõtte ajalogimise süsteemi tööaja sisestamine on  ärile väärtust loov tegevus ja seega ei saa seda tegevust äriprotsessist lihtsalt eemalda. Küll aga on vaja otsida võimalusi selle tegevuse ajakulu minimeerimiseks töötaja jaoks – näiteks ettevõtte ajalogimise süsteemi ja JIRA süsteemi integreerimine vms.

Kuidas ma tean, millise tegevuse eest on klient nõus maksma?

Siin tuleb mängu äriprotsesside raamistiku  (täpsemalt loe raamistiku kohta sellest postitusest ) olulisus. Äriprotsesside raamistiku puhul rääkisime, et iga äriprotsessi puhul tuleb lisaks äriprotsessi enda tegevustele, tuvastada ka konkreetse äriprotsessi klient ja tema ootused. Kui iga äriprotsessi kohta on selle kliendi ootused teada, siis nendest lähtuvalt tulebki hakata tegevusi märgistama, kas väärtust loovateks, ärile väärtust loovateks või väärtusetuteks tegevusteks.

Tuues paralleeli tööaja raporteerimise protsessiga, siis sellel protsessil on toodud näites kaks klienti – töötaja ülemus ja projektijuht, kelle projektis antud töötaja tööd teeb. Kui esimese kliendi (ülemuse) puhul on lisaks tundide logimisele oluline ka võimalikult detailne tööülesannete kirjeldus, mida nende tundide raames tehti. Siis teise kliendi (projektijuhi) jaoks on oluline info, kui suure hulga tööst sai töötaja raporteeritud tundide jooksul tehtud ning kas on reaalne, et töö saab tehtud planeeritud tundide raames. Nendest kliendi ootustest lähtuvalt tuleb analüüsida ka olemasoleva tööaja raporteerimise protsessi tegevusi – näiteks, kas äriprotsess sisaldab tegevusi, mis ei täida antud ootusi? Või kuidas saab olemasolevas äriprotsessis raporteerimise samme parendada nii, et äriprotsessi kliendi ootused saaksid täidetud aga samas ei kaasneks sellega lisapingutust töötajale, kes peab tööaega raporteerima.

Lean filosoofia kohaselt esineb tootmises 8 tüüpi raiskamist, mis tingib äriprotsessides ebaefektiivsuse. Inglise keeles nimetatakse raiskamist väga tabavalt terminiga “waste“. Tootmise kontekstis raiskamise kohta saad lugeda näiteks siit – https://www.sixsigmadaily.com/what-is-value-add-vs-non-value-add/ . Olen järgneval joonisel proovinud oma tähelepanekute pinnalt raiskamise tüüpe üldistada ka näiteks IT süsteemidega seotud äriprotsessidele, seetõttu ei ühti need üks-ühele tootmise kontekstis välja tooduga.

Miks on oluline mõista väärtust loova ja väärtusetu töö olemust?

Nagu juba mainisin, on väärtuspõhine analüüs üks oluline metoodika, mida kasutatakse äriprotsesside tõhustamisel/parendamisel.  Palju olulisem on aga seos väärtust loova töö ja töötaja motivatsiooni vahel. Võin julgelt öelda, et enamuse töötajate jaoks on väga oluline, et see töö, kuhu ta igapäevaelt oma energiat/loovust/ideid panustab, oleks kellegi jaoks väärtuslik! Vähesed teevad tööd lihtsalt töö tegemise pärast ning pigem tahavad aru saada, kuidas nemad saavad panustada ettevõtte/meeskonna eesmärkide täitmisesse. Seega äriprotsessi tasandil väärtusetu töö ja tegevuste välja selgitamine, aitab tõsta ka töötajate motivatsiooni.  Sellise tegevuse tulemusel võib selguda, et töötajale enne väärtusetuna tundunud töö, saab uue tähenduse. Ja seda seetõttu, et ta saab aru, kellele ja millist väärtust ta oma tegevusega loob. Või saab tõsta töötajate motivatsiooni sellega, et igasugused rutiinsed lõppkliendile väärtusetud tööd protsessist eemaldada või automatiseerida.

Postituses kasutatud allikad

  • Fundamentals of Business Process Management” Marlon Dumas et al.
  • https://leanopedia.com/what-is-value-added-analysis/
  • https://www.sixsigmadaily.com/what-is-value-add-vs-non-value-add/

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus. Nimetatud koolitusel teeme konkreetse äriprotsessi peal läbi ka väärtuspõhise analüüsi ehk protsessist väärtust loovate ja väärtusetute tegevuste tuvastamise.

Kui sind kõnetavad teemad, mida oma blogis kajastan, siis võta minuga julgelt ühendust!

 

 

 

 

 

BPMN – mis see on ja kuidas seda modelleerimisel kasutada?

Eelmises postituses küll viitasin, et juttu tuleb ka DMN-st (Decision Model and Notation), kuid siiski otsustasin selle kohta täitsa eraldiseisva postituse teha. Seega antud blogipostituses annan ülevaate enamlevinud äriprotsesside modelleerimise notatsioonist BPMN-ist (Business Process Modelling Notation) ja toon välja juhiseid, kuidas seda notatsiooni kõige paremini kasutada.

BPMN

BPMN (Business Process Modelling Notation) on graafiline notatsioon äriprotsesside modelleerimiseks. BPMN on universaalne keel, mis on ärilisele kasutajale väga intuitiivne, samas sellest saab aru ka IT.  Seega võib öelda, et see on kommunikatsioonivahendiks äriprotsesside disaini ja rakendamise vahel. “BPMN provides businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner.” (Business Process Model and Notation v 2.0). Kõige põhjalikuma ülevaate BPMN notatsioonist, saab Object Management Group (OMG) poolt koostatud juhisest – https://www.omg.org/spec/BPMN/2.0/PDF . Kel jaksu võib ka seda 538 leheküljelist materjali otsast lugema hakata aga esimeste mudelite joonistamiseks ja nendest arusaamiseks pole kindlasti vaja kohe nii mahukat materjali läbi töötada.

BPMN-i baaselemendid

Selleks, et BPMN-is modelleeritud mudeleid mõista, on kõigepealt vaja aru saada BPMN-i baaselementidest. Järgnevatel joonistel olen välja toonud peamised elemendid, mille tundmisest piisab, et täiesti korralikke protsesse joonistada.

Mõned juhised heade protsessimudelite loomiseks

Minimeeri mudeli suurust

Modelleerija eesmärk peaks olema hoida protsessimudeleid nii väikestena kui võimalik. Suured mudelid ei ole hästi hoomatavad ja nende lugemine on väga kohmakas st. nõuab dokumendis/programmis korduvat sisse ja väljasuumimist. Üks nipp mudeli suuruse reguleerimiseks on kasutada alamprotsesse – kui on näha, et mudel läheb liiga suureks, leia mudelilt loogilised tükid, mida on mõistlik eraldi alamprotsessidena modelleerida. See võimaldab nö peaprotsessist eemaldada need elemendid, mis tõsteti alamprotsessi ja peaprotsessi lisada ainult viite alamprotsessile.

Jaota ja ühenda voogusid ühetaoliselt

See lüüs, mida kasutati voogude jagamiseks, peaks koonduvaid vooge ka ühendama. Näiteks kui mingis tööprotsessis jagunevad tööd kaheks paralleelseks tegevuste jadaks, mis hiljem jälle ühinevad (ehk mõlema töövoo puhul on vaja läbi täpselt samu tegevusi), siis peab enne mainitud paralleelset tegevuste jadat kasutama nö paralleellüüsi ning töövoogude uuesti ühinemisel samuti kasutama paralleellüüsi.

Töövoo lahknevusel kasutatavad välistavad lüüsid (nn XOR Gateway) peavad sisaldama küsilauset

Näiteks mingi kauba tellimise protsessis lahkneb töövoog kohas, kus on kontrollitakse, kas kaup on laos või mitte. Nimetatud lahknemiskohal kasutatakse välistavat lüüsi koos küsilausega “Kas kaup on laos?” Juhul kui kaup on laos, siis jätkub tööprotsess ühtmoodi tegevustega ja kui kaupa ei ole laos, siis teistmoodi tegevustega.

Väldi mudelites omavahel kattuvaid elemente

Modelleerimisel jälgi, et tegevuste kastid või lüüsid ei paikneks üksteise peal või et voogusid kirjeldavad jooned oleksid omavahel eristatavad ja arusaadavad. Omast kogemusest võin öelda, mudeli korrastamine ehk mudeli elementide kattuvuste eemaldamine nõuab modelleerimise protsessis märkimisväärset tööaega.

Kasuta võimalikult vähe erinevat tüüpi lüüse

Väga paljude eri tüüpi lüüside (välistav lüüs, paralleellüüs, sündmuspõhine lüüs, kompleksne lüüs, kaasav lüüs jne) vähendab protsessist arusaamist. Mina kasutan enamjaolt kolme eri tüüpi lüüsi – välistavat lüüsi (Exclusive or XOR Gateway), paraleellüüsi (Parallel Gateway), kaasavat lüüsi (Inclusive Gateway).

Lähtu modelleerimisel ühetaolisuse printsiibist
  • Kõikidel tegevustel peavad olema samas stiilis kirjeldused – kirjelduste lisamisel on hea tava, et nad on samas stiilis ka sõnastatud. Mitte nii, et üks tegevus on “Tellimuse tegemine” ja teine on näiteks “Arve väljastus”;
  • Kasuta basseine  (Pools) seotud protsesside kirjeldamisel ühetaoliselt – basseinid on mõeldud ühe konkreetse protsessi kujutamiseks. Kui sa ühe protsessi puhul kirjutad basseini nimetusse protsessi nime ja teises protsessis hoopis asutuse nime, siis see ei ole ühetaoline kasutamine ja raskendab mudelitest arusaamist;
  • Kasuta radu (Lanes) seotud protsesside kirjeldamisel ühetaoliselt  – rajad on mõeldud antud protsessiga seotud ospoolte (üksuste, osakondade, rollide) kujutamiseks. Kui sa ühe protsessi puhul kirjutad radade nimetusse nt konkreetsete rollide nimed ja teises seotud protsessis aga hoopis üksuse nime, siis see ei ole ühetaoline kasutamine ja raskendab mudelist arusaamist.
  • Kasuta protsessi algussündmuseid (Start event) ühetaoliselt – üldiselt on igal protsessil ainult üks algussündmus. Kui on siiski vaja lisada ka teist protsessi “käivitajat”, siis kaalu sündmuspõhise alguslüüsi (Event-based start gateway) kasutamist.
  • Kasuta protsessi lõppsündmuseid (End event) ühetaoliselt – protsessi katkemiste puhul kasuta lõppsündmuse elemendi sees vastavat tähistust (punane rist). Kui protsess sisaldab mitut nö tähistamata lõppsündmust (punast ringi täiendava tähistuseta), siis  peab sellised lõppsündmused üheks sündmuseks koondama.

Erinevates allikates on erinevaid protsessimudelite kvaliteedi juhiseid kirjeldatud aga nende rakendamisel tuleks säilitada nö “terve mõistus” – neid juhiseid tuleks rakendada täpselt nii palju, kui see aitab kaasa protsessimudelist arusaamisele. Väga hea ülevaate taolistest kvaliteedijuhistest on kirjeldatud järgnevas artiklis – “A Guideline framework for understandable BPMN models” Flavio Corradini, Fabrizio Fornari, Andrea Polini, Barbara Re et. al. Viidatud artiklis on toodud ka tööriist http://pros.unicam.it/bebop-webinterface/  , mis võimaldab enda BPMN-is modelleeritud mudeli üles laadida ning see tööriist analüüsib sinu mudelit ja annab tagasisidet, milliste “reeglite” vastu eksisid. Siinkohal hoiatus, et ärge laske tulemustel ennast morjendada 🙂 , nagu ma ütlesin peab sellistesse juhistesse/reeglitesse suhtuma terve mõistusega.

Kuidas tutvustatud notatsiooni elemente ja juhiseid rakendada?

Alljärgnev joonis kajastab Bizagi Modelleriga joonistatud lihtsustatud toote tellimise protsessi ning näitlikustab, kuidas kasutada järgnevaid BPMN elemente:

  • Bassein – suur ristkülik, mille nimetus käesoleval joonisel on “Toote tellimise protsess”;
  • Rada – käesoleval joonisel on kaks antud protsessiga seotud osapoolt, seega on ka kaks rada – klient ja toodet omav firma;
  • Tegevus – sinised kastid joonisel, nt “Tellimuse registreerimine”;
  • Lüüs – kollased rombid joonisel, tähistuseta lüüs tähendab vaikimisi välistavat lüüsi. Jooniselt on näha, et välistavad lüüsid on varustatud küsimustega, nt. “Kas sobiv toode on laos?”;
  • Järgnevusvoog – mustad pidevad jooned, mille otsas on nool. Need jooned seovad omavahel teisi BPMN-i elemente ja annavad ülevaate, millised elemendid on omavahel seotud ja kuidas nad üksteisele järgnevad;
  • Algussündmus – roheline mummuke protsessi alguses. Konkreetset protsessi käivitab kliendi soov tellida konkreetset toodet;
  • Lõpusündmused – joonisel on näha kahte tüüpi lõpusündmusi. Tähistusega (ristiga) punane mummuke tähistab neid kohti, kus protsess teatud põhjustel katkeb. Tähistuseta punane mummuke näitab, kuhu jõuab protsess välja ja millega lõppeb nö eduka stsenaariumi korral (st. juhul kui ta varem ei katke).

 

Millal BPMN-i kasutada?

Plussid:

  • laialt kasutatav ja seega paljudele hästi mõistetav;
  • kasutatakse palju riigiasutustes;
  • üks kõige võimsamaid ja mitmekülgsemaid notatasioone äriprotsessi piirangute tuvastamiseks.

Miinused:

  • vajab harjutamist ja kogemusi selleks, et kõiki elemente õigesti kasutada;
  • keeruline näha seoseid protsessi erinevate tasandite vahel;
  • erinevad modelleerimise tööriistad võivad sisaldada eri hulgal notatsiooni elemente;

Väga hea eestikeelse ülevaate BPMN-ist ja äriprotsessidest annab protsessianalüüsi käsiraamat “Avaliku sektori äriprotsessid” – https://www.mkm.ee/sites/default/files/protsessianaluusi_kasiraamat.pdf 

Postituses kasutatud allikad

Koostöös IT koolitusega olen ette valmistamas äriprotsesside kirjaoskuse teemalist koolitust – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus

Seega kui tahad BPMN-i notatsioonist rohkem teada, siis koolituse esimesel päeval teen sellest põhjaliku ülevaate, millele järgneb ka praktika ühe konkreetse äriprotsessi modelleerimise näol.

Kuidas alustada äriprotsessi modelleerimist?

Antud blogipostitus annab ülevaate vajalikest sammudest enne äriprotsesside modelleerimist, seletab lahti äriprotsessi raamistiku mõiste ning annab juhiseid modelleerimistarkavara valimiseks.

Mida on vaja teha enne äriprotsessi modelleerimist?

Justnagu maja ehitamisel on kõigepealt vaja projekti, on ka enne äriprotsesside modelleerimist vaja paika panna modelleeritava äriprotsessi raamistik (st. piirid ja lähteparameetrid). Inimestel on erinevad arusaamad sellest, millega üks või teine äriprotsess algab ja lõpeb ning millistest sammudest see peaks koosnema. Seepärast on enne äriprotsessi modelleerimist ülioluline seotud osapooltega läbi rääkida konkreetse äriprotsessi piirid ja muud lähteparameetrid.

Ma tean, et alati on väga suur kiusatus kohe äriprotsesse joonistama hakata aga kui jätta vahele raamistiku täpsustamise samm, siis see võib hiljem põhjustada protsessi skoobi järk-järgulist kasvamist ning korduvat ümberjoonistamise vajadust. Äriprotsesside piiride ja lähteparameetrite läbiarutamine enne modelleerimist annab modelleerijale kindluse, et äriprotsess sisaldab kõike vajalikku. Teiselt poolt paneb see seotud osapooled omavahel arutama ja kokku leppima, mida me ikkagi mingi konkreetse äriprotsessi alla mõtleme. Kuna äriprotsesside mudel peaks sündima koostöös tellijaga, siis ei tohi siin sammus alahinnata ka kommunikatsiooni rolli ning erinevaid tellija kaasamise põhimõtteid.

Äriprotsessi raamistiku täpsustamine

Äriprotsesside raamistiku täpsustamise all pean silmas järgnevaid tegevusi:

  • äriprotsessi nimetuse välja selgitamine ja kokku leppimine;
  • tuvastamine, kes on antud äriprotsessi omanik;
  • äriprotsessi tekstilise kirjelduse koostamine. Kirjeldus võiks olla selline, millest saab aru ka antud äriprotsessiga varasemalt mitte kokku puutunud isik. Kõik kirjelduses kasutatavad spetsiifilised mõisted peavad olema samuti lahti seletatud!;
  • tuvastamine, milline on antud äriprotsessi algatav sündmus. Näiteks mõni äriprotsess algab mingil kindlal ettenähtud ajal, samas teist äriprotsessi algatab laekunud tellimus/avaldus/teabenõue vms.;
  • tuvastamine, milline on antud äriprotsessi lõpetav sündmus. Näiteks võib äriprotsess lõppeda siis, kui tellimus on täidetud (st. tellijale välja saadetud) või teabenõudele on vastatud;
  • tuvastamine, millistest sammudest/tegevustest antud äriprotsess koosneb;
  • kes on antud äriprotsessi kliendid ning millised on tuvastatud klientide ootused?;
  • kes on antud äriprotsessiga seotud muud osapooled ja millised on nende huvid?;
  • kuidas mõõta antud äriprotsessi edukust? Protsessi edukuse mõõdikud peaksid olema seotud antud äriprotsessi klientide ja teiste osapoolte vajaduste ja ootustega.

Kui iga modelleeritava äriprotsessi kohta on täpsustatud äriprotsessi raamistik, on aeg hakata modellerima! 🙂

Milliseid töövahendeid kasutada äriprotsesside modelleerimiseks?

Töövahendi valik sõltub sinu eesmärgist ja eelistustest. Selleks, et valida endale õige töövahend, peaksid leidma vastused järgmistele küsimustele:

  • Milline on sinu eelnev kogemus erinevate äriprotsesside modelleerimise töövahenditega? Kui kogemus puudub, siis tasub alustada lihtsamatest töövahenditest (nt. draw.io, MS Visio, Bizagi). Ei ole mõtet hakata ennast “uputama” spetsiaaltarkvarade elementide mitmekesisusse ja keerukusse!
  • Millistest protsessidiagrammidest sinu sihtrühm aru saab? Tihti olen märganud seda, et näiteks IT lähteülesanded sisaldavad väga keerulisi protsessidiagramme, mis on joonistatud spetsiaaltarkavaradega ning sisaldavad antud spetsiaaltarkava spetsiifilisi elemente, mida on notatsiooni mõistes ka valesti kasutatud. Sellised protsessidiagrammid raskendavad protsessist arusaamist ja tekitavad tihti palju rohkem küsimusi kui annavad vastuseid!
  • Mida sa plaanid modelleeritud protsessidiagrammiga edasi teha?
    • Kui sul on plaanis protsessidiagrammi joonistada selleks, et lihtsalt selgitada, mida konkreetne äriprotsess endast kujutab, siis sobib  protsessidiagrammi joonistamiseks põhimõtteliselt ka tavaline joonistusprogramm (nt. MS Visio, Google draw.io jne);
    • Kui sul on plaanis hakata süstemaatiliselt oma ettevõtte äriprotsesse kaardistama ja haldama,  siis peab kaaluma juba mõnda keerulisemat töövahendit, milles on võimalik seotud protsesse ja alamprotsesse omavahel linkida ning mis sisaldab modelleeritud protsesside repositooriumi (nt. Bizagi BPM Suite, Enterprise Architect, Camunda jne);
    • Kui sul on huvi kaardistatud äriprotsesse hakata tõhustama ja tahad katsetada, kuidas üks või teine muudatus mõjutab äriprotsessi kestvust ja/või efektiivsus, siis pead valima töövahendi, mis võimaldab äriprotsesside simulatsioone läbi jooksutada (nt. Bizagi BPM Suite, ARIS Business Designer, Signavio Process Editor, IBM Websphere Business Modeller, Oracle Business Process Analysis (BPA) Suite jne).
  • Kui palju on konkreetsel töövahendil kasutajaid ja kas on olemas piisavalt töövahendi kasutamist selgitavaid juhendeid/videosid/foorumeid? Kui tegemist on piisavalt keeruka töövahendiga, siis on heade juhendite olemasolu väga oluline!

Erinevaid äriprotsesside modelleerimist ja haldamist võimaldavaid tarkvarasid on palju. Hea ülevaate saad näiteks Gartneri koostatud nimekirjast ja hinnangutest – https://www.gartner.com/reviews/market/business-process-management-platforms. Eestis kasutatakse laialdasemalt Bizagi-t, Enterprise Architect-i, Camundat.

Postituses viidatud tarkvarad

Järgmises blogipostituses käsitlen enamlevinud äriprotsessidega seotud notatsioone BPMN-i (Business Process Management Notation) ja DMN-i (Decision Model and Notation) ning nende põhilisi elemente, mida näitlikustan ühe konkreetse protsessi abil. Stay tuned! 🙂  

 

 

Kust ma tean, milliseid äriprotsesse kõigepealt kaardistada?

Mis on kaardistamise eesmärk ja skoop?

See on kõige-kõige olulisem aspekt, mis on vaja korralikult läbi mõelda! Äriprotsesse ei kaardistata kaardistamise/kirjeldamise tegevuse pärast iseenesest, vaid üldiselt on see seotud sooviga oma ettevõtte äriprotsessidest aru saada ja neid ühel või teisel viisil tõhustada. Äriprotsesside kaardistamise vajadus võib tekkida ka arendatava süsteemi toimepõhimõtete selgitamise või näiteks teenuste lõpptarbijale mugavamaks muutmise soovist. Siinkohal on väga heaks näiteks sündmusteenusepõhine lähenemine, mille puhul on ülioluline aru saada, kuidas teenuse tarbija tegelikult konkreetse sündmusega seotud teenuseid tarbida tahab. Kindlasti ei taha värsked abiellujad abiellumise avaldusi paberil esitada ja maru mugav oleks nime vahetaval osapoolel kohe ühe toiminguga saada vormistatud ka uue nimega isikut tõendavad dokumendid ja/või autojuhiluba. Misiganes on teie äriprotsesside kaardistamise ja tõhustamise tegevuste eesmärgiks, siis palun ärge unustage antud äriprotsessiga seotud töötajaid/lõppkasutajaid ja nende eesmärke!

Äriprotsessi skoop

Äriprotsesside kaardistamise eesmärk määrab ära tegevuste skoobi ehk sisuliselt nimekirja nendest äriprotsessidest, millele peaksite keskenduma. Sündmusteenuste puhul on skoobis kõik äriprotsessid, mis üht või teistpidi on konkreetse sündmusega seotud. Kui võtta näitena eelpool mainitud abiellumise sündmusteenust, siis see peaks sisaldama abiellumise avalduse algatamise protsessi, abielu registreerimise planeerimise protsessi, varasuhte valimise protsessi, uue nime valmise protsessi, uue nimega seotud dokumentide tellimise protsessi ja riigilõivude tasumise protsessi. Kaardistamise skoobi võib seada aga hoopis ettevõtte, osakonna või üksuse põhiselt. Terve ettevõtte äriprotsesside kaardistamine on väga suur töö, mis nõuab süsteemset lähenemist ja pühendumist nii kaardistust läbiviiva isiku kui ettevõtte juhtkonna poolt. Kui skoop on paigas, siis tuleb saada ülevaade/koostada nimekiri kõikidest äriprotsessidest, mis kuuluvad kokkulepitud skoopi.

Kust saada infot, milliste äriprotsessidega ettevõte/osakond tegeleb?

Ettevõtte/osakonna äriprotsesside tuvastamiseks on mitmeid võimalusi ja see, millist meetodit valida sõltub sellest, kui palju on varasemalt äriprotsesse dokumenteeritud. Kõige levinumad meetodid on:

  • ettevõtte töötajate ameti- või tööjuhendite läbitöötamine – nendes talletatakse tavaliselt konkreetse rolli vastutused ja tööd. Sellest infost tekib esmane ülevaade, millega konkreetsed töötajad igapäevaselt tegelevad;
  • ettevõtte töötajate jaoks loodud infosüsteemide kasutusjuhendite läbitöötamine – kui töötajate igapäevaste tööülesannete läbiviimiseks on arendatud infosüsteemid, siis nende kasutusjuhenditest saab samuti aimu, millega konkreetsed töötajad tegelevad. IS-de kasutusjuhenditesse tuleb suhtuda kriitiliselt! Näiteks väga ammu arendatud IS-d ei pruugi kajastada enam töötajate tegelikke tööprotsesse ja vajadusi. Juhul kui töötajad kasutavad mõnda karbitoodet, siis see võib sisaldada kõvasti rohkem funktsionaalsusi, kui konkreetse ettevõtte töötajad tegelikult oma tööülesannete tarvis vajavad;
  • ettevõtte töötajate tööd reguleerivate või hõlbustavate juhiste läbitöötamine – sõltuvalt ettevõtetest võib olla koostatud erinevate töölõikude jaoks konkreetseid juhiseid, mis aitavad samuti aru saada seotud tööprotsessidest. Näiteks on maakaarte valmistavas ettevõttes juhised selle kohta, kuidas kaardile info paigutada (pole sugugi lihtne ülesanne, eriti kui pead suure hulga infot ära paigutama!), milliseid värve/värvipalette kaardil kasutada, milliste leppemärkidega reaalse maailma nähtusi kaardil kujutada jne;
  • tööde/teenuste hankimise lepingud – hankelepingud võivad samuti sisaldada infot, mis on ühe või teise osapoole kohustused ning sealt võib välja kooruda täiendavat infot seotud osapoolte tegevuste kohta. Lepingutes fikseeritud tööülesannete kirjeldustesse tuleb samuti suhtuda kriitiliselt! Teame ju kõik, et tegelik elu teeb tihti lepingus sätestatu suhtes korrektsioone.
  • ettevõtte töötajatega intervjuude läbiviimine – intervjuud on eelistatud siis, kui dokumentide kujul on juba olemas mingi arusaam äriprotsessidest ning vajadus on nende kohta täiendavaid küsimusi esitada;
  • ettevõtte töötajate igapäevaste tegevuste vaatlus – väga hea meetod juhul, kui pole eelnevalt mingeid dokumente, mille alusel esmane arusaam tekitada. Kui töötaja jääb jänni oma tööülesannete kirjeldamisega, siis küsi “Aga palun näita mulle, kuidas sa seda tegevust teed?”;
  • ettevõtte töötajate jaoks loodud infosüsteemide kasutuslogid – selleks, et IS logidest saaks töötajate igapäevaseid tegevusi kajastavat infot, on vaja, et nimetatud logid sisaldaksid õige granulaarsusega infot.  IS logide analüüsi tegevust koondab mõiste process mining – siinkohal raamatusoovitus Wil van der Aalst  “Process Mining” .

Ja muidugi kõige ideaalsem stardipositsioon on see, kui eelnevalt on olemas juba ettevõtte äriprotsesse (kasvõi mingi seisuga) kajastavad protsessidiagrammid.

Mis on äriprotsesside arhitektuur?

Kui huvipakkuvad äriprotsessid on tuvastatud ja on tekkinud äriprotsesside nimekiri, siis on vaja hakata seda teavet süstematiseerima.  Äriprotsessid on oma olemuselt hierarhilised, mis tähendab seda, et iga üldisema protsessi saab omakorda jagada alamprotsessideks ning iga alamprotsessi veel omakorda alamprotsessideks. See, kui palju alamprotsesside tasemeid mingi konkreetse äriprotsessi alla mahub, sõltub protsessi keerukusest ja äriprotsesside modelleerijast. Üldine soovitus on loetavuse ja arusaadavuse parandamiseks väga suured ja keerukad protsessidiagrammid tükeldada alamprotsessideks.  Näide – kaardi valmistamise tööprotsess võib alamprotsessidena sisaldada lähteinfo korrastamise tööprotsessi, leppemärkide väljatöötamise tööprotsessi, värvipalettide väljatöötamise tööprotsessi, kaardiinfo kujundamise tööprotsessi jne. Lähteinfo korrastamise tööprotsess võib omakorda sisaldada lähteinfo andmebaasi sisestamise tööprotsessi, olemasoleva info valideerimise tööprotsessi jne. Äriprotsesside süstematiseerimiseks ja omavahelise seoste näitlikustamiseks sobib väga hästi äriprotsesside arhitektuur.

Äriprotsesside arhitektuur on sisuliselt äriprotsesside grupeeritud nimekiri, mis kajastab äriprotsesse (sh nende alamprotsesse) ja nende omavahelisi seoseid. Hea kirjelduse ja näiteid äriprotsesside arhitektuurist leiad raamatust “Fundamentals of Business Process Management”.

Milline äriprotsess on kõige olulisem?

Tavaliselt kujuneb äriprotsesside nimekiri üpris pikaks ja selleks, et suures mahus mitte pead kaotada ja efektiivselt oma edasisi tegevusi planeerida, on vaja paika panna, milliseid äriprotsesse peaks kõigepealt kaardistama hakkama. Seda tegevust nimetatakse äriprotsesside prioriseerimiseks. Misiganes prioriseerimise tegevuse puhul, tuleb kõigepealt paika panna kriteeriumid/mõõdikuid, millele tuginedes hindeid antakse. Enimkasutataiv ja lihtsaim prioriseerimise kriteerium on olulisus ehk hinnatakse teatud funktsionaalsusi või äriprotsesse nende olulisuse põhjal. Kui arendusprojektides saab olulisele tuginedes funktsionaalsusi üpris edukalt hinnata (nt. lõppkasutaja jaoks kõige olulisemad funktsionaalsused saavad kõige kõrgema hinde), siis äriprotsesside vaates on prioriseerimine komplekssem tegevus ja hõlmab mitmeid kriteeriume ja mõõdikuid, mis kajastavad äriprotsesside erinevaid tahke . Järgnevalt on välja toodud mõned näited kriteeriumitest ja nendega seotud mõõdikutest.

Äriprotsesside prioriseerimise kriteeriumid
  • Mõju – kui palju konkreetne äriprotsess mõjutab ettevõtte olulisi teenuseid/toodet?
  • Rakendamine – äriprotsesside muudatuste rakendamise lihtsus
  • Olemasolev olukord – kui hästi konkreetne äriprotsess hetkel töötab?
  • Väärtus – kui suurt väärtust looks konkreetse äriprotsessi tõhustamine?

Selleks, et lihtsustada väljatoodud kriteeriumite hindamist, on iga kriteeriumi alla defineeritud mõõdikud või kontrollküsimused (vaata joonist). Iga mõõdiku kohta peab määrama ka skaala – näiteks, millise juhul saab hinde 3 (palju töötajaid on seotud) ja millisel juhul hinde 1 (vähe töötajaid on seotud). Näiteks äriprotsessi mõju hinne koosneb kahest mõõdikust – esimene annab vastuse küsimusele, kui paljud töötajad on seotud antud äriprotsessiga. Mida rohkem töötajaid on antud äriprotsessiga seotud, seda suurema hinde antud äriprotsess saab. On ju loogiline, et kõikidest tõhustamist vajavatest äriprotsessidest saab kõige kõrgema hinde see, millega on kõige enam töötajaid seotud.  Teine mõju mõõdik annab vastuse küsimusele, millise taseme töötajad on antud äriprotsessiga seotud. Mida kõrgema taseme töötajatega on tegemist, seda suurema hinde antud äriprotsess saab (see loogika võib sõltuvalt ettevõttest olla ka teistpidine).

Üleval toodud joonisel on iga kriteerumi juurde kirjeldatud näitena erinevaid mõõdikuid, mida võib kaaluda prioriteetsuse hindamisel. Soovitav oleks, et iga ettevõte defineeriks prioriteetsuse hindamisel mõõdikud oma visoonist ja eesmärkidest lähtuvalt.  Äriprotsessi prioriteetsuse koondhinne kujuneb kõikide mõõdikute hinnete summast.

Nüüd oleme jõudnud niikaugele, et teame, millised äriprotsessid on tegevuse skoobis ja millist neist oleks vaja kõigepealt kaardistada. Ega siis midagi, kui tuleb kaardistamisega pihta hakata. Järgmises blogipostituses käsitlen lähemalt tegevusi, mida on vaja läbi mõelda enne kui hakata protsessidiagramme joonistama 🙂

Postituses viidatud raamatud
  • “The Power of Business Process Improvement” Susan Page
  • “Fundamentals of Business Process Management” Marlon Dumas, Marcello La Rosa, Jan Mendling, Hajo A. Reijers
  • “Process Mining” Will van der Aalst

Kes tahab mõtteid vahetada, siis andke endast mulle märku!

 

« Older posts