Kuna pilt ütleb rohkem kui tuhat sõna, siis olen viimasel ajal hakanud ka erinevaid enda tegevusi äriprotsesside vahendusel visualiseerima. Antud postituses tutvustan enda AS-IS äriprotsesside kaardistamise tööprotsessi. Modelleerin enda töövoo BPMN notatsioonis ning selgitan lahti, milliseid tegevusi millises järjekorras tavapäraselt teen.

Tavapäraselt algab äriprotsesside kaardistus vajadusest paremini aru saada, kuidas teatud töövood hetkel käivad ning millised osapooled sellega seotud on. Selline vajadus võib näiteks tekkida teenuse kvaliteedi parendamise raames, ettevõtte digitaliseerimise algatustest või infosüsteemide arendamisega seoses.

Mida modelleerida?

Kõigepealt on vaja endale tekitada arusaam ettevõtte/asutuse erinevatest äriprotsessidest ning sellest, millist äriprotsessi kaardistama on vaja hakata. Kui sellist arusaama ei ole, tuleb kõigepealt luua ettevõtte äriprotsesside arhitektuur. Väga uhke mõiste aga sisuliselt tähendab see kõikide ettevõtte äriprotsesside organiseeritud kogumit. Organiseerimise all mõtlen seda, et üldisema taseme protsessid on eristatud madalama taseme protsessidest ning seatud omavahelisi hierarhiaid kujutavasse nimekirja või on seda hierarhiat mingil kujul visualiseeritud.

Kui äriprotsesside arhitektuur on olemas, siis oleks vaja loodud organiseeritud nimekirjast valida see kõige olulisem äriprotsess, mida kaardistama minnakse. Seda saab teha äriprotsesside prioriseerimise kaudu ning sellest olen kirjutanud eraldi blogipostituses – https://kreetsolnask.com/kust-ma-tean-milliseid-ariprotsesse-koigepealt-kaardistada/ .

Edasi jätkub töö selle ühe kõige olulisema äriprotsessiga. Enne modelleerimist on vaja tellijaga/äriprotsessiga seotud osapooltega kokku leppida, mis on äriprotsessi kaardistamise eesmärk ning milline peaks sellest eesmärgist tulenevalt olema protsessimudeli detailsus. Kui tarkvaraarendajale on vaja väga detailset ja tehniliselt nüanssirohkem protsessimudelit, siis näiteks teenusejuhile sobib tase üldisem protsessimudel. Väga oluline on, et modelleerimise eesmärgi ja detailsuse kokkulepe oleks olemas enne mudeli joonistamist!

Kust saada äriprotsessi kohta infot?

Igasugust äriprotsessi on palju lihtsam modelleerida siis, kui sul on olemas taustateadmine selle protsessi kohta – sisuliselt on vaja aru saada, mida modelleeritav äriprotsess üldse sisaldab, millised osapooled on sellega seotud ning kuidas see konkreetne äriprotsess ettevõte/asutuse teiste äriprotsessidega seostub (nö suur pilt). Sellise taustateadmise saab tekitada erinevate äriprotsessiga seotud materjalide läbitöötamisega või kui selliseid materjale ei ole, siis äriprotsessiga seotud osapoolte intervjueerimise kaudu. Arvestama peab seda, et kui äriprotsessiga seotud alusmaterjalid puuduvad, siis peab selle võrra rohkem intervjuude voore läbima.

Aga mida teha siis kui äriprotsessiga seotud osapooled ei ole valmis intervjuude käigus rääkima? Vahel ikka juhtub, et mõni inimene ei suuda ennast selgelt väljendada või on tema igapäevased tegevused tema jaoks nii iseenesest mõistetavad, et ta ei oskagi neid kirjeldada. Sellisel juhul on väga heaks metoodikaks vaatlus – sisuliselt lähed protsessiga seotud osapoolte juurde kohale ja jälgid, kuidas nad enda tööd teevad.

Juhul kui olemasoleva äriprotsessi toetamiseks on loodud mingi infosüsteem, siis võib väga head infot saada ka infosüsteemide logidest. Sõltuvalt infosüsteemi logide granulaarusest, võib sealt olla võimalik välja lugeda, milliseid infosüsteemi mooduleid või funktsionaalsusi, millises järjekorras läbitakse. Sellise lähenemise inglise keelne koondmõiste on Process Mining – kel huvi võib internetist lähemalt uurida.

