Rubriik: Uncategorized (Page 1 of 4)

Dubleerivad tegevused tööprotsessides – millised on lahendused?

Erinevaid tööprotsesse analüüsides hakkab mulle peaaegu alati silma see, et keegi peab samu andmeid mitmesse süsteemi käsitsi sisestama. Mõnes protsessis on sellist mustrit vähem, teises jälle rohkem. Andmete sisestaja vaatest on sisuliselt tegemist dubleeriva tegevusega. Tööprotsesside tõhustamisel on üks oluline soovitus dubleerivate tegevuste vähendamine või isegi kõrvaldamine.

Aga kuidas siis selliseid dubleerivaid sisestustegevusi vähendada või kõrvaldada?

Automaatsed liidestused erinevate süsteemide vahel

Esimene ja ilmselt ka kõige kallim lahendusvariant oleks süsteemile arendada liidestused, mille kaudu liiguvad automaatselt ühte süsteemi sisestatud andmed teistesse süsteemidesse. Liidestus tähendab sisuliselt seda, et kokku on lepitud andmete formaat ja koosseis, mis ühest süsteemist teise liikuma peab. Sellise kokkuleppe põhjal on arendaja kirjutanud koodi.

Selle variandi puhul on võtmetähtsusega, et andmed oleksid standardiseeritud. See tähendab seda, et mõlemas süsteemis talletatakse samu andmeid samal kujul. Kui ma pean liigutama ühest süsteemist teise enda töötamistega seotud andmeid, siis peab olema kokku lepitud, milliseid objekte (töökoht, amet, vastutused vms) liigutatakse. Ning millised tunnused neid objekte kirjeldavad (töökoha puhul nt. tööandja nimi, tööandja aadress, otsese juhi nimi, tööstaaži pikkus vms). Täpsemalt võite andmetest ja andmekvaliteedist lugeda minu ühest varasemast postitusest.

Samuti on oluline lähtuda single source of data põhimõttest, mille järgi on üks alliksüsteem, kus toimub andmete parandamine ja täiendamine. Juhul kui mõnes muus süsteemis andmete kasutamise käigus selgub, et andmed vajaksid parandamist, siis tuleb see teave edastada alliksüsteemile. Ehk sisuliselt tuleks kokku leppida ka andmete parandamise ja täiendamise tööprotsess. Kui sellist loogikat ei jälgita, siis on oht, et samad andmed hakkavad erinevatest süsteemides elama oma elu. Selle tulemusena kaob ära ühtne andmeallikas, kus on alati tõene info.

Kolmas oluline nüanss, on erinevate süsteemide vaheline andmete sünkroniseerimise tihedus. Kokku on vaja leppida, kas andmeid sünkroniseeritakse jooksvalt (nö live-is), kord ööpäevas, kord nädalas või mõne muu sagedusega. Sünkroniseerimise tihedus sõltub vajadusest – ehk vaja on välja selgitada, millise tööprotsessi milline tegevus millise sagedusega neid andmeid tarbib.

Igasuguse arenduse puhul võiks alati kaaluda ka selle arenduse tasuvust! Kaaluda võiks, kui sage on see protsess, kus dubleerivalt andmeid sisestatakse (kas see toimub igapäevaselt, kord nädalas, kord kvartalis vms)? Ning kui palju inimesi on sellise protsessiga seotud? Kui tegemist on nt. kord kvartalis läbiviidava protsessiga ning sellega on seotud ainult mõned inimesed, siis suure tõenäosusega ei tasu liidestuse investeering ennast ära. Seega tuleks leida mõni muu lahendus, mis hõlbustaks sellist dubleerivat andmesisestust.

Automaatsed andmete liigutamise töövood erinevate süsteemide vahel

Kui liidestuse väljaarendamise investeering ei tasu ennast ära, siis järgmise sammuna võiks uurida erinevaid töövoogude ehitamise tööriistu. Näiteks Zappier ja Make on sellised, mida mina olen kasutanud ning mis võimaldavad üpris lihtsalt ise valmis komponentidest “ehitada” töövooge. Näiteks töövoogusid, mis liigutavad andmeid ühest kohast teise ja vajadusel ka vormindavad andmeid selle käigus ümber.

Nii Zappier https://zapier.com/apps/categories/databases kui ka ka Make https://www.make.com/en/integrations/category/databases?community=1&verified=1 toetavad integratsioone väga erinevate andmebaasidega, aga teatud juhtudel on vaja tasulist kontot.

Nimatatud töövoogude ehitamise puhul on väga oluline paika panna kogu tööprotsess, mida andmed peavad läbima. Näiteks võivad sellise töövoo puhul olla esimesed sammud üldse mingid andmete vormindamise või andmete kvaliteedi kontrolli sammud. Ning alles seejärel toimub nende liigutamine teise andmebaasi.

Antud lahendus ei nõua otseselt koodi kirjutamise oskust, küll aga võiks olla natuke tehnilisem taustateadmine ja arusaam andmebaasidest. Enne sellise lahenduse kasutamist, tasuks kindlasti oma IT osakonna/inimestega rääkida. Nemad oskavad tähelepanu juhtida selliste lahendustega seotud riskidele ja pakkuda võimalusi nende riskide maandamiseks. Tundlikke ja ettevõtte vaatest konfidentsiaalsete andmete puhul ei pruugi sellised “karbitooted” olla alati kõige õigem lahendus!

Pool-automaatsed andmete liigutamise lahendused erinevate süsteemide vahel

Kui ükski eelnevalt mainitud lahendustest ei ole sinu ettevõtte jaoks sobilik, siis on üheks võimaluseks luua seotud süsteemidesse lisafunktsionaalsused. Üks selline variant on luua nendesse süsteemidesse, kuhu soovitakse andmeid sisestada, võimalus andmeid üles laadida mõnest struktureeritud andmefailist. Struktureeritud andmefaili all on mõeldud andmefaili (nt. csv või xlsx), kus andmed on kokkulepitud struktuuri järgi talletatud.

Selline lahendus vähendaks andmete sisestamisele kuluvat aega, sest andmete sisestaja valmistab andmed ette ühekordselt (nt. Excelis) ja siis laeb sedasama ettevalmistatud faili erinevatesse süsteemidesse. Ettevalmistatud faili laadimiseks sihtsüsteemi on tegelikult erinevad võimalused. Kas läbi kasutajaliidesesse arendatud funktsionaalsuse või siis nt andmehalduri poolt otse andmebaasi. Esimene variant nõuab vajalikes kasutajaliidestes arendusi aga on kiirem, sest ei vaja andmehalduri tööpanust. Teine variant ei nõua ilmselt arendusi, st. on odavam aga siis peab arvestama täiendavalt andmehalduri tööpanusega.

Üks kõige suurem risk, mida selline struktureeritud faili kaudu andmete laadimine võib kaasa tuua, on andmekvaliteedi langus. Sest Excelis ei ole võimalik kõiki sisestavate väljadega seotud reegleid kontrollida. Kui andmete sisestaja ise hoolas ei ole, siis võivad süsteemi jõuda ebaloogilised või vigased andmed.

Kokkuvõte

Lisaks erinevate infosüsteemide liidestamisele leidub ka muid lahendusi, mis saavad aidata vähendada tööprotsessides esinevaid dubleerivaid andmesisestusi. Tuleb vaid leidlik olla ja natuke katsetada! Oluline on endale teadvustada, mis andmetega sa tegeled! Ning kaaluda, kas erinevad turul kättesaadavad lahendused ei kujuta sinu ettevõtte jaoks infoturbe riski.

Kui soovid rohkem teada protsessipõhisest juhtimisest 👉 https://kreetsolnask.podia.com/milles-seisneb-protsessipohine-juhtimine

Kui soovid õppida äriprotsesse kaardistama ja analüüsima 👉  https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus

Kui soovid minu mentorlust oma äriprotsesside kaardistamise ja analüüsi projektis 👉https://calendly.com/kreetsolnask/30min

Protsessianalüüsi peamised väljakutsed: Kuidas nendega toime tulla?

Protsessid ja protsessijuhtimine on teemad, mis on endiselt paljude ettevõtete ja seal töötavate inimeste jaoks arusaamatud. “Mis protsessid? Miks mul on vaja neid kaardistada? Ma ju tean küll, kuidas oma tööd teha!”

Ärimaailmas on protsesside optimeerimine muutunud üha olulisemaks konkurentsieelise saavutamisel ja säilitamisel. Kuid isegi kogenud protsessianalüütikud, kvaliteedijuhid ja tegevjuhid seisavad silmitsi keerukate väljakutsetega, mis võivad takistada edukat protsesside ümberkujundamist. Antud blogipostituses jagan peamisi probleeme, millega protsessianalüütikud kokku puutuvad, ja pakun välja ka mõned lahendused, kuidas nendega edukalt toime tulla.

1. Osapoolte vastupanu ja muudatuste juhtimine

Muudatuste poolt on kõik niikaua, kuni neid ellu viima ei pea hakkama. Inimesed eelistavad sageli harjumuspäraseid tööviise, mis muudab uuenduste elluviimise keeruliseks. Väga levinud on ütlus – “Aga ma olen ju koguaeg niimoodi teinud!”. Misiganes muudatused mõjutavad alati inimesi ja nende praegust harjumust tööd teha. Ja kui me hakkame seda harjumust, kas töökorralduslikult või mõne uue tehnoloogia kasutuselevõtmisega muutma, tekivad kohe hirmud. “Kas mulle jääb alles minu töö?” “Millega mina tegelema hakkan, kui mõni töölõik automatiseeritakse?” jne. Mida suurem on see hirm ja vastupanu, seda keerulisem on soovitud muudatust ellu viia. Algul võib selline olukord tekitada tunde, et võitled justkui tuuleveskitega.

Iga eduka muudatuste juhtimise võti on avatud suhtlus ja läbipaistvus. On oluline, et kõik osapooled mõistaksid, miks muudatusi tehakse ja millist kasu need toovad. Selge ja avatud suhtlus aitab vähendada vastupanu ja suurendab töötajate valmisolekut muudatusi omaks võtta. Üks enamlevinud viga on see, et muudatuse kommunikatsiooni tehakse ainult üks kord ning seejärel öeldaks, et aga ma ju teavitasin neid! Tegelikult peab muudatuse kommunikatsiooni järjepidevalt tegema niikaua, kuni inimestel enam küsimusi ei teki ja ärevus vaibub. Selles suhtes ei erine muudatuste juhi roll väga palju lasteaia kasvataja rollist – niikaua kuulad, selgitad ja rahustad, kuni inimestel rohkem küsimusi ei teki.

