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!

 

Mis on äriprotsess?

Susan Page on protsessi kirjeldanud järgnevalt  Everything is a process, from making breakfast for yourself in the morning to building the space shuttle“.  Minu arust on see väga mõjus kirjeldus ja annab edasi just seda arusaama, et protsessid ei ole ainult ülikeeruliste valdkondade pärusmaa, vaid sisuliselt ümbritsevaid meid igal sammul. Kui protsessid on koondmõiste misiganes eluvaldkonna loogiliselt üksteisega seotud tegevustele, siis äriprotsessid kirjeldavad kitsamalt konkreetse ärivaldkonna jaoks olulisi tegevusi.

Kui rääkida äriprotsessi ametlikumast definitsioon, siis mulle väga meeldib Mathias Kirchmeri definitsioon, mis rõhutab seda, et äriprotsess peaks tekitama väärtust – “Äriprotsess on konkreetses järjekorras läbitavad tegevused, mis loob väärtust sisemisele või välisele kliendile.

Protsessid vs äriprotsessid

Üks erinevus igapäevaste protsesside ja äriprotsesside vahel on see, et üldiselt ei ole igapäevaseid protsesse vaja formaalselt kuidagi kirjeldada või modelleerida, kuna tegemist on suhteliselt iseenesestmõistetavate tegevustega, mis on enamus inimestele tuttavad. Näiteks kui ütled sõbrale, et valmistad hommikusööki, siis kujutab sõber juba sind ja sinu eelistusi tundes ette, et valmistad endale kohvi, kallad apelsinimahla, teed putru ja asud sööma. Sama loogika ei kehti aga siis, kui ütled sõbrale, et töötad kosmoserakette valmistavas ettevõttes näiteks kvaliteedijuhina. Kui sinu sõber ei tea sellest valdkonnast ega sinu ettevõttest midagi (st see ei ole tema jaoks iseenesestmõistetav), siis ei kujuta ta üldse ette, millega sa päevad läbi tegeled.

Miks on vaja äriprotsesse kirjeldada?

Siit jõuamegi küsimuseni, et miks on siis ikkagi oluline (äri)protsesse kirjeldada? (Äri)protsesse on vaja kirjeldada eelkõige siis, kui tahad mõnele teisele osapoolele (kes veel ei tea kõiki sinu harjumusi/eelistusi, töömeetodeid) selgeks teha, millega sa igapäevaselt tegeled.  Igapäevaste tegevuste puhul võib paralleeli tuua endale koju koristusteenuse tellimisega. Igal inimesel on kindlasti omad ootused koristusteenusele – kas teenus peab hõlmama köögi koristamisel praeahju puhastamist ja kõikide köögikappide koristamist  või ainult üldpindade koristust jne. Neid koristamise tegevusi üldiselt formaalsete protsessi-kirjeldustena ei vormistata, vaid fikseeritakse nt lepingus või kokkuleppes. Ja see on igati mõistlik, kuna antud protsessi ja tegevustega on seotud vähe osapooli (tavaliselt kaks – koduomanik ja koristaja).