Kuidas modelleerida?

Nüüd peaksid olema äriprotsesside kaardistamisel juba sellises punktis, et on aeg hakata BPMN-is mudelit modelleerima. Aga enne veel võiksid paika panna oma äriprotsessi skoobi – see annab kindluse, et oled koostöös seotud osapooltega läbi mõelnud, milline on minu äriprotsessi ulatus. Äriprotsesside skoobist ehk raamistikust olen kirjutanud eraldi blogipostituse – https://kreetsolnask.com/kuidas-alustada-ariprotsessi-modelleerimist/ Võtmetähtsusega on äriprotsessiga seotud osapooltega koos paika panna äriprotsessi algus- ja lõppsündmus!

Lõpuks tuleb äriprotsess BPMN notatsioonis (võib muidugi kasutada ka mõnda muud notatsiooni, minu isiklik lemmik on lihtsalt BPMN :)) ära modelleerida. Ära ei tohi unustada, et seda modelleeritud protsessi tuleb kindlasti vähemalt korra protsessiga seotud osapooltega valideerida! Oluline on, et protsessimudelist saaksid lisaks modelleerijale aru ka kõik protsessiga seotud osapooled ning siin tuleb võtta niipalju aega kui vaja, et mudel nendega läbi käia ja nende heakskiit saada.

Mis saab edasi?

Kui läheb hästi ja protsessiga seotud osapoolte heakskiit saabub kiirelt, siis palju õnne, oled edukalt jõudnud ühe äriprotsessi kaardistatud. Tavapäraselt nii hästi lähe ning sõltuvalt protsessiga seotud osapoolte tagasisidest võib olla vajadus ümber mõtestada protsessi skoop (kirjeldada uuesti äriprotsessi raamistik) või teha täiendusi AS-IS protsessimudelisse.

Varem või hiljem jõuavad kõik protsesside kaardistused sellisesse seisu, et on tekkinud protsessiga seotud osapoolte poolt heakskiidu saanud AS-IS protsessimudel. Võin teid lohutada, et sellega töö ei lõppe – järgmise sammuna on vaja AS-IS protsessi analüüsida, tuvastada selles probleemkohad ning neile lahendusi leides disainida TO-BE tööprotsesse. Aga sellest kirjutan juba eraldi postituses, milles tutvustan taaskord äriprotsessi kaudu enda lähemist.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele raames rakendame siin postituses kirjeldatud äriprotsessi kaardistamise tööprotsessi – https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

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

Lubasin eraldi blogipostituses jätktata enda koostatud Ishikawa diagrammi lahti kirjutamist. Seekord käsitlen siis metoodika ja meeskonnaga seotud juurpõhjuseid.

Metoodika

Vikipeedia definitsiooni järgi on metoodika (inglise keeles methodology) korrastatud lähenemine suuremale tegevusele. Metoodika jaotab protsessi väikemateks osadeks, püstitab osadele eesmärgid ning võib näidata ära meetodid nende eesmärkide saavutamiseks https://et.wikipedia.org/wiki/Metoodika.

Minu jaoks tähendab metoodika arusaama, kuidas ma konkreetseid metoodeid/töövõtteid rakendades konkreetse eesmärgini jõuan. Ehk siis ühelt poolt peab olema väga selge arusaam, mis on eesmärk. Teiselt poolt peab olema teadmine, milliseid konkreetseid tegevusi/meetodeid, millises järjekorras selle eesmärgini jõudmiseks rakendatatakse. Tundub ju lihtne ja loogiline? Tegelikkuses on kahjuks misiganes metoodilised märksõnad tarkvara arendusprojektides tihti ainult sõnakõlksud. Puudub tegelik arusaam, mis on nende sõnade taga.

Projektijuhtimise metoodika

Projektijuhtimise meetoodikaid on väga palju erinevaid ning neid ma siin kõiki ükshaaval tutvustama ei hakka. Minu tähelepanek on seotud sellega, et väga palju viidatakse tarkvara arendusprojektides mingile metoodikale ilma lahti mõtestamata, mida see tähendab, kuidas seda rakendada ja kas seda antud kontekstis üldse rakendada on võimalik.