Veel üks nipp vastupanu leevendamiseks on seotud inimeste kaasamine ja ühtse meeskonnana toimimise rõhutamine. Mida see kaasamine ikkagi tähendab? Protsesside kaardistamise ja analüüsimise vaatest tähendab see seda, et alates esimestest protsessikaardistuse intervjuudest on kõik seotud inimesed aruteludesse kaasatud, neid kuulatakse ja nende arvamustega arvestatakse. Ja tulevikuprotsesside ideed peaksid tulema justnimelt nendesamade kaasatud inimeste poolt. Kellelegi meist ju ei meeldi see, et ülemus või mõni väline konsultant tuleb ette ütlema, kuidas me peaksime oma tööd tegema! See tekitabki enamasti trotsi!

2. Andmete kvaliteet ja ligipääsetavus

Tänapäeval pole ilmselt enam ühtegi protsessi, mis ei kasutaks mingeid andmeid või toodaks neid. Teine kriitiline probleem on seotud andmete kvaliteedi ja kättesaadavusega. Ebatäpsed andmed võivad viia valede järeldusteni protsesside analüüsimisel, mis omakorda võib põhjustada ebaefektiivseid või lausa kahjulikke muudatusi. Raskesti kättesaadavad andmed tingivad ebamõistlikke protsesside disainimise – st protsessidesse peab hakkama disainima mingeid täiendavaid samme selleks, et andmeid kätte saada. 

Halbade andmete tunnuseks on see, kui need on puudulikud, ebatäpsed või vale struktuuriga. Ebakvaliteetsed andmed tekivad erinevatest standardiseerimata allikatest andmeid kokku koondades või läbimõtletama andmete kogumise ja haldamise tööprotsesside kaudu. Näiteks võib juhtuda, et erinevad osakonnad koguvad sama protsessi kohta andmeid erineval kujul, mis teeb nende omavahelise võrdlemise või kooskasutamise keeruliseks.

Kvaliteetsete andmete saamiseks on oluline läbi mõelda andmete kogumise tööprotsessid ning investeerida andmehalduse süsteemidesse, mis võimaldavad andmeid standardiseerida ja tagavad nende järjepideva kogumise ja haldamise. Samuti on oluline, et kõikidel andmete kogumise ja haldamise eest vastutavatel töötajatel oleks ühtne arusaam andmete kvaliteedist, see tähendab, et nad oleksid teadlikud andmete täpsuse ja täielikkuse tähtsusest. Regulaarsed andmete auditid ja analüüsid aitavad avastada probleeme ja hoida andmed usaldusväärsetena.

3. Protsesside keerukus ja läbipaistvuse puudumine

Ettevõtete protsessid võivad olla väga keerulised, hõlmates erinevaid osakondi, töötajaid ja süsteeme. See omakorda muudab protsesside kaardistamise ja analüüsimise keeruliseks. Igal protsessiga seotud osapoolel on omad ootused, millega peab arvestama. Ning mida rohkem osapooli on seotud, seda keerukamaks läheb ka nende kõigi kaasamine. Samuti võivad kaardistamise keerukust tõsta väga spetsiifilised valdkondlikud protsessid, mille osas puudub protsessianalüütikul eelnev domeeniteadmine.

Keskmistes ja suurtes ettevõtetes võib protsessianalüütikul suure pildi tekkimine võtta omajagu aega. Sest iga osakond keskendub intervjuudel ainult enda “tagaaiale” ning harva osatakse näha seoseid teiste osakonna protsesside ülesannetega. Selle tulemusena võib tekkida protsessianalüütikul “piiratud nägemine”, mis omakorda tingib selle, et ta ei oska optimeerimise käigus arvestada kõiki kriitilisi tegureid või teeb otsuseid, mis toovad kasu ainult teatud osakondadele, aga mitte kogu organisatsioonile.

Selle probleemi leevendamiseks on kasulik rakendada standardiseeritud protsessimodelleerimise tehnikaid, nagu BPMN 2.0, ning kasutada protsesside arhitektuuri raamistikke, näiteks APQC PCF. BPMN aitab väga tulemuslikult keerulisi protsesse ja olukordi visualiseerida. APQC PCF raamistik annab esmase aimduse tavapäraselt ettevõtetest esinevatest protsessidest ja tegevustest. Regulaarsed protsesside ülevaatused ja optimeerimissessioonid aitavad valideerida, kas protsessidest on õigesti aru saadud.

4. Muutuv keskkond ja tehnoloogilised uuendused

Muutus on meie igapäevaelu tavapärane osa ja ka protsessianalüüsi puhul peab arvestama, et tehnoloogia muudab meie igapäevast elukorraldust tuntavalt. See, mis tehnoloogiliselt ei olnud pool aastat tagasi võimalik, on suure tõenäosusega tänaseks juba võimalik. Lisaks võivad muutused tuleneda erinevatest regulatiivsetest nõuetest ja/või turutrendidest. Mainitud muutuste tõttu võivad protsessianalüüsi käigus tehtud ettepanekud kiiresti aeguda ja seetõttu vajab protsesside optimeerimine järjepidevust ja paindlikkust.

Selle väljakutsega toimetulekuks on soovitatav luua tehnoloogilise valmisoleku hindamise raamistik ning investeerida paindlikesse ja skaleeritavatesse IT-lahendustesse. Organisatsiooniülese digitaalse kompetentsi arendamine on samuti kriitilise tähtsusega. Innovatsiooni stimuleeriva keskkonna loomine, näiteks häkatonide või innovatsioonilaborite kaudu, võib aidata organisatsioonil püsida tehnoloogiliste arengutega kursis ja neid oma protsesside optimeerimiseks ära kasutada.

Teisalt peavad ka protsessianalüütikud pidevalt jälgima turu trende, tehnoloogilisi arenguid ja regulatiivseid muudatusi ning olema alati tulevikku suunatud pilguga. Samuti tuleks arvestada, et protsessianalüüs ei ole ühekordne tegevus, mida saab sahtlisse seisma jätta. See on miskit, millega peaks pidevalt ja iteratiivselt toimetama. Ainult siis saad tagada selle, et protsessid vastavad muutuvale keskkonnale ja tehnoloogiale.

5. Kultuurilised ja organisatsioonilised barjäärid

Iga organisatsioon on unikaalne ja selles võivad eksisteerida erinevaid kultuurilisi ja organisatsioonilisi takistusi, mis mõjutavad protsesside kaardistamist ja analüüsimist. Näiteks võivad erinevad osakonnad töötada erinevate prioriteetide ja eesmärkidega, mis muudavad ühiste lahenduste leidmise keeruliseks.

Selle väljakutse ületamiseks on oluline juurutada pideva täiustamise kultuur, näiteks Kaizen filosoofia abil. Tunnustussüsteemi loomine protsesside parendamiseks ja innovatsiooniks võib motiveerida töötajaid aktiivselt osalema optimeerimisprotsessides. Regulaarsed koolitused ja teadlikkuse tõstmise sessioonid aitavad luua ühist arusaama protsesside optimeerimise tähtsusest. Lisaks on oluline mõõta ja kommunikeerida protsesside optimeerimise tulemusi läbipaistvalt, et näidata tehtud muudatuste positiivset mõju.

6. Piiratud ressursid ja eelarve

Viimaseks, kuid mitte vähem oluliseks väljakutseks on piiratud ressursid ja eelarve. Protsesside analüüs ja optimeerimine nõuavad märkimisväärseid investeeringuid nii ajas kui ka rahas. Selle probleemi lahendamiseks on soovitatav rakendada ROI-põhist projektide prioriseerimise metoodikat, mis aitab keskenduda kõige suuremat väärtust loovatele algatustele. Agiilsete projektijuhtimise meetodite kasutamine võib aidata kiiremini väärtust luua ja ressursse efektiivsemalt kasutada. Mõnel juhul võib olla kasulik kaaluda väliste ekspertide kaasamist spetsiifiliste probleemide lahendamiseks. Pikaajaliste investeeringute planeerimiseks on soovitatav luua strateegiline teekaart, mis aitab ressursse optimaalselt jaotada ja tagada järjepidevus protsesside täiustamisel.

Kokkuvõte

Kokkuvõttes nõuavad protsessianalüüsi väljakutsed süsteemset ja strateegilist lähenemist. Nii nagu Roomat ei ehitatud ühe päevaga, ei saa ka protsessianalüüs valmis kiirelt ja ühe iteratsiooniga. Edu võti peitub järjepidevas täiustamises, andmepõhises otsustamises ja täiustamisele suunatud organisatsioonikultuuri kasvatamises. Rakendades siin toodud strateegiaid, saavad organisatsioonid abi oma tuuleveskitega võitlemisel. Veelkord meeletuletuseks, et protsesside kaardistamine ja optimeerimine ei ole ühekordne projekt, vaid pidev teekond, mis nõuab püsivat tähelepanu ja pühendumist kõigilt organisatsiooni liikmetelt. Ainult nii saab tagada, et organisatsioon püsib efektiivne ja konkurentsivõimeline ka kiiresti muutuvas ärikeskkonnas.

Kui soovid rohkem teada protsessipõhisest juhtimisest 👉 https://kreetsolnask.podia.com/milles-seisneb-protsessipohine-juhtimine

Kui soovid õppida äriprotsesse kaardistama ja analüüsima 👉  https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus

Kui soovid minu mentorlust oma äriprotsesside kaardistamise ja analüüsi projektis 👉 https://calendly.com/kreetsolnask/30mi

Kas äriprotsessi peaks muutma süsteemi järgi või vastupidi?

Käisin Tartus kuulamas “Industry 5.0” konverentsi ja tajusin seal, et väga paljudel tootmisettevõtetel pitsitab king justnimelt erinevate äriprotsesside digitaliseerimise osas. Minu jaoks jäi kõlama, et ERP (Enterprise Resource Planning) tarkvara edukas kasutuselevõtmine on pikk ja vaevaline teekond. Tootmisettevõtetel on välja kujunenud selle kohta lausa naljaga-pooleks küsimus “Kui kaua siis sinul ERP süsteemi juurutamine aega võttis?”. Antud postituses selgitan taaskord äriprotsesside kaardistuse olulisust ning arutlen, milliste sammudega peaks uue süsteemi loomisel või kasutusse võtmisel arvestama.

Kumb on enne – kas äriprotsessid või süsteemid?