Kui aga meil on seotud rohkem osapooli ja erinevad protsessid on lisaks omavahel sõltuvuses , siis on väga oluline protsesside kohta luua protsessidiagrammid ja -kirjeldused (protsessidiagrammidest tuleb täpsemalt juttu mõnes järgmises blogipostituses).  See on tavapärane just ettevõtetes ja asutustes, kus sõltuvalt ettevõtte/asutuse suurusest võib olla väga mitmeid osakondi, mis omakorda koosnevad mingitest väikesematest üksustest (tiimid, talitused vms) jne. Ettevõtetes/asutustes ei ole aga protsessid tavapäraselt tiimide põhised, vaid pigem vajavad mitme osakonna mitmete tiimide panust. Näiteks toidukaupluses on tiim, kes vastutab kauba väljapanemise eest. Nemad ei saa oma tööd teha juhul, kui kauba tellimise eest vastutav tiim ei ole oma tööd teinud ehk siis nad pole tellinud kaupa, mida välja panna. Kauba tellimise tiim ei saa omakorda oma tööd teha, kui tarnijatega kokkulepete tegemise tiim ei ole tööd teinud ehk siis puuduvad kokkulepped vajalike tarnijatega, kes kaupa poodi toovad. Väljatoodud tegevused võib koondada kauba poodi jõudmise protsessiks ning nagu kirjeldusest selgus, siis on selle protsessiga seotud kolm tiimi, kelle tegevused on omavahel sõltuvuses. 


  1. Arusaama, millega ettevõttes üks või teine üksus tegeleb – väga oluline just uutele töötajatele, et neil tekiks arusaam oma töö sisust ja vastutuspiiridest. Tavapäraselt kulub uuel töötajal minimaalselt paar kuud, et hakata hoomama, millega ettevõttes/asutuses keegi tegeleb. Juhul kui oleks olemas kirjeldus/joonised äriprotsessidest, saaks selle pildi uuele töötajale kiiremini tekitada;
  2. Arusaama, millise üksuse rollid on millise äriprotsessiga seotud ja kes mis “tüki” eest vastutab –  ülioluline selleks, et tööde üleandmine ühelt üksuselt teisele sujuks ning protsessis ei tekiks viivitusi või katkemist;
  3. Olulise sisendi ettevõtte toote/teenuse kvaliteeditegevuste parandamiseks – Näiteks sa avastad, et sinu töötajad teevad oma tööülesannete raames korduvaid vigu ja sa üritad aru saada, millise protsessi millise tegevuse raames neid vigu tehakse;
  4.  Olulise sisendi dubleerivate tegevuste ja/või andmekorje tuvastamiseks – Dubleeriv andmekorje on väga aktuaalne teema Eestis just riigisektori puhul. Siin aga ei lahenda seda probleemi enam ühe asutuse sees, vaid mängu tulevad juba erinevad asutused oma äriprotsesside ja huvidega;
  5. Olulise sisendi äriprotsesside efektiivistamisel – Näiteks sa tahad aru saada, kuidas sinu asutus /ettevõte saab parandada oma töö efektiivsust nii, et töötajad panustaksid oma väärtuslikku aega justnimelt tööle, mis loob kliendile tegelikult väärtust. Samuti on äriprotsesside efektiivistamisel oluline roll ka erinevatel IT lahendustel, mille puhul peaks olema must-be nõue, et enne uue süsteemi arendama asumist on vaja tekitada arusaam, millist äriprotsessi loodav süsteem toetama hakkab ja millist probleemi lahendada aitab. 
  6. Aitab väärtustada oma töötajaid – Minu arust on see loetletud põhjustest kõige olulisem! Tänases tööjõukriisis otsivad tööandjad erinevaid viise, kuidas töötajaid enda juurde tööle meelitada – küll on nendeks nippideks sportimistoetused või lauajalgpalli laud kontoris. Need hüved on pigem pealiskaudsed ja paljud töötajad neist suurt ei hooli. Mis aga on iga töötaja jaoks oluline, on arusaam, mis on tema roll ettevõttes/asutuses ja mida temalt oodatakse? Sellest tulenevalt tekivad igale töötajale eesmärgid, mille saavutamise rõõm kaalub üle kõik spordikompensatsioonid või muud hüved! Ja selleks, et ettevõte oskaks öelda, mis on iga töötaja roll ettevõttes, on võtmetähtsusega omada pilti oma ettevõtte äriprotsessidest! Seega siit üleskutse juhtidele, palun väärtustage oma inimeste tööaega ja motivatsiooni ning ärge laske neil tegeleda väärtusetu tööga! Väärtusetu töö olemust käsitlen pikemalt mõnes järgnevas blogipostituses.

Protsesside ja nende toimimisest arusaamise olulisust iseloomustab väga hästi Bill Gatesi tsitaat A rule of thumb is that a lousy process will consume ten times as many hours as the work itself requires.

Kes võiks/peaks äriprotsesse kirjeldama?

Enne kui “sukeldun” järgmiste blogipostitustega äriprotsesside kaardistamise detailsematesse sammudesse, tahan põgusalt peatuda teemal, kes võiks/peaks äriprotsesse kirjeldama? Olles töötanud nii erasektoris teenusepakkujana kui ka  riigisektoris teenuse tarbijana, olen korduvalt mõtisklenud selle üle, et kuidas oleks kõige mõistlikum äriprotsesside kirjeldamise tööd korraldada? Ühelt poolt on teenuse tarbija ju see, kellel on olemas detailne arusaam oma tegevustest ja domeenist, samas puuduvad (üldjuhul aga mitte alati!) oskused protsesside kaardistamiseks. Teiselt poolt on teenuse pakkuja see, kel on olemas mainitud oskused aga puudub arusaam kliendi tegevustest ja domeenist. Sellest vaatest lähtuvalt peab mõlemal juhul emb-kumb osapool midagi juurde õppima ja endale selgeks tegema. Paraku on äriprotsessid oma olemuselt ajas pidevalt muutuvad ja see omakorda toob kaasa pideva vajaduse äriprotsesse täiustada. Seega mina arvan, et pikas perspektiivis on ärile kasulik (kuluefektiivsem) endal omada selliseid töötajaid, kes suudavad ettevõtte äriprotsesse kaardistada ja hallata. 

Selleks, et panustada omaltpoolt äriprotsesside alase kompetentsi kasvatamisele, plaanin järgmiste blogipostituste raames käsitleda samme, mis on vajalikud äriprotsesside kaardistamisel. Need sammud põhinevad erinevatel kirjandusallikatel, milles väljatoodut üritan enda kogemuse ja tähelepanekute põhjal laiendada.

Seega, kes tundis, et äriprotsesside teema teid kuidagi puudutab, siis olete oodatud lugema minu blogi järgmisi postitusi! 🙂 

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

 

Postituses viidatud raamatud:

  • “The Power of Business Process Improvement” Susan Page
  • “High Performance Through Business Process Management” Mathias Kirchmer