Lõpuks ei ole vahet, millist metoodikat kasutatakse, oluline on projekt etteantud piirangute raames võimalikult edukalt ära teha. Kui projekti realiseerimiseks on väga pingeline ajaperiood, kindel skoop ja eelarve, siis peab olema nagu kellavärk selge, kes mida ja millal teeb. Sellisel juhul ei saa lubada endale agiilsuse sildi all planeerimatust ja metoodika ning vajalike oskuste puudumist.

Millest siis kliendi vaatest vajaka jääb? Suurel osal juhtudest jääb vajaka planeerimise oskusest. Ehk siis mõtteviisist, milliseid tegevusi millises vahemikus on vaja teha selleks, et me mingi etapi lõpuks vajalikud eesmärgid täidetud saaks. Sellise plaani olemasolu on vajalik ka kliendi ootuste juhtimiseks – et oleks arusaam, millal peab olema klient valmis midagi üle vaatama või testima.

Teine oluline tegevus, mis tihti tegemata jäetakse on arendustiimi sees rollide vastutuste ja koostöö korralduse kokku leppimine. Kui seda paika ei panda, siis töö tegijad ei tea, mis nendelt oodatakse ja kuhu “maani” peavad nemad panustama. Rollide paikapanemine ja läbirääkimine peab toimuma koostöös kliendiga! Siis on ka tema ootused rollide tööülesannetele juhitud.

Projektis vajaliku kommunikatsiooni tagamine on samuti üks osa projektijuhtimise metoodikast. Eeldatatakse, et meeskonna sees teineteisega suhtlemine ja info vahetamine on elementaarne ning iga meeskonna liige saab sellega edukalt hakkama. Kuna inimtüübid on erinevad, siis paraku see kõigile nii elementaarne ei ole. Siin on jällegi projektijuhi vastutus aidata sellised juhtusid lahendada! Ja kommunikatsiooni all ei mõtle ma ainult silmast-silma suhtlemist, vaid misiganes infovahetuse viisi.

Analüüsi metoodika

Ma ise olen valdavalt olnud erinevatest analüütiku rollides, seega on analüüsi metoodika mulle väga südamelähedane teema. Nagu nimetuski viitab on analüütiku töö olemus mingi info läbi analüüsimine ning selle läbi kliendi vajaduste parem mõistmine. Tihti on läbitöötamist vajavat infot palju ja seda on vaja veel täiendavalt juurde koguda, et tekiks arusaam, mida kliendil päriselt vajab. Selleks, et mingi infokild ei jääks kahe silma vahele, on vaja väga konkreetset ja süsteemset plaani. Vaja on läbi mõelda, millist infot on vaja koguda, kuidas seda võimalikult optimaalselt teha ning milliste meetoditega seda analüüsida. 

Kurvaks teeb see, et väga sageli tarkvaraarendusprojektides analüütikutel selline plaan/metoodika puudub ning rööpräheldakse ühel ja teisel rindel. Pole ime, et midagi jääb kahe silma vahele ja analüütikul on enda kaitseks vaid öelda “Aga ma ei saanud aru, et teil selline vajadus on!”. Analüütiku peamine ülesanne on aru saada, mis on kliendi vajadus! Kui seda arusaama ei teki, siis tuleks peeglisse vaadata ja endalt küsida:

• kas ma mõistan üldse probleemi, mida lahendatakse?
• kas ma sain kliendilt kinnituse, et olen tema probleemist õigesti aru saanud?
• kas mul oli plaan/tegevuskava, kuidas kellelt ja mis infot ma vajan?
• kas minu tegevuskava mahub projekti etteantud raamidesse?
• kas ma analüüsisin lahendatavat probleemi erinevatest aspektidest?
• kas ma saan aru, kuidas pakutav lahendus probleemi lahendab? nö suure pildi mõistmine
• kas ma palusin kliendil keerulisemaid asju mitmeid kordi selgitada?
• kas ma peegeldasin kliendile oma arusaama?