See küsimus liigitub natuke samasse kategooriasse küsimusega “Kumb oli enne, kas kana või muna?”. Ehk selles osas on palju erinevaid arvamusi ja seisukohti. Mina olen seisukohal, et äriprotsessid on olemas kindlasti enne süsteemi. AGA ettevõttes võib puududa lihtsalt arusaam oma äriprotsessidest, kuna neid ei ole kaardistatud. Kuidas nii? Mul ju inimesed igapäevaselt toimetavad? Jah, inimesed võivad igapäevaselt ka enda väljakujunenud harjumuse järgi tööd teha aga see ei tähenda, et oleks olemas üldisem kokkulepe, kuidas me koos meeskonna/ettevõttena tööd teeme.

Minu arust on äriprotsesside kaardistamise kõige suurem väärtus justnimelt selles, et arutatakse läbi, kuidas me KOOS tööd teeme. Ja selle tulemina tekib kõikidel inimestel selgus oma rollist ja vastutusest. Protsessimudelid on lihtsalt üks viis, kuidas seda koostöö kokkulepet vormistada. Kui nüüd protsessimudeleid “vorbitakse” teha lihtsalt mudelite enda pärast, siis sellist kokkulepet ei teki ning nendest on vähe kasu.

Mis juhtub, kui mul ei ole enne süsteemi kasutusele võtmist äriprotsessid kaardistatud?

Üldjuhul juhtub see, et saad süsteemi, mis ei toeta sinu igapäevaseid äriprotsesse. See võib efektiivsuse tõstmise asemel kaasa tuua täiendavad sammud, mis hoopiski aeglustavad sinu äriprotsesside läbimist. Võibolla mõnel teist tekib küsimus “Kuidas? Tehnoloogia peaks ju täiustama meie äriprotsesse?”. Ega tehnoloogia üksi mingi võluvits ole! Ta saab sind aidata väga konkreetsetes töölõikudes väga konkreetsete ülesannetega. Ja selleks, et temast võimalikult palju kasu oleks, pead sa ikkagi ise paika panema, millised on need konkreetsed töölõigud 🙂 .

Endiselt arendatakse ja juurutatakse süsteeme, mille sisendiks ei ole äriprotsesside kaardistus. No tegelikult võib ju ka niipidi liikuda. Siis pead lihtsalt arvestama, et pead oma äriprotsessid paika panema süsteemi dikteeritud töövoogude järgi.

Selline lähenemine on väga tavapärane karbitoodete (nn off-the-self tarkvarade) puhul. Sinna on toodet arendanud firma loonud nö tavapäraselt esinevad töövood. See, millise metoodikaga need tavapäraselt esinevad töövood paika on pandud ning kui palju toote lõppkasutajate ideid on arvestatud, sõltub juba konkreetsest firmast. Mõni teeb seda paremini ja rohkem, kui teine firma. Selge on aga see, et tooted, mis on arendatud väga laiale sihtrühmale (nt. kõikidele tootmisettevõtetele üle maailma), ei saa kunagi olla sellised, mis sinu ettevõtte äriprotsessidega 1-1-le sobituvad. Ehk, kui valid karbitoote, siis pead olema valmis tegema teatud järeleandmisi oma ka äriprotsessides.

Loomulikult saab ka karbitoodet kohandada – see tähendab, et sinu vajadustest lähtuvalt arendatakse teatud moodulid ümber või tehakse juurde. Küll aga peab silma pidama, et kõik karbitootele juurde ehitatavad laiendused tõstavad edaspidise tarkvara haldamise keerukust ja maksumust.

Milliseid samme on vaja planeerida uue süsteemi loomisel või kasutusele võtmisel?

  1. Vahet pole, milline on sinu lähtepunkt, kaardista alati oma hetke olukorda kajastavad äriprotsessid (nö AS-IS äriprotsessid). Kui sa lähed tellima täiesti nullist rätseplahendust, siis on see lausa kohustuslik esimene samm! Kui sa kaldud pigem karbitoote poole, siis on see rangelt soovituslik esimene samm. See annab sulle arusaama oma äriprotsessidest ning sul on võimalik paremini hinnata, mil määral pakutav karbitoode sinu äriprotsessidega sobitub.
  2. Kui AS-IS äriprotsessid on kaardistatud, vaata need üle andmete liikumise vaatest. Millistes äriprotsessides ja milliste tegevuste juures andmeid luuakse, muudetakse, kustutatakse? Millised tegevused, millisest andmeallikast andmeid vajavad? Algselt võid kogu selle teadmise kirja panna oma protsessimudelile. Kui aga protsessimudel läheb liialt kirjuks, siis modelleeri igale äriprotsessile kõrvale eraldi andmete liikumise diagramm (ehk data-flow-diagram). Siin on oluline silma pidada, et mõlemal mudelil kasutad samu mõisteid! Muidu ei ole hiljem võimalik neid mudeleid omavahel kokku viia.
  3. Kui lähed arendama rätseplahendust, siis tuvasta võtmekohad, mida tahad oma AS-IS protsessis täiustada. Sest soovid ju lahendust, mis tulevikus sinu senist äriprotsessi parandaks! Äriprotsesside analüüsimisel on olemas samuti erinevaid nippe ja metoodikaid ning nendest olen kirjutanud ühes oma varasemas postituses.
  4. Kui oled otsustanud karbitoote kasuks, siis küsi karbitoote pakkujalt tema tootes realiseeritud äriprotsesside kohta kirjeldusi, protsessijooniseid, selgitusi. Ja võrdle seda infot enda AS-IS äriprotsessidega. Tuvasta, kui palju on neil protsessidel sarnasusi ja erisusi! Kui tuvastad, et sinule olulistes äriprotsessides (nt sinu ettevõtte põhiprotsessides) on erisusi palju, siis kaalu uuesti, kas karbitoode on ikka kõige õigem valik?
  5. Rätseplahenduse puhul modelleeri analüüsi tulemusena tekkinud ideede pealt tuleviku äriprotsess (nö TO-BE äriprotsess). Siin on oluline silmas pidada, et TO-BE äriprotsess peab samuti olema KOKKULEPE erinevate osapoolte vahel! See ei tohiks olla pelgalt mõne konsultandi või analüütiku ettepanek, vaid peab kajastama kõikide protsessiga seotud osapoolte kokkulepet.
  6. Karbitoote puhul lepi kokku, millised äriprotsessid juurutatakse tootes ettenähtud töövoogude põhjal ja milliste puhul on vaja tootele edasiarendust.
  7. Vastavalt paika pandud TO-BE äriprotsessidele hakka tarkvara arendust või toote juurutamist tellima.

Kui soovid rohkem teada protsessipõhisest juhtimisest 👉 https://kreetsolnask.podia.com/milles-seisneb-protsessipohine-juhtimine

Kui soovid õppida äriprotsesse kaardistama ja analüüsima 👉  https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus

Kui soovid minu mentorlust oma äriprotsesside kaardistamise ja analüüsi projektis 👉 https://calendly.com/event_types/43193181/edit?return_to=%2Fevent_types%2Fuser%2Fme

Jätkusuutlik tulevik AI ja protsesside automatiseerimise läbi