Teine tähelepanek, mida olen märganud on see, et kogutakse küll seotud osapooltelt vajalik info ära, mis vormistatakse memodeks ning sellega justkui analüüs lõppeb. Kallid analüütikud, tahaksin teile meelde tuletada, et analüütiku rolli nimetus on meelega analüütik ja hoopis mitte referent! Info kogumine on alles esimene osa analüüsist. Kõige olulisem osa on kogutud info analüüsimine/sünteesimine ning selle pinnalt koostöös meeskonnaga kliendile vajaliku lahenduse välja pakkumine.

Analüütik peab suutma mõista kliendi probleemi ja tööprotsesse. Kogutud info pealt suurt pilt näha ning koostöös tehnilise meeskonnaga välja pakkuda lahendusi kliendi probleemi lahendamiseks. Kui ta seda ei suuda, siis puudub analüütikul antud projektis/teenuses väärtuspakkumine!

Meeskond

Meeskonna puhul on võtmetähtsusega kolm faktorit – oskused, kogemused ja tahe ehk motivatsioon. Ideaalses tarkvaraarenduse meeskonnas on kõikidel rollidel need kolm faktorit esindatud. Ehk rollil on olemas oskused vajalikke metoodikaid rakendada, ta on seda saanud varasemalt praktiseerida ning tal on tahe klienti aidata.

Nagu me juba teame, siis kahjuks ei ela me ideaalses maailmas ning teenust pakkuva meeskonna puhul jääb tihti vajaka üks kolmest faktorist. Ilmselt oleme kõik omal nahal tunda saanud seda, et riigihangetes võib paberile väga ilusad CV-d kokku kirjutada. Aga kui tegelik töö pihta hakkab, siis jääb justkui midagi vajaka.

Kui vajaka jääb oskustest konkreetseid metoodikaid, töövõtteid rakendada, siis tehakse tööd väga ebaefektiivselt. Suure tõenäosusega tekivad raskused projekti etteantud ressursside raames ära teha.

Kui vajaka jääb eelnevast kogemusest, siis suure tõenäosusega ei osata mõelda lahenduse suure pildi peale, mistõttu ei osata ka teatud riske/ohukohti ette näha. See seab samuti ohtu projekti realiseerimise võimalikkuse etteantud ressursside raames.

Kui vajaka jääb tahtest klienti mõista, siis tekib lahendus, mida kliendile tegelikult vaja ei olnud. Sellisel juhul tehakse lihtsalt midagi ära ning pärast vaidluste käigus tuuakse välja argument “Aga te ei öelnud, et teil selline vajadus on”.

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

Ma olen tänaseks 10 aastat aktiivsemalt olnud seotud tarkvara arendusprotsessidega nii teenuse tellija kui ka pakkuja poolel, seega mõtlesin vahelduseks sellest kirjutada. Täpsemalt oli mõte peegeldada minu tähelepanekuid selle kohta, miks klient tihti ikkagi ei saa tarkavaraarenduse projektidest seda, mida ta vajab. Oma tähelepanekuid plaanin teile tutvustada läbi Ishikawa või põhjus-tagajärg diagrammi.

Mis on Ishikawa diagramm?

“Kalasaba diagrammi (inglise k fishbone diagramm) tuntakse ka põhjus-tagajärg diagrammi nime all või siis selle looja Kaoru Ishikawa järgi Ishikawa diagrammi nime all. Antud diagrammi kasutatakse probleemi algpõhjuse väljaselgitamiseks. Algpõhjuseni jõudmiseks peab diagrammi joonistamise käigus läbi mõtlema kõik tegurid, mis selle probleemi esile võisid kutsuda.” https://tsenter.ee/kalasaba-diagrammide-kasutamine-probleemide-lahendamisel/

Minu poolt koostatud Ishikawa diagrammi (Joonis 1) probleemiks on küsimus “Miks klient ei saa seda, mis tal vaja on?” ning selle probleemi algpõhjuseid analüüsides olen tuginenud enda tähelepanekutele tarkavaraarenduse projektidest. Minu joonise algpõhjuste grupid on kohandatud vastavalt minu tähelepanekutele. Tavapäraselt võite internetist leida Ishikawa diagramme, milles on algpõhjused grupeeritud 6 suuremasse gruppi.

Joonisel viidatud algpõhjuste gruppe kirjutan lahti mitmes järjestikusest blogipostituses. Plaanisin küll seda teha ühe postitusega aga te poleks viitsinud seda siis lõpuni lugeda 🙂 Antud postituses tuleb siis juttu tehnoloogiast ja andmetest.

Tehnoloogia

Tehnoloogia on väga võimas vahend, misiganes tööprotsesside efektiivistamiseks või automatiseerimiseks. Aga seda peab oskama rakendada õigel kujul õigetes kohtades! Mida ma selle all mõtlen? Tehnoloogiat ei ole vaja rakendada lihtsalt sellepärast, et see on uus kuum trend või et keegi teine kusagil seda teeb. See toob kliendile kasu ikkagi siis ja ainult siis kui see haakub antud kliendi tööprotsessidega. Tehnoloogia rakendamise/juurutamisega seoses on minu algpõhjuste tähelepanekud olnud järgnevad:

• Tarkvaraarenduse projektides pööratakse tihti liiga vähe tähelepanu arhitektuuri läbimõtlemisele ja paika panemisele. Ja siin on oluline arhitektuur mitte abstraksel tasandil, vaid juba seoses äriarhitektuuriga ja tööprotsessidega.
• Tihti on arhitektuur planeeritud nii, et see ei haaku kliendi tööprotsessidega. See viitab sellele, et tehnoloogiline vaade ei ole kooskõlas äriliste vajadustega ning seda on planeeritud ärilistest vajadustest isoleerituna.
• Üks peamine ootus arhitektidele on see, et nad on kursis erinevate tehnoloogiliste võimalustega ning oskavad neid sobitada ärilistest vajadustest lähtuvalt ka arhitektuuri. Selle tegemine eeldab arhitektilt oskust ja tahet mõista ärilisi vajadusi. Tundub elementaarne aga sellist oskust kohtab kahjuks vähe! Ma olen mainitud 10 aastase perioodi jooksul kohanud ainult kahte sellist arhitekti, kes seda on suutnud hästi teha.

Andmed

Väga hea viis tööprotsesside efektiivistamiseks on elimineerida tööprotsessidest kasutaja sellised manuaalsed tegevused, millega saab väga edukalt hakkama masin/tehnoloogia. Andmete liigutamine ühest allikast teise, andmete kokku kombineerimine ja omavaheline rikastamine on näited sellistest tegevustest, mida saab misiganes tööprotsessides teha väga edukalt tehnoloogia kaasabil. Andmetega seoses on minu algpõhjuste tähelepanekud olnud järgnevad:

• Tarkvaraarenduse projektides pööratakse üldiselt väga vähe tähelepanu andmetele ja justnimelt sellele poolele, kuidas kusagil kogutavad andmed saavad säästa mõnes teises tööprotsessis osalevate inimeste tööaega ning millist kasu/väärtust andmed konkreetsele tööprotsessile annavad.
• Kuna ei tajuta andmete väärtus tööprotsesside efektiivistamisel, siis tihti ei planeerita ka tarkvaraarenduse projektidesse andmete analüüsimisega seotud tegevusi. Uute IT süsteemide arendamisel jääb vajaka andmete analüüsi vaade – ei analüüsita, mis andmeid mingi tööprotsess vajab, mis kujul ta neid andmeid vajab, millistest allikatest need andmed saadakse jne.
• Väga tavapärane on see, et arendustele eelnevates äri- või eelanalüüsides reastatakse terve hulk erinevaid liidetusi teiste süsteemidega, mida on vaja projektis realiseerida, ilma endale selgeks tegemata, kas antud allikad sisaldavad ikkagi neid andmeid, mida tööprotsessides on vaja.

Minu joonistatud Ishikawa diagrammilt saate juba märksõnade näol vihjeid, millistele algpõhjustele oma järgmistes blogipostitustes keskendun. Senikaua aga proovige ise ka mõne probleemi kohta koostada Ishikawa diagrammi 🙂

NB! Ishikawa diagramm on väga hea töövahend misiganes muudes tööprotsessides esinevate probleemide algpõhjuste väljaselgitamiseks!

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

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.

Loe edasi…