Jätkusuutlik ressursside kasutamine on märksõna, mis on kerkinud üha enam esiplaanile ning pannud inimesed/ettevõtted mõtlema, kuidas edasi? Kui inimkond jätkab samas tempos ressursside (maapõue ressursid, vesi, energia vms) kasutamist, siis ei ole üsna pea enam elu Maal võimalik. Steven Hawking on ennustanud, et aastaks 2600 on inimkond ülerahvastatuse ja priiskava energiatarbimise läbi muutnud Maa hiiglaslikuks tulekeraks, millel pole elu enam võimalik (allikas – https://www.cnbc.com/2018/03/15/stephen-hawking-predictions-human-extinction-to-global-warming.html) .

Jätkusuutliku tuleviku kujundamisel on meid ümbritseval tehnoloogial võtmetähtsus! Viienda tööstusrevolutsiooni valguses räägitakse palju generatiivsest tehisarust (Generative AI), küberfüüsilistest süsteemidest (Cyber-physical system), mis suurendavad oluliselt tootlikkust ja määratlevad ümber kliendikogemused erinevates sektorites, sealhulgas nutivõrkudes, IoT-s ja isesõitvates autodes.

Tehisaru potentsiaal ulatub lihtsast automatiseerimisest kaugemale. Sellel on võimekus põhjalikult ümber kujundada majandusmaastikku, muutes 350 miljoni töökoha olemust ja võimalik, et suurendades globaalset SKP-d kuni 7%. Vaja on mõttemaailma muutust selles, kuidas me töörolle tajume, rõhutades pideva õppimise ja kohanemise olulisust.

Kindlasti on mainitud tehnoloogiatel potentsiaali tõhustada meie igapäevast tööd AGA neid tehnoloogiaid peab oskama õigetes töölõikudes rakendada! Nimetatud tehnoloogiate üheks olulisemaks eelduseks on, et ettevõtete äriprotsessid on läbi mõeldud ja kaardistatud.

Kuidas astuda jõulisemaid samme äriprotsesside automatiseerimise suunas?

Kuulasin eile GBTECi “Process Days” nimelist üritust ja panen kirja mõned mõtted, mis sealt minu jaoks kõlama jäid 🙂 .

Inim- ja kliendikeskus

Äriprotsesside disaini etapis peab olema prioriteet nr.1 inim- ja kliendikesksusel! Kliendi teekonna kaardid, mis kajastavad kliendi kokkupuutepunkte ja neis esinevaid probleeme, peavad saama oluliseks töövahendiks ettevõtte äriprotsesside disainimisel. Ehk siis palju rõhutatigi seda, et äriprotsess ei saa olla disainitud pelgalt disaineri suva järgi. Vaid peab päriselt aru saama, kes on äriprotsessi klient ja millised on tema vajadused/ootused. Ainult siis on lootust, et luuakse kliendi- ja kasutajakeskseid äriprotsesse.

BPM tarkvara ja AI sümbioos

Erinevad äriprotsesside kaardistamist, analüüsimist ja automatiseerimist võimaldavad platvormid arendavad generatiivse tehisaru võimekust oma tarkvaradesse. Selline abimees saab sind aidata äriprotsesside kaardistamisel või automatiseerimisel. Näiteks loob ta sinu sisendteksti pealt ise protsessimudeli või nõustab reaalajas modelleerimisel tekkivate küsimuste korral. Nt GBTEC tarkvaras on olemas abimees nimega Arty, mis pakub reaalajas nõustamist, loob sinu antud kirjelduse pealt ise protsessimudeli, tõlgib vajadusel protsessimudeli teise keelde ja aitab protsessimudelites vigu tuvastada.

Koodivaba automaatika ehk innovatsiooni demokratiseerimine

Minu jaoks uus mõiste oli “Citizen Developer”, mille idee on selles, et teha koodi või skripti kirjutamine ka tavatöötajale jõukohaseks. Selleks on BPM tarkvaradesse integreeritud AI abilised, mis aitavad vajalikke koodijuppe kiirelt valmis kirjutada. Teine suund, millest palju räägiti on koodivaba automaatika ehk nö no-code või low-code platvormid (LCAP). Sellised platvormid võimaldavad mittetehnilistele inimestel koodi kirjutamata oma äriprotsesside töövoogusid automatiseerida. Kogu automatiseerimine on üles ehitatud platvormil olevate komponentide seadistamise peale. Antud lähenemine aitab vabastada ettevõtete IT üksuste töötajate tööaega ning anda äripoole inimestele vabamad käed ise oma töövoogude automatiseerimiseks.

Äriprotsesse toetavate süsteemide koostalitusvõime

Digitaliseeritud ja tarkvarapõhises maailmas on esmatähtis süsteemide sujuv koostalitusvõime ja protsesse toetavate rakenduste läbipaistvus. Koostalitusvõime tagamiseks on suurepäraseks vahendiks REST API liidestused. REST APId aitavad erinevaid süsteeme omavahel ühtseks äriprotsessiks siduda – võimaldavad reaalajas tööde staatuse info jälgimist ja teistele süsteemidele selle edastamist ning omakorda seotud süsteemidest andmete saamist ja sinna andmete saatmist.

Roheline protsessipõhine juhtimine

Esimest korda kuulsin sellist lähenemist nagu Roheline BPM (Green BPM). Selle mõte on, et äriprotsesse disainides ja täiustades tuleks meeles pidada ka jätkusuutlikkuse ja keskkonna aspekte. Ehk alati tuleks mõelda iga tegevuse jaoks vajalike materjalide ja ressursside keskkonnamõjule ning teiseks sellele, kuidas iga tegevust saaks optimeerida.

Kui soovid rohkem teada saada protsessipõhisest juhtimisest, siis minu aprillis toimunud veebiseminar on järelkuulatav siit –https://kreetsolnask.podia.com/milles-seisneb-protsessipohine-juhtimine .

Oma ettevõtte äriprotsesside kompetentsi tõstmiseks ja töötajate võimestamiseks on sobilik minu äriprotsesside kirjaoskuse koolitus –   https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Juhul, kui soovid äriprotsesside teemalist mentorlust, siis tule räägime – https://calendly.com/event_types/43193181/edit?return_to=%2Fevent_types%2Fuser%2Fme

II – Millisel protsessijuhtimise küpsusastmel asub sinu ettevõte?

Käesolev postitus on jätk minu eelmisele protsessijuhtimise küpsusastme postitusele. Antud postituses kirjutan täpsemalt lahti protsessijuhtimise 3-5 taseme tunnused ning annan mõned soovitused, kuidas sinna liikuda.

Tase 3 – Standardiseeritud

3.taset iseloomustab protsesside standardiseeritus. Kõik ettevõtte protsessid on kaardistatud ja dokumenteeritud kokkulepitud standardi (tavapäraselt BPMN) kohaselt. Protsessidest arusaamiseks ning nende järgi käitumiseks on ettevõttes läbi viidud koolitusi kõikidele töötajatele. Ettevõttes on vaikimisi kokkulepe, et kõik töötajad peavad kokkulepitud protsesside järgi toimetama. Eraldi jälgitakse seda, kas töötajad peavad kinni protsesside kokkulepetest.

Mõned tunnusmärgid, et ettevõte asub 3. tasemel:

  • Kõik ettevõtte töötajad on läbinud protsessijuhtimise teemalised koolitused;
  • Ettevõtte tiimide/meeskondade mõõdikutes kajastuvad ka protsessidega seotud mõõdikud;
  • Kõik töötajad, kes kaardistavad/täiustavad protsesse, kasutavad sama BPM töövahendit ja lähtuvad samast standardist (tavapäraselt BPMN);
  • Kõik töötajad, kes tarbivad protsesse, oskavad kasutada protsesside repositooriumi;
  • Protsessijuhtimist koordineeritakse keskselt;
  • Igale protsessile on määratud oma protsessi omanik, kes vastutab protsessi toimimise eest;
  • Protsesside täiustamist juhitakse keskselt;
  • Protsesside muudatuste juhtimist tehakse keskselt;
  • Kasutusel on mitteametlik protsessimudelite kvaliteedi tagamise protsess;
  • Kõik protsessimudelid asuvad ühtses protsesside repositooriumis.

Tase 4 – Ennustatav

4.taset iseloomustab ennustatavus. See tähendab, et protsessidest saavad tulemuste ennustamisel olulised abivahendid. BPM CoE (Center of Excellence) jälgib ja mõõdab, kas protsesse jälgitakse ning kui hästi need töötavad. Juhul kui protsessides esinevad probleemid või need töötavad oodatust halvemini, algatatakse uus protsessi täiustamise tsükkel.

Mõned tunnusmärgid, et ettevõte asub 4. tasemel:

  • Osa ettevõtte BPM meeskonna inimesi on akrediteeritud BPM arhitektid;
  • Ettevõtte tiimide/meeskondade mõõdikutes kajastuvad ka protsessidega seotud mõõdikud;
  • Kõik töötajad, kes kaardistavad/täiustavad protsesse, kasutavad sama BPM töövahendit ja lähtuvad samast standardist (tavapäraselt BPMN);
  • Ettevõtte juhtkond on vastutav protsesside haldamise eest;
  • Kõik protsessimudelid asuvad ühtses protsesside repositooriumis.
  • Protsesside omanikud juhivad aktiivselt enda vastutuse all olevaid protsesse;
  • Kõik ettevõtte protsessid on standardiseeritud;
  • Kõik töötajad, kes kaardistavad/täiustavad protsesse, kasutavad sama BPM töövahendit ja lähtuvad samast standardist (tavapäraselt BPMN);
  • Kõik töötajad, kes tarbivad protsesse, oskavad kasutada protsesside repositooriumi;
  • Protsesside muudatuste juhtimist tehakse keskselt;
  • Protsesse ei juurutata enne, kui need on läbinud kokkulepitud reeglitele vastava kvaliteedikontrolli;
  • Kõik protsessimudelid asuvad ühtses protsesside repositooriumis aga need on klassifitseerimata;

Tase 5 – Uuenduslik

5.tasemel asuva ettevõtte protsessid on optimeeritud ning protsesside pidev täiustamine on muutunud loomulikuks osaks ettevõtte igapäevases töös. IT lahendusi kasutatakse erinevate töövoogude ühendamiseks ning protsesside kvaliteedi ja efektiivsuse tõstmiseks.

Mõned tunnusmärgid, et ettevõte asub 5. tasemel:

  • Paljud ettevõtte BPM meeskonna inimesed on akrediteeritud BPM arhitektid;
  • Ettevõtte tiimide/meeskondade mõõdikutes kajastuvad ka protsessidega seotud mõõdikud;
  • Protsesside testimiseks ja katsetamiseks kasutatakse simulatsioone;
  • Protsessijuhtimist koordineeritakse keskselt (vastutab BPM Center of Excellence);
  • Protsesside muudatuste haldust juhitakse keskselt (vastutab BPM CoE);
  • Meeskonnad on omaks võtnud pideva täiustamise mõtteviisi;
  • Ettevõtte äriprotsesside arhitektuur on kihiline – st rakendatud on hierarhilist modelleerimist ning erineva detailsusega protsessimudelid asuvad erinevatel “kihtidel”;
  • Protsessimudelite ajakohasust ja protsesside toimivust auditeeritakse pidevalt;
  • AS-IS protsesside analüüsimiseks on võimalik kasutada protsesside kaevet (process mining);
  • Kõik protsessimudelid asuvad ühtses protsesside repositooriumis ja need on klassifitseeritud.

Kas märkasid, et IT lahendusi maniti alles viienda küpsusastme juures? Ja see on ka igati loogiline, kuna kõigepealt tuleb ikka oma protsessid paika saada ning seejärel hakata alles automatiseerima 🙂 .

Kui soovid rohkem teada saada protsessipõhisest juhtimisest, siis minu aprillis toimunud veebiseminar on järelkuulatav siit –https://kreetsolnask.podia.com/milles-seisneb-protsessipohine-juhtimine .

Oma ettevõtte äriprotsesside entusiastide koolitamiseks ja võimestamiseks on sobilik minu äriprotsesside kirjaoskuse koolitus –   https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Kui soovid äriprotsesside teemalist nõustamist või mentordamist, siis kirjuta mulle!

I – Millisel protsessijuhtimise küpsusastmel asub sinu ettevõte?

Vast olete kuulnud ütlust “Igal asjal on oma aeg”? See ütlus kehtib väga hästi ka protsessijuhtimise kohta (NB! mõtlen protsessijuhtimise nime all lühendit BPM (Business Process Mangement)). Ettevõtted, kes ei ole siiani tegelenud enda protsesside paika panemise, dokumenteerimise ja protsessidest teadlikkuse tõstmisega, tahavad äkitselt teada, milline on kõige parem tööriist oma protsesside haldamiseks. Mina ütleks selle peale “Hold your horses!“. Kõigepealt on vaja protsessijuhtimise mõtteviis juurutada ettevõtte kultuuris ja alles seejärel tulevad spetsiaalsed tööriistad, notatsioonid ja repositooriumid.

Käesolevas postituses puudutan protsessijuhtimise küpsusmudelit (BPM Maturity Model) , mille abil saab iga ettevõte enda küpsusastet määrata ning jagan ka mõned soovitused, kuidas järgmisele arengutasemele liikuda.

Joonisel ei ole kajastatud 0-taset, sest selles faasis ei ole ettevõtted endale isegi teadvustanud oma ettevõtte äriprotsesse ega ka seda, millist kasu annab nende kaardistamine. Samuti puuduvad seal inimesed, kes teaks midagi äriprotsesside kaardistamisest ja täiustamisest. Eestis on valdav osa mikro- ja väikeettevõtteid oma protsessijuhtimises alles 0-tasemel!

Soovitus: pange paika oma ettevõtte eesmärgid ja mõelge läbi reaalsed tegevused, kuidas sinna jõuate. Selle mõtteharjutuse tulemusena peaks tekkima arusaam oma ettevõtte põhiprotsessist/-protsessidest. Seejärel proovige seda arusaama, kuidagi kirja panna ja/või visualiseerida. Küsige sellele teiste meeskonnaliikmete arvamust/tagasisidet!

Tase 1 – Algeline

1.taset iseloomustab hästi kaootiline ja eesmärgipäratu tegutsemine. Sellel tasemel on ettevõttes teadvustatud vajadus saada paremini aru oma äriprotsessidest aga mingit juhitud süsteemi veel paigas ei ole. Ettevõttes on üksikud äriprotsesside entusiastid, kes modelleerivad näiteks enda töölõike ning selle tulemusena tekkivad protsessimudelid asuvad sellesama isiku arvutis. Tihti puuduvad isegi sama meeskonna üleselt kokkulepped, kuidas tööd tehakse, rääkimata siis kogu meeskonna tööd kajastavatest protsessimudelitest.

Mõned tunnusmärgid, et ettevõtte asub 1.tasemel:

  • Üksikud meeskonnaliikmed on kuulnud protsessijuhtimisest ja on seda teemat iseseisvalt uurinud (teadmiseks, et ka mina alustasin sellest punktist 🙂 );
  • Tekib vaikselt arusaam, et vaja oleks ühtset protsessijuhtimise metoodikat;
  • Protsesse “juhivad” need isikud, kes protsessimudelid lõid – nö isikupõhine juhtimine;
  • Mõned protsessid on juhuslikult dokumenteeritud;
  • Protsessijuhi mõiste puudub;
  • Protsesside kaardistamise ja täiustamise/standardiseerimise metoodika puudub;
  • Üldiselt ei kasutada protsessimudeli loomiseks mingit kindlat notatsiooni;
  • Protsessi muudatuste juhtimist ei toimu, muudatusi viiakse sisse ad-hoc printsiibil;
  • Protsessimudelite kvaliteedikontroll puudub;
  • Protsessimudelite hoidmiseks ei kasutata ühtseid tööriistu ega repositooriumi.

Soovitus: Ärge võtke ette liiga suurt ampsu! Näiteks võtke fookusesse mõni oma ettevõtte peamise toote või teenusega seotud protsess. Mõni selline, kus kõige rohkem king pitsitab 😉. Pange eesmärgiks läbi viia selle teenuse osutamise või toote loomisega seotud protsessi kaardistamine sellisel tasandil, et kõigil protsessis osalejatel tekiks arusaam oma rollist. Panustage inimeste koolitamisse, leidke üles enda ettevõtte äriprotsesside entusiastid ja võimestage neid. Kui selliseid inimesi ei ole, siis “kasvatage” need või värvake. Esimese “ampsu” edukal läbimisel, tutvustage seda algatust ettevõttes laiemalt, jagage õnnestumisi ja õppetunde.

Tase 2 – Juhitud

2.taset iseloomustab juba juhitum lähenemine, milles meeskonna/tiimi tasandil pannakse projektipõhiselt paika ühised protsessid. Seda selleks, et sama töölõiku tegevad töötajad oskaksid üksteisega arvestada ja projekt jõuaks eduka lõpuni. Protsesside täiustamine on endiselt jäetud äriprotsesside entusiastide pärusmaaks ja kui seda tehakse, siis sellest dokumentatsiooni näol mingit märki maha ei jää. Protsessijuhtimise teemal on mõnda üksikut inimest koolitatud aga ettevõttes läbivat ja süsteemset koolituskava ei eksisteeri.

Mõned tunnusmärgid, et ettevõtte asub 2.tasemel:

  • Teatud hulk inimesi on läbinud protsessijuhtimise teemalisi koolitusi;
  • Projektipõhiselt jõuvad protsessijuhtimise tegevused ka töötajate ametijuhenditesse;
  • Koolituse läbinud meeskonnaliikmed kasutavad sama BPM tööriista;
  • Protsessi muudatuste juhtimine toimub (projekti)meeskonna siseselt;
  • Protsesse dokumenteeritakse samast standardist lähtuvalt (tavapäraselt BPMN);
  • On tekkinud nö mitteametlikud protsessijuhid;
  • Protsesside kaardistamise ja täiustamise/standardiseerimise metoodika on juhuslik – igaüks teeb nii nagu heaks arvab;
  • Valikuliselt kontrollitakse protsessimudelite kvaliteeti;

Soovitus: Panustage inimeste koolitamisse, leidke üles enda ettevõtte äriprotsesside entusiastid ja võimestage neid. Andke äriprotsesside entusiastidele vastutusrikkamaid ülesandeid – nt ettevõtte protsesside kaardistamise ja täiustamise metoodika paika panemine. Laske neil analüüsida ettevõtte vajadusest ja ressurssidest lähtuvaid erinevaid BPM tööriistu ja valige välja enda ettevõttele sobiv. Kujundage äriprotsesside entusiastidest enda ettevõtte protsessijuhid. Tehke tööd juhtkonnaga – selgitage neile laiapindsema protsesside kaardistamiseks ja täiustamise vajalikkust. Planeerige rahastus – ühelt poolt laiemalt enda inimeste koolitamiseks ning teisalt protsesside kaardistamisse ja täiustamisse konsultantide näol lisaressursi kaasamiseks.

Kõige suurem arenguhüpe on 2.tasemelt 3.tasemele liikumine, sest 3.tasemel peaksid senini läbiviidud tegevused hõlmama juba laiemalt kogu ettevõtet. Selle arenguhüppe õnnestumisel on võtmetähtsusega juhtkonna tugi – kas juhtkond on pardal ja on nõus ettevõttes laiemalt protsesse kaardistama ja liikuma protsessipõhise juhtimise poole? Kui vastus on jah, siis klaaslage ees ei ole ja suure tõenäosusega arenguhüpe õnnestub läbi viia. Kui vastus on ei, siis tuleb veel juhtkonnaga tööd teha niikaua, kuni see arusaam tekib ja klaaslagi saab purustatud.

Kui soovid ise rohkem teada saada protsessipõhisest juhtimisest, siis tule kuula minu 9.aprillil toimuvat veebiseminari! Registreeruda saad siin – https://kreetsolnask.podia.com/milles-seisneb-protsessipohine-juhtimine .

Oma ettevõtte äriprotsesside entusiastide koolitamiseks ja võimestamiseks on sobilik minu äriprotsesside kirjaoskuse koolitus –   https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

3.-5. küpsustasemest kirjutan juba järgmises blogipostituses! 😉

Mida annab meile teadlikkus oma äriprotsessidest?

Käesoleva blogi kõige esimeses postituses kajastasin seda, miks on äriprotsesse vaja ja mida annab nende kaardistamine. Hetkel on tunne, et vahepeal möödunud 2 aasta jooksul on minu kogemustepagas mõnevõrra täienenud ning antud teemat oleks vaja värskete mõtetega uuesti käsitleda. Seega on antud blogipostituse fookuses taaskord seesama küsimus, et mida ikkagi annab meile teadlikkus oma äriprotsessidest?

Kindlasti olete erinevates valdkondades kohanud jäämäe analoogiat, milles jäämäe tipp visualiseerib seda kõige nähtavamat osa. Samal analoogial põhineva visualiseeringu tegin ka protsessipõhise juhtimise kohta. Tihti arvatakse, et protsessipõhine juhtimine võrdubki protsesside kaardistamisega.

Kuna protsessimudelid on selle tegevuse kõige tajutavam tulem, siis on isegi mõistetav, miks nii arvatakse. Samas ei ole mõistlik protsesse kunagi kaardistada lihtsalt selle tegevuse enda pärast! Peaks olema sügavam põhjus, miks seda tehakse. Ja needsamad sügavamad põhjused asuvadki nö “veepinna” all. Mida sügavamal need asuvad, seda vähem neid teadvustatakse.

Strateegiate elluviimine

Arusaam oma äriprotsessidest on tegelikult üks olulisemaid strateegiate ja eesmärkide elluviimise eeldusi! Minu silmis on äriprotsessid eesmärgist lähtuvalt disainitud teekonnad, mis aitavad jõuda punktist A punkti B. Need aitavad lahti mõtestada, KUIDAS oma eesmärkideni jõuda! Ja hästi disainitud protsessid teevad seda vägagi edukalt.

Näiteks võib mul olla isiklik eesmärk kasvatada käesoleva aasta lõpuks oma igakuist passiivset sissetulekut 500 eurole. Selleks panen paika strateegia, et teen seda enda veebikoolituste müümise kaudu. Selle eesmärgini jõudmiseks, panen enda jaoks paika ajaraami, mille jooksul seatud eesmärgi poole rühin. Ja ka tegevused, mis ma selle eesmärgi saavutamiseks tegema pean. Teisisõnu disainin endale äriprotsessi, mida sihikindlalt jälgima hakkan.

Tundub ju loogiline, eks? Aga mida ikkagi annavad siin protsessimudelid? Oletame, et pandud eesmärgi saavutamine läheb väga libedalt ja on näha, et turul on nõudlust minu veebikoolituste järele. Järgmine samm on veelgi suurema eesmärgi seadmine, mille ellu viimiseks ei piisa enam ühest inimesest. Olen jõudnud punkti, kus ma pean oma koolitusäri kasvatamiseks, võtma tööle täiendavaid inimesi. Ja vot sel hetkel, kui pead hakkama oma ülesandeid kellelegi delegeerima, on protsessimudel üks tänuväärne töövahend. Sa oled protsessimudeli näol dokumenteerinud kogu kvaliteetse teenuse loomise ja pakkumise protsessi ning see on väga hea materjal, mille abil uus inimene kiiresti “pardale” tuua.

Ettevõtte igapäevane juhtimine

Öeldakse, et head spetsialistid ei pruugi olla head juhid. Ometi ootame oma juhilt, et ta saaks aru meie igapäevastest tegevustest ja oskaks vajadusel nõu anda. Mina näen, et spetsialistist juhi tegemine ei olegi alati see kõige õigem lahendus. Vaja on vaid juhile piisavalt hästi selgeks teha, millega tema inimesed igapäevaselt tegelevad. Ja sellist arusaama aitavad jällegi väga hästi luua protsessimudelid. Need on justkui visuaalsed teekaardid, mis aitavad igapäevastes tegevustes orienteeruda ja annavad otsustamisel vajalikku taustainfot.

Ettevõtetes on tavapäraselt ikka sadu erinevaid äriprotsesse, mille kaasabil mingeid tooteid või teenuseid luuakse ja müüakse. Kogu selle “masinavärgi” hoomamine võib ühe korraliku kaardita olla paras väljakutse. Protsessimudelid tulevad siingi abiks. Oma protsesside visualiseerimine mudelina ning erinevate mudelite omavaheline linkimine annab sulle suunataju, sisuliselt GPSi, millega protsessiderägastikus õigesse kohta navigeerida.

Digitaalse transformatsiooni läbiviimine

Kui keegi mainib sõnapaari “digitaalne transformatsioon”, siis tavaliselt mõtleb ta selle all vajadust panna oma ettevõtte tehnoloogia (IT süsteemid, robotid, AI jne) kaasabil efektiivsemalt toimima. Minu eelnevalt toodud veebikoolituste näites võib digitaalne transformatsioon tähendada näiteks seda, et AI või spetsiaalsed IT lahendused aitavad mul veebikoolitusi kiiremini koostada.

Mida aga tihti ei tajuta on see, et enne tehnoloogia rakendamist on vaja väga hästi aru saada, kuhu ja mille hüvanguks seda rakendada on vaja. Siin tulevad taaskord mängu äriprotsessid, mille AS-IS (ehk olemasoleva) olukorra kaardistus annab ette pildi, kus on üldse mõttekas tehnoloogiat efektiivistamisel kasutada. Veebikoolituse näite puhul võiks AI kaasa aidata koolitusvideo automaatsel töötlemisel või koolituskava koostamisel. Ehk siis panen väga täpselt paika, millistes äriprotsessi sammudes ootan tehnoloogia tuge.

Seega kui mõne digitaalse transformatsiooni raames on plaanis äriprotsesse automatiseerida, siis see on esimene indikatsioon selle kohta, et kõigepealt on vaja AS-IS äriprotsesse kaardistada. Ja kindlasti on oluline määrata see fookus, kuhu tehnoloogiat rakendada plaanitakse.

Meeldiva töötajakogemuse kujundamine ja inimeste võimestamine

Oleme palju kuulnud kliendikogemusest aga mis on töötajakogemus?

“Töötaja vaatest on töötajakogemus lihtsalt reaalsus, mida nad kogevad organisatsioonis töötades. Töötajakogemuse moodustavad kõik kokkupuuted tööandjaga alates kandideerimise protsessist, kõigest, mis töökohal juhtub, kuni organisatsioonist lahkumiseni. Igal töötajal on individuaalne töötajakogemus.” (allikas – Brightera veebileht).

Kui kliendikogemuse vaatest on võtmetähtsusega kliendi teekond ehk protsess, mida ta teatud toote või teenuse tarbimiseks läbima peab, siis sama võiks kehtida ju ka töötajakogemuse puhul? Kindlasti on hea töötajakogemuse kujunemisel palju erinevaid tegureid aga mina näen, et üks võtmeteguritest on teadlikkus ja selgus ettevõtte äriprotsessides. Ilmselt meist kellelegi ei meeldiks töötada ettevõttes, kus eesmärgid ei saa täidetud, sest puudub kokkulepe, KUIDAS neid täita? Või sa pead igapäevaselt tegelema ainult ad-hoc “tulekahjude” kustutamisega?

Loen hetkel raamatut nimega “Äriilma mässulised”, mis kajastab väga mitmetes organisatsioonides läbiviidud vaatlusi ja nende pealt on näha, et tavapärased juhtimismudelid enam ei tööta! Ettevõtted peavad töötajate tööle meelitamiseks ja seal hoidmiseks üha enam panustama töötajakogemuse tõstmisele.

John Maxwell on kunagi öelnud “Juhid saavutavad suurepärasuse mitte lähtuvalt oma võimust, vaid võimekusest võimestada teisi“. Palju räägitakse sellest, et inimesi saab võimestada neid usaldades ja neile vastutust andes. Nagu juba eespool mainitud, siis võivad protsessimudelid olla väga head tööriistad vastutuse delegeerimisel. Samuti saab inimesi võimestada hästi disainitud nö inimkesksete protsesside kaudu. Näiteks võiksidki juhid delegeerida ainult eesmärke ning iga töötaja paneb sellest lähtuvalt paika enda töövoo, kuidas ta eesmärgid saavutab. Nii jõuame lõppkokkuvõttes inimkesksete protsessideni, mis oma olemuselt juba võimestavadki inimesi.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele käigus õpetan, kuidas häid äriprotsesse disainida –  https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Minu õppetunnid äriprotsesside kaardistamise projektidest

Eksimine on inimlik!Keegi meist ei ole täiuslik ja me kõik teeme vigu!

Sattusin hiljaaegu lugema ühte raamatut, milles tutvustati Jaapani kultuuriruumist tulenevat Hansei mõistet. Hansei tähendabki protsessi, mille käigus õpitakse oma vigadest, selleks et järgmisel korral parem olla. Hansei protsessi üheks võtmekomponendiks on tagasivaate koosolekud (hansei-kai), mille käigus analüüsitakse, mis läks hästi ja mis halvasti. Sellest raamatust inspireerituna mõtlesin kirjutada postituse vigadest, mida mina olen erinevates protsessikaardistuse projektides teinud. Ning muidugi ka sellest, mida ma nendest vigadest õppisin 🙂

Õppetunnid äriprotsesside kaardistamisest

1. õppetund

Kui sa õigel hetkel õigeid inimesi (seotud osapooli) ei kaasa, siis võib kõige halvemal juhul olla “rong juba läinud”. Iga äriprotsesside kaardistamise projekt on oma olemuselt ka muudatuste juhtimine ning õigel ajal õigete inimeste kaasamine on edu saavutamisel võtmetähtsusega!

Iga äriprotsesside kaardistamise ja optimeerimise projekt on samaaegselt ka muudatuste juhtimise projekt. Seega on oluline siin arvestada muudatuste juhtimise põhitõdedega. Üks kõige olulisem põhimõte on see, et muudatus peab kõigepealt toimuma isiklikul tasandil (loe täpsemalt siit) . Ehk siis protsessiga seotud inimesed peavad olema valmis ise muutuma ja neil peab olema valmisolek muudatusega kaasa minna.

Esimese asjana on sul vaja välja selgitada, keda ja millisel hetkel on vaja kaasata. Seega on vaja läbi viia seotud osapoolte ja nende huvide analüüs. Kel kohe huvi, siis saab siit inglise keeles selle kohta lugeda. Plaanin lähitulevikus selle kohta eraldi postituse ka teha. Nüüd selleks, et saada inimesed endaga “samasse paati”, on vaja nendega inimlikult suhelda, vajadusel neid toetada ja nõustada. Võimaluse korral praktiseeri näost näkku suhtlust!

Seotud osapoolte vähene kaasamine on probleemiks just suuremate/ keerulisemate äriprotsesside puhul. Mainitud protsessidel võib seotud osapooli olla nii palju, et silme eest läheb kirjuks. Sellistel puhkudel on alati kiusatus mõni vähemtähtis osapool välja jätta aga seda ei tasuks teha, sest just nemad võivad saada komistuskiviks hilisemas protsessi juurutamise etapis.

2. õppetund

Dokumentatsioon (juhendid, süsteemi kirjeldus, analüüsid, lepingud, seadusandlus vms) peegeldab teatud hetke seisu ning võib olla lugemise hetkeks vähemal või suuremal määral aegunud. Samuti on see alati kirjutatud teatud eesmärki või vaadet silmas pidades, mis ei pruugi kattuda sinule vajaliku vaatega. Seega on mõistlik alati selle sisusse kriitiliselt suhtuda ja see õigete inimestega üle valideerida.

Minu äriprotsesside kaardistamise töövoos on tavaliselt esimeseks sammuks olemasoleva dokumentatsiooniga tutvumine. Seda teen ma selleks, et saada paremat ülevaadet konkreetse ettevõtte ärispetsiifikast ning, et ennast paremini kaardistamise töötubadeks ette valmistada. Tegelikult on minul mainitud esimese sammuga seoses isegi mitu õppetundi:

  • Esimene on see, et tuleb alati silmas pidada, et lepingud on ikkagi eelkõige juriidilised konstruktsioonid ning päriselu ei pruugi alati lepingu järgi toimida. Mul oli kunagi üks kaardistuse projekt, milles kliendi töötajad ütlesid, et teevad oma tööd nii nagu lepingus on kirjas. Sai siis selle järgi ka esimesed protsessimudelid tehtud, kuni selgus, et tegelikkus oli natuke teistsugune.
  • Teine õppetund on see, et erinevaid analüüse/süsteemide kirjeldusi aluseks võttes, tuleb alati arvestada, et need ei ole peaagu kunagi ajakohased! Need on üldjuhul ajakohased ainult sel hetkel kui need valmivad.

Nimetatud õppetundidest võtsin kaasa selle, et ei tohiks eeldada, et lepingud kajastavad päriselu või et erinevatest dokumenditest saan kätte kõige ajakohasema info . Alati tuleb kõik kahtluse alla seada ja protsessiga seotud inimestega tekkinud küsimused üle täpsustada.

3. õppetund

Intervjuudel/töötubades jälgi põhimõtet, et küsitled eri valdkondade ja eri hierarhiatasemel olevaid inimesi eraldi.

See on teadmine, mida igale analüütikule koolipingis õpetatakse, aga seda ei taha keegi usukuda enne kui on ise kõrvetada saanud. Minul on olnud kogemus ühe rangelt hierarhiatasemeid jälgiva organisatsiooniga, kus proovisin pingelise ajagraafiku tõttu intervjuusid kombineerida. See päädis sellega, et intervjuudel kõik inimesed oma arvamust avaldada ei julgenud ning lõpuks pidin vajaliku info kättesaamiseks ikkagi veel täiendavaid intervjuusid tegema. Ehk siis vahel võib aja kokkuhoid olla lihtsalt näiline ja ei tasu minna lihtsama vastupanu teed!

Nimetatud õppetundi olen mina kogenud pigem hierarhiliste organisatsioonide juures. Samas võib see esineda vabalt ka vähem hierarhilises organisatsioonis. Määravaks saab see kui mugavalt ettevõtte inimesed end üksteise seltskonnas tunnevad.

4.õppetund

Ära eelda, et sinu protsessimudeleid ja/või kirjeldusi oskavad kõik lugeda! Mina olen õppinud, et iga äriprotsesside kaardistamise projekt on ühtlasi ka protsessidega seotud inimeste koolitamise projekt. Kui sa tahad, et keegi oskaks hiljem ka mudelisse modelleeritud tarkust kasutada, siis on vaja panustada inimeste koolitamisse.

Jällegi oleks lihtsam ja kiirem protsessimudelid valmis joonistada ning kliendile lihtsalt üle anda. Antud stsenaariumi lõpeb tavapäraselt sellega, et need mudelid leiavad oma koha kusagil “sahtlipõhjas” ja keegi neid aktiivselt kasutama ei hakka. Võibolla olete kuulnud Pareto prinsiibist, mis ütleb, et 20% panust toob 80% tulemusi? Vot siin ongi selle 20% panuse koht – protsessidega seotud inimeste koolitamine, annab tulemuseks selle, et nad oskavad hiljem mudelisse modelleeritud tarkust ka kasutada.

Mina vaatan igat äriprotsesside kaardistamise projekti teekonnana, mille käigus tekib teekonnale kaasatud inimestel arusaam oma rollist ja kuuluvusest ettevõtte ökosüsteemis. Nagu misiganes teekonnal, tuleb ka sellel ette komistuskivisid, millest midagi õppida. Ja seda ikka selleks, et järgmisest komistuskivist juba teadlikumalt mööduda.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele käigus jagan enda õppetunde erinevatest projektidest –  https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Hetkel on samuti välja töötamisel koolitus targale tellijale, mille käigus mõtestatakse lahti vajalikud eelteadmised ja oskused IT projektide juhtimiseks ning õpetatakse, millisel tasemel ja detailsusega analüüsi võiks üks tark tellija ise osata teha. Kui tahad selle koolituse kohta rohkem infot, siis võta minuga julgelt ühendust!

Iga analüüsiprotsess on oma olemuselt agiilne

Seekordset postitust tundub paslik alustada ühe väga tabava tsitaadiga:

Analysis sounds like something that just kind of happens through staring at requirements long enough

“Software Requirements Essentials” Karl wiegers, candase hokanson

See tsitaat on väga tabav ja kirjeldab minu arust üsna täpselt seda, kuidas analüüsi tegevust laiemalt mõistetakse. Teine väärarusaam on see, et analüüs koosnebki ainult intervjuude läbiviimisest ja nende põhjal memode kirjutamisest. Käesolevas postituses avan natuke analüüsi läbiviimise tööprotsessi ehk seda, millistest etappidest see koosneb ning millised on iga etapi tavapärased tegevused. Natuke teise nurga alt olen analüütiku tööprotsessist kirjutanud ka ühes oma varasemas blogipostituses.

Tuvastamise etapp

Inglise keeles on sellel etapil palju kõnekam nimetus kui eestikeelne tuvastamine. Elicitation tähendab otsetõlkes esile tooma või välja meelitama ning tegelikult annavadki need tegusõnad väga hästi edasi seda mõtet, mida analüütik antud etapis tegema peab.

Seotud osapoolte peades on väga palju erinevate nõuete fragmente – näiteks mingi kindel visioon konkreetsest kasutajaliidese kuvast või konkreetsete andmete kirjeldused, mida neil vaja on või hoopis rahulolematus/probleemid oma praeguse süsteemi/tööprotsessiga. Sellised fragmendid ei ole tihtilugu ei struktureeritud ega ka terviklikud, mis tähendab, et nõuete formuleerimiseks peab analüütik nendega veel vaeva nägema.

Seega võiks öelda, et nõuete kogumine on ainult üks tegevus nõuete tuvastamise etapist. Lisaks kuuluvad sinna sellised tegevused nagu uurimine, avastamine ja leiutamine. Analüütik peab suutma väga erinevate töövõtete abil endale selgeks teha, millist probleemi lahendatakse ja milline võiks olla tellija jaoks rahuldustpakkuv lahendus. Lisan ka mõned enimkasutatavate meetodite märksõnad – dokumentide analüüs, protsesside kaardistamine ja analüüs, andmekaevandamine, kasutajaliideste analüüs, intervjuud ja fookusgrupid, kasutajate vaatlus, ajurünnak. Konkreetse meetodi valik sõltub sinu sihtrühmast, projekti ajakavast ja eelarvest, projekti arendusmeetoodikast jne.

Analüüsimise etapp

Nõuete tuvastamise etapis kogutud, avastatud ja välja uuritud info vajab nüüd süsteemset ja parimatest praktikatest lähtuvat korrastamist. Mida siis analüüsimise tegevus ikkagi endast kujutab? Analüüsimine on sisuliselt kogutud info klassifitseerimine, filtreerimine, sorteerimine, visualiseerimine ning info omavaheline võrdlemine. See annab analüütikule võimaluse kontrollida, et kogutud info on omavahel kooskõlas ja et tal ei ole midagi kahe silma vahele jäänud.

Analüüsimise etapi tulemina võivad tekkida nõuete kirjeldused, mis on kujutatud, kas tekstiliselt või mudeli kujul või hoopis prototüübina. Siinkohal tahan igaks juhuks üle rõhutada, et ei ole olemas ühte notatsiooni, mis kataks kõikide erinevate info esitamise viiside vajadused. Väga kummaline on vahel analüüsi tellinud osapoole nõuetest lugeda, et kõik mudelid peavad olema koostatud UML (Unified Modelling Language) notatsioonis. Samas kui äriprotsesside modelleerimiseks on soovituslik kasutada üldse BPMN-i (Business Process Management Notation) või andmevoogude visualiseerimiseks DFD-d (Data Flow Diagram).

Kogutud info analüüsimise abil kontrollib analüütik, kas kõikide seotud osapoolte vajadustega on arvestatud ning kas on olemas kokkulepe kõiki nõudeid rahuldava lahenduse osas. Eelmises lauses on üks olulisemaid sõnu “kokkulepe” – see eeldab, et misiganes esitlusviisil kirja pandud nõuded on ka tellijaga valideeritud ning saadud tema kinnitus.

Määratlemise etapp

Antud etapi vajalikkust annab edasi järgnev tsitaat:

However, the cost of recording knowledge is small compared to the cost of acquiring that knowledge or reacquiring it in the future.”

“Software Requirements Essentials” Karl wiegers, candase hokanson

Väga levinud väärarusaam on see, et agiilses arenduses dokumenteeritakse võimalikult vähe ning dokumentatsiooni nõudmine on justkui vananenud praktika. Mina olen seisukohal, et dokumentatsioon on oluline kommunikatsioonivahend ning see kajastab mingi hetke seisu tellija ja arendaja vahelisest kokkuleppest. Ausalt öeldes ei ole minu pea küll prügikast, et suudan sinna kõik kokkulepped ja nüanssid salvestada ning hiljem neid väikse vaevaga meenutada. Mul on oma mälumahuga parematki teha, kui seda sellel eesmärgil kasutada.

Mõned soovitused spetsifikatsiooni kirjutamisel:

  • Lähtu nõuete kirjeldamisel samast stiilist ja detailsusastmest ning mõtle läbi, milline esitlusviis annab kõige paremini edasi nõude/nõuete olemust;
  • Organiseeri nõuded struktuurselt ja lugeja jaoks loogiliselt – loo endale nõuete kirjeldmise mallid, mida saad erinevates projektides taaskasutada;
  • Ära unusta välja selgitada ja kirjeldada ärireegleid (business rules);
  • Loo nõuete arusaadavuse suurendamiseks sõnastik.

Kinnitamise etapp

Nõuete kinnitamise etapis hinnatakse, kas kirjapandud nõuded tegelikult ka rahuldavad tellija vajadusi ning kas need aitavad kaasa äriliste eesmärkide saavutamisele. Selle etapi olulisust tihti alahinnatakse ning pingelises projektiplaanis on selle etapi ärajätmise ahvatlus suur. Mida ei mõisteta on see, et selles etapis vigade avastamine ja nende parandamine on mitmeid kordi odavam, kui mõnes hilisemas etapis.

Arendusmeeskonna liikmed saavad kontrollida nõudeid (verification) – st hinnata, kas midagi realiseeriti õigesti. Tellija meeskonna liikmed saavad kinnitada nõudeid (validation) – st hinnata, kas tehti üldse õiget asja. Mõlemad sammud on vajalikud ja nende läbiviimiseks on erinevaid võimalusi. Kontrollimiseks on väga efektiivne töövorm teise sama rolli kandva isiku poolt tehtud töö üle vaatamine (nn. peer-review, code-review jne). Kinnituse saamiseks on minu arust kõige sobivam meetod koos tellijaga kinnitamist vajavate nõuete läbikäimine ning selle raames tellija kinnituse küsimine. Kirja teel kinnituse küsimine võib päädida sellega, et sinu kirja ignoreeritakse või ei saada täpselt aru, millele kinnitust on vaja.

Kosemudeli stiilis analüüsi protsessi ei ole olemas!

Nagu postitusele lisatud protsessiskeemilt näha, siis saab analüüsi protsessis peaagu igast etapis liikuda tagasi eelmisesse etappi ning see on igasuguse analüüsi puhul täiesti normaalne töövoog. Räägitakse küll arendusprojektidest, mis järgivad kosemudelit (waterfall) aga isegi sellistes projektides ei ole võimalik kõiki detaile ette analüüsida. Kuna tellija teadlikkus ajas kasvab ja tema nõuded muutuvad, siis tuleb isegi väga detailselt ette defineeritud analüüsis kindlasti ette muutmisvajadusi.

Muutmisvajadused võivad selguda:

  • Kui analüütik on hakanud nõudeid analüüsima (st grupeerima, korrastama, võrdlema), siis võib tulla välja, et mingid nõuded on üldse kogumata ning peab minema tagasi nõuete tuvastamise etappi;
  • Kui nõuded on spetsifikatsioonina kirja pandud, võib selguda, et mingid nõuded on analüüsimata või kogumata ning peab minema tagasi, kas nõuete analüüsimise või tuvastamise etappi;
  • Kui toimub nõuete kontrollimine ja kinnitamine, võivad selguda asjaolud, mistõttu võib olla vajadus minna tagasi, kas nõuete tuvastamise, analüüsimise või määratlemise etappi.

Koostöös IT koolitusega olen läbi viimas äriprotsesside kirjaoskuse teemalist koolitust, millele käigus õpetan täpsemalt, kuidas tööprotsesse kaardistada ja optimeerida –  https://koolitus.ee/koolitused/9756/koolitus-ariprotsesside-kirjaoskuse-koolitus.

Hetkel on välja töötamisel ka koolitus targale tellijale, mille käigus mõtestatakse lahti vajalikud eelteadmised ja oskused IT projektide juhtimiseks ning õpetatakse, millisel tasemel ja detailsusega analüüsi võiks üks tark tellija ise osata teha. Kui tahad selle koolituse kohta rohkem kuulda, siis võta minuga julgelt ühendust!

Minu lõppeva aasta tähelepanekud tarkvaraarenduse projektidest

Seekordse postituse fookuses ei ole kitsalt äriprotsessid, vaid see kajastab laiemalt minu lõppeva aasta õppetunde ja tähelepankuid tarkvaraarenduse projektidest.

Käesoleva aasta lõpp tähistab minu jaoks mitme suure ja pikaajalise projekti lõppu ning tunnen, et on aeg tagasi vaadata ja panna kirja oma tähelepanekud. Etteruttavalt pean kurvastusega tõdema, et mõned tähelepanekud on täpselt samad, mis enam kui 10 aastat tagasi oma esimest tarkvaraarenduse projekti läbi viies.

Tähelepanek nr 1- Agiilsus ei tähenda planeerimatust ja lohakat tegutsemist

Agiilsus on tarkvaraarenduse projektides endiselt üks väga oluline mõiste. Iga tellija tahab oma tarkvara lasta arendada agiilselt, enamjaolt võrdsustatakse agiilsust paindlikkusega. Ometi ei mõisteta tihti, mis on selle mõiste taga ja seda kiputakse väärkasutama. Paljude arendusfirmade jaoks on see lihtsalt sõnakõlks, mida lisada oma pakkumusse lihtsalt sellepärast, et tellija tahab seda seal näha. Ja kui projekt pihta hakkab, siis ei ole agiilsest mõtteviisist ega arendusmetoodikast halli haisugi. Agiilsuse sildi taha peidetakse planeerimatust, lohakat ja läbimõtlematut tegutsemist ja kompetentsi puudumist. Väga hästi võtab minu tähelepanekuid kokku Merle Randleppa blogipostitus agiilsest mõtteviisist ja müütidest. Oma viimaste projektide kogemuste põhjal võin kinnitada, et müüdid nr 1, 4, 5 ja 6 on arendusprojektides väga visalt kanda kinnitanud.

Tähelepanek nr 2- Riigihankes kannatab paber kõike

Kui ma ise mõnda aega tagasi erasektoris töötasin ja erinevatele hangetele pakkumusi koostasin, siis ringlesid kuulujutud, et osad firmad “kirjutavad” oma pakutavale meeskonnale kompetentse, mida neil tegelikult ei ole. Tookord ei võtnud ma seda kuigi tõsiselt ja mõtlesin, et see on lihtsalt kuulujutt või liialdus…kuni tänaseni. Olles ise olnud taas tellija poolel, olen kahjuks pidanud korduvalt tõdema, et seda siiski tehakse ja isegi väga nahhaalselt. Olen korduvalt näinud, et arendusfirma meeskonna rollidel ei ole olnud küsitud rollile kohaseid elementaarseid baasoskuseid ja/või kogemusi. Ometi on tellija justnimelt selle ettevõte kasuks otsustanud heas usu, et tal on vajalik kompetents olemas. Pakkumustesse kirjutatakse tõepoolest kokku igasugust mulli – peaasi, et klient uskuma jääb.

Tähelepanek nr 3- Testimine on osa korralikust arendusmetoodikast

Siinkohal on paslik tuua näide viimasest “agiilsest” arendusprojektist. Arendusfirma väitis, et spetsifikatsiooni loomine enne arendust ei ole agiilse arendusmetoodika osa ja nemad seda ei tee. See oli minu jaoks väga kummaline väide, kuna esiteks on nõuete fikseerimine spetsifikatsiooni kujul kokkulepe tellijaga, mille põhjal toimub hiljem ka testimine ning tööde vastuvõtmine. Samuti meenus mulle ülikoolist õpitud V-mudel, mille järgi on spetsifikatsioon üks-ühele seotud erinevate testimise liikidega.

Ma üritasin pihta saada loogikale, kuidas toimub testimine kui spetsifikatsiooni ei looda. Ja ma ei pidanud kaua pead murdma kui selgus, et meeskonda pakutud testijal ei olnud õrna aimugi minu viidatud seosest. Muuhulgas laekusid esimeste etappide tarned meieni täiesti testimata. Hoolimata sellest, et testimine võiks olla iga endast lugupidava arendusfirma kvaliteedi tagamise protsessi osa, pidime seda edaspidi neile pidevalt meelde tuletama.

Tähelepanek nr 4 – Äriprotsessidest arusaamine on suure pildi mõistmisel väga oluline

Selleks, et arendada kliendile head lahendust, peab kõigepealt mõistma, kuidas ta toimetab (AS-IS tööprotsessid) ning millised on tema praegustes töövoogudes valupunktid (selle info pinnalt disainitakse TO-BE tööprotsessid). Sellise infota ei ole võimalik mõista suurt pilti ning luua lahendust, mida klient päriselt vajab. Jällegi oli minu hämmastus suur kui arendusfirma pakkus meeskonda analüütikut, kes ei suuda aru saada äriprotsessidest (rääkimata oskusest neid kaardistada ja optimeerida) ning mõista kasutuslugude olulisusest tellija ärireeglite ja nõuete talletamisel.

Teine suur komistuskivi, millest ma ei väsi rääkimast ja mida korduvalt tehakse, on AS-IS tööprotsesside kohene automatiseerimine. See on kõige suurem karuteene, mida võib ühe infosüsteemi arendamisel teha. Enne tööprotsessi automatiseerimist tuleb AS-IS tööprotsess disainida võimalikult mõistlikuks. Sellest olen pikemalt kirjutanud eraldi blogipostituses.

Tähelepanek nr 5 – Spetsifikatsioon on kommunikatsioonivahend, mitte tüütu kohustus

Minu kui analüütiku jaoks, on olnud tarkvaraarenduse projektides üks tulemuslikumaid tööriistu hästi arusaadav spetsifikatsioon. Sellele küsin alati tellija kinnitust, et ta tõesti soovib sellist lahendust nagu spetsifikatsioonis kirjas. Selline töökorraldus maandab analüütiku jaoks nii mõnegi riski – näiteks selle, et tellija väidab, et ta ei ole olnud teadlik meie kokkuleppest. Või selle, et arendaja hakkab ise leiutama, mida kliendil võiks vaja minna (või veel hullem kuidas võimalikult lihtsalt antud arendusülesanne kaelast ära saada).

Viimaste projektide käigus olen märganud, et tihti analüütikud sellist töövõtet ei kasuta ja selle läbi projekti riske ei enneta. See päädib alati sellega, et arendamisel tehakse teatud eelduseid, millest klient ei tea midagi ning mille üle hakatakse hiljem vaidlema. Sellistes olukordades olen tihti tabanud ennast mõttelt, et palju aja- ja ressursisäästlikum on kohe alguses teha natuke rohkem ja korralikumalt tööd kui hiljem hakata vaidlema ning asju ringi tegema. Analüütiku tegevustest ja tööprotsessides olen samuti kirjutanud eraldi blogipostituse.

Tähelepanek nr 6 – Tuleb mõista ja austada projekti raame ja piiranguid

Olen korduvalt näinud, kuidas riigihangete projektides (kus teatavasti on alati fikseeritud eelarve ja ajaraam ning tihti ka fikseeritud skoop) hakatakse arendama “agiilselt”. See tähendab ilma igasuguse plaanita, kuidas oleks võimalik jõuda projekti oodatava tulemini. Sellise lähenemise lõpplahendus on, et arendusfirma kulutab ära tunnid ja raha ning klient ei saa sellist tulemit, mida ta vajab.

Siinkohal peaks tuhka pähe raputama nii kliendile kui ka arendusfirmale. Klient ei saa küsida arendusfirmalt ebamõistlikku skoopi. Klient peaks suutma ise ära teha ärianalüüsi, et mõista väga täpselt, mida ta hankima läheb ja mis on reaalne ettenähtud eelarve raames ära teha. Teiselt poolt hämmastab mind alati arendusfirmade naiivsus fikseeritud eelarve, ajaraami ja skoobiga projekti arendada agiilselt. See ei ole ju kuidagi võimalik! Seda sellepärast, et kliendil on peaagu alati rahastusallikaga seotud kohustus projekt teatud ajaraamis, teatud eelarve ning lubatud skoobiga ära teha. Ja kuna kõikidest piiravatest faktoritest on kõik fiskeeritud, siis ei ole ju millegi arvelt võimalik agiilselt arendada.

Tähelepanek nr 7 – Rolliselgus on oluline

Rolliselgus ei ole oluline kitsalt tarkvara arenduses vaid igas ettevõttes/asutuses, mille eesmärk on võimalikult efektiivselt toimetada ning tagada oma töötajatele arusaam nende ülesannetest. Kuna tarkvaraarenduse projektid on tavaliselt väga ajakriitilised, siis on ükskõik millise arendusmetoodika eeldus, et täpselt oleks kokku lepitud rollid ning nende vastutused. Mida ma sellega mõtlen? Ikka seda, et arendusmeeskonnas teaks näiteks projektijuht, millised on tema ülesanded selleks, et projektis suhtlus toimiks (nii meeskonna sees kui ka kliendiga), tööd saaks nõuetekohaselt ja õigeaegselt tehtud, projekti riskid oleksid ennetatud ja maandatud ning meeskond oleks juhitud. Kui millegipärast ei ole arendusmeeskonnas ette nähtud projektijuhi rolli, siis peab olema selge, milline muu roll katab neid tavapäraseid projektijuhtimise ülesanded. See oli üks näide projektijuhi vastutusest aga sama loogika kehtib iga misiganes arendusmeeskonna rolli kohta.

Rolliselguseta ei ole võimalik üles ehitada toimivat koostööd nii arendusmeeskonna sees kui ka kliendiga ning tekivad “hallid vastutused”, mis on projekti/töö õnnestumiseks olulised aga mille osas keegi vastutust ei võta.

Minu soov uueks aastaks oleks see, et arendusfirmad päriselt ka läbi mõtestaks, kas ja kuidas nad oma tegevusega kliendile väärtust pakkuvad. Siinkohal on märksõnad – soov klienti mõista ning leida talle kontekstist lähtuvalt parim lahendus, läbitöötatud ja toimivate metoodikate kasutamine, rolliselgus arendusmeeskonnas.

Selleks, et tellijad oskaksid paremini oma vajadusi kirja panna ning osata seista oma õiguste eest, olen välja töötamas uut targale tellijale suunatud koolitust. Täpsemalt aga sellest juba uuel aastal 🙂 !

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

« Older posts