protsesside analuus ja kaardistamine

SISEMINISTEERIUM

Protsesside analüüs ja kaardistamine Juhend

Detsember 2009

Versioon 1.0

2

Sisukord Sissejuhatus ........................................................................................................................................... 4

Lühikokkuvõte ......................................................................................................................................... 5

Versiooniajalugu ..................................................................................................................................... 6

1. Protsessianalüüsi käsitlus ja metoodika ...................................................................................... 7

1.1 Protsessianalüüsi eesmärk ................................................................................................... 7

1.1.1 Protsesside dokumenteerimine ........................................................................................ 7

1.1.2 Protsesside optimeerimine ............................................................................................... 7

1.1.3 Infosüsteemi loomine ........................................................................................................ 8

1.2 Protsessianalüüsi eeldused ja põhimõtted............................................................................ 8

1.2.1 Organisatsiooni valmisolek ............................................................................................... 8

1.2.2 Eesmärgi seadmine .......................................................................................................... 9

1.2.3 Vahendite valik .................................................................................................................. 9

1.2.4 Üldpõhimõtted ................................................................................................................... 9

1.2.5 Protsessianalüüs avalikus sektoris ................................................................................. 10

1.3 Protsessianalüüsi läbiviimine .............................................................................................. 10

1.3.1 Põhifunktsioonide määratlemine ja funktsioonihierarhia koostamine ............................. 10

1.3.2 Ulatuse ehk skoobi defineerimine .................................................................................... 11

1.3.3 Analüüs ja modelleerimine............................................................................................... 11

1.3.4 Protsessianalüüsi võtted protsesside kirjeldamisel ......................................................... 11

2. Protsessianalüüsi notatsioon BPMN ......................................................................................... 13

2.1 Notatsioonide ülevaade ....................................................................................................... 13

2.2 BPMN notatsioon ................................................................................................................ 13

2.2.1 Elementide liigitamine ..................................................................................................... 13

2.2.2 BPMN põhielemendid ..................................................................................................... 14

2.2.3 BPMN lisaelemendid ...................................................................................................... 15

2.3 BPMN notatsiooni kasutamine ............................................................................................ 18

2.3.1 Privaatsed ja avalikud protsessid ................................................................................... 19

2.3.2 Basseinid ja rajad ........................................................................................................... 20

2.3.3 Artefaktid ......................................................................................................................... 20

2.3.4 Välistavad ja paralleelsed lüüsid ..................................................................................... 21

2.3.5 Transaktsioonid ja kompensatsioonid ............................................................................. 22

2.3.6 Meeldetuletused ja aegumised ....................................................................................... 22

3. Protsesside arendamine / efektiivsus ........................................................................................ 24

3.1 Protsesside arendamise etapid ........................................................................................... 24

3.2 Protsesside arendamise metoodikad .................................................................................. 24

3.2.1 Six Sigma ........................................................................................................................ 24

3.2.2 Lean ................................................................................................................................ 24

3.2.3 Lean Sigma ..................................................................................................................... 25

3

3.2.4 Kaizen ............................................................................................................................. 25

3.3 Protsesside arendamise tehnikad ....................................................................................... 25

3.3.1 Ajurünnak ........................................................................................................................ 25

3.3.2 Küsimustike koostamine ................................................................................................. 25

3.3.3 Algpõhjuse analüüs ........................................................................................................ 25

3.3.4 Võrdlev analüüs .............................................................................................................. 25

4

Sissejuhatus

Käesoleva juhendi eesmärk on anda juhiseid avaliku sektori organisatsioonides protsesside kirjeldamiseks ja analüüsimiseks.

Protsessianalüüs ja kirjeldamine (modelleerimine) on valdav meetod organisatsioonides toimuvatest protsessidest arusaama kujundamiseks ja protsesside optimeerimiseks. See on vajalik mitmel eesmärgil, sh:

1. Protsessi erinevate osapoolte vahel ühise arusaama loomiseks protsessi toimimisest, protsessis osalevatest rollidest jms;

2. Protsessides kitsaskohtade ja ebaefektiivuste tuvastamiseks;

3. Protsesse toetavate infotehnoloogiliste lahendustele loomiseks.

Protsessianalüüsil on tähtis roll ka organisatsioonide ülese tegevuse koordineerimisel. Kodanikule suunatud teenuste osutamine toimub sageli mitme erineva riigiasutuse või kohaliku omavalitsuse üksuse poolt. Seetõttu on oluline, et kõik ühe teenuse või eesmärgi heaks tegutsevad osapooled omaksid ühtset tervikpilti kogu teenuse osutamise protsessist. Käesoleva juhendi üks eesmärke ongi anda ühtsed juhised protsesside kaardistamiseks, et parandada suhtlust eri osapoolte vahel.

Kuna protsesside üks põhiomadusi on asjaolu, et nendes osalevad erinevad organisatsioonilised üksused ja osapooled, on oluline, et kõik osapooled räägiksid nö sama keelt. Protsesside kirjeldamisel kasutatakse nii graafilisi kui tekstilisi vahendeid. Protsesside kirjeldamise graafilisteks vahenditeks on märkide keel ehk notatsioon, millega antakse edasi protsessi olulised omadused – protsessi käik, osalejad, erinevad tingimused jms. Viimasel ajal on protsesside kirjeldamisel üheks levinuimaks notatsiooniks BPMN (Business Process Modeling Notation), mis on ühest küljest mitte-spetsialistile lihtsalt arusaadav, samas aga ka kasutatav tehnoloogilistes rakendustes. Seetõttu on käesolevas juhendis tuginetud BPMN notatsioonile.

Käesolevat juhendit täiendatakse vastavalt vajadustele üks kord aastas.

5

Lühikokkuvõte

Protsessipõhine lähenemine töö kirjeldamisel sai alguse umbes 100 aastat esimeste suurte tehaste tekkimisega kui tekkis vajadus tööviljakust tõsta ning suure hulga inimeste tööd paremini koordineerida. Eelmise sajandi 70ndatel aastatel hakkas protsessipõhine lähenemine levima ka teistesse eluvaldkondadesse. Tänapäeval on see trend jätkunud ning protsesside kirjeldamisega tegeleb valdav enamus suuremaid organisatsioone nii era- kui avalikus sektoris.

Maailmast on tuua palju näiteid, kus protsessipõhine lähenemine on aidanud oluliselt vähendada organisatsiooni kulusid ning tõstnud tööviljakust ilma suuremate lisainvesteeringute tegemiseta lihtsalt olemasolevaid ressursse paremini ära kasutades. Organisatsiooni peamine tulu protsessianalüüsist on parem arusaamine oma töökorraldusest, arenguvajaduste väljaselgitamine ning sellega seonduvate kulude põhjendamine.

Infotehnoloogia areng on viimase aastakümne jooksul oluliselt laiendanud võimalusi protsesside kirjeldamisel ja parendamisel. Kui varem piirdus infotehnoloogia tugi lihtsa protsesside joonistamise vahendi pakkumisega, siis kaasaegsete modelleerimisvahenditega on võimalik läbi viia keerukaid simulatsioone ja analüüse, protsessiserverid võimaldavad kirjeldatud protsesse kasutada vahetult infosüsteemides ning protsesside monitooringuvahendid koguda protsessidele kirjeldatud mõõdikute andmeid reaalajas.

Protsesside kirjeldamiseks on läbi aegade kasutatud mitmeid erinevaid märgendite keeli. Viimasel ajal on üha enam populaarsust kogunud BPMN (Business Process Modelling Notation), mis on võetud aluseks ka käesoleva juhendi koostamisel. BPMNi eelis seisneb lihtsas ja arusaadavas väljendusvormis, mis on loetav ka ilma põhjalike eelteadmisteta, samas pakub see piisavalt detailide kirjeldamise võimalust, et protsessi vahetult infosüsteemiks teisendada.

Käesolev juhend koosneb kolmest sisupeatükist, mis annavad ülevaate protsessipõhise lähenemise tagamaadest, eesmärkidest ja kasutatavatest tehnikatest.

Esimene peatükk toob välja nüansid protsessianalüüsi käsitlusest ja metoodikast, kirjeldab analüüsi erinevaid eesmärke ning eelduseid, mis on vajalik täita enne analüüsiga alustamist.

Teine peatükk annab ülevaate protsesside kirjeldamise BPMN notatsioonist, selle elementidest, toob näiteid tüüpsituatsioonidest ning nende lahendamisest.

Kolmas peatükk käsitleb mõningaid protsesside efektiivsuse analüüsimise ja parendamise võtteid ning kirjeldab enamlevinud protsesside optimeerimise raamistikke.

6

Versiooniajalugu

Versioon Kuupäev Kirjeldus

0.1 Aprill 2009 Esialgne versioon- Meelis Pupart

0.2 Mai 2009 Täiendatud, protsesside ajalugu- Leopold Veges

1.0 31.12.2009 Enst jaYoung

7

1.1.1.1. Protsessianalüüsi käsitlus ja metoodika

1.11.11.11.1 Protsessianalüüsi eesmärk Protsessianalüüs on organisatsiooni töö kaardistamine, mille käigus tuvastatakse mingi kitsama funktsiooni või eesmärgi saavutamiseks vajalikud erinevad tegevused, osapooled, nende vahelised seosed ja toimimisloogika protsessina.

Järgnevates alapeatükkides on toodud tüüpilised protsessianalüüsi eesmärgid nende rõhuasetused ja tüüptoimingud.

1.1.11.1.11.1.11.1.1 Protsesside dokumenteerimine

Protsesside kirjeldamine dokumenteerimise eesmärgil on senini olnud üks peamiseid protsessianalüüsi teostamise põhjuseid. Osalt on selle tinginud infotehnoloogiliste vahendite võimetus muid eesmärke saavutada, aga oma osa on ka organisatsioonide töökorralduse ja sisemise valmisoleku puudustes.

Dokumenteerimise puhul tuleks lähtuda eelkõige protsessi loetavusest ning valida kasutatavale formaadile vastav detailsuse aste. Näiteks kui protsessiskeem lisatakse A4 formaadis paberaruandele, siis peaks see mahtuma ühele või äärmisel juhul 2-3 lehele. Pigem on soovitatav kirjeldada protsess mitmetasemeliselt, põhiprotsessi ja vajaliku hulga alamprotsessidena. Soovitatav on protsessid varustada piisava hulga kommentaaridega ning hästi liigendatud basseinide, radade ja gruppidega. Sageli koostatakse protsessiskeemile lisaks ka vaba tekstina protsessi toimimise kirjeldus.

Dokumenteerimine võib kanda endas ka muid eesmärke. Üks levinumatest on organisatsioonis rakendatud standardile vastavuse kontroll või auditeerimine. Sageli lisatakse protsessiskeeme uute töötajate koolitusmaterjalidesse, et anda neile visuaalset ülevaadet nende rollist ja organisatsiooni töökorraldusest. Dokumenteeritud protsessi saab kasutada ka juhtimisvahendina töökäskude andmiseks.

Dokumenteerimise eesmärgil protsessi kirjeldamisega tegeleb tavaliselt organisatsiooni protsessianalüütik või selle puudumisel protsessi omanik.

Tarkvaralistest vahenditest dokumenteerimise eesmärgil protsesside kirjeldamiseks piisab üldjuhul küllaltki lihtsast modelleerimistarkvarast või ka joonestustarkvarast.

1.1.21.1.21.1.21.1.2 Protsesside optimeerimine

Optimeerimise eesmärgil protsessi kirjeldamine tähendab teadlikku soovi protsessi muuta. Sellisel juhul on enamasti üldjoontes teada ka probleemsed kohad, mille kirjeldamisele pööratakse suuremat tähelepanu ning tehakse seda võimalikult detailselt.

Optimeerimise puhul on oluline kõigepealt kirjeldada protsess täpselt sellisena nagu see reaalselt toimib, mitte üritada kirjeldamise käigus seda jooksvalt optimeerida. Reaalselt toimivat protsessiskeemi kutsutakse protsessi hetkeolukorraks (as-is process). Hetkeolukorra põhjal koostatakse ettepanekud protsessi muutmiseks tuleviku olukorda (to-be process). Tuleviku olukordi võib olla paralleelselt töös rohkem kui üks. Protsessianalüüsi käigus toimub erinevate tuleviku olukordade omavaheline hindamine ning võrdlemine hetkeolukorraga. Analüüsi eesmärk on välja selgitada tuleviku olukorra otstarbekus ning sellega seonduvad kulud.

Esialgse protsessi kirjeldamisega tegeleb tavaliselt organisatsiooni protsessianalüütik või selle puudumisel protsessi omanik. Protsessi optimeerimiseks kaasatakse sageli väliseid eksperte. Optimeerimise läbiviimiseks on kasutusel erinevaid metoodikaid (näiteks Six Sigma, Lean, Kaizen), mis annavad juhtnööre kuidas probleemseid kohti tuvastada ning protsessi optimaalsemaks muuta. Enamasti kasutatakse ühe organisatsiooni sees ühte või kahte protsesside optimeerimise metoodikat.

Sõltuvalt analüüsi läbiviimise metoodikast võib optimeerimise eesmärgil protsesside kirjeldamine vajada spetsiaalsete modelleerimisvahendite kasutamist, mis võimaldavad protsessiskeemile kirjeldada erinevaid ressursse (aeg, raha, inimesed, seadmed) ning teostada protsesside simulatsioone ja analüüse.

8

1.1.31.1.31.1.31.1.3 Infosüsteemi loomine

Infosüsteemi loomise eelduseks on selgelt fikseeritud protsess, mis kirjeldab infosüsteemi käitumise loogikat. Sõltuvalt kasutatavatest infosüsteemide loomise vahenditest võib eristada kahte tüüpi lähenemist:

1. Traditsiooniline infosüsteem – protsessid kirjeldatakse abimaterjalina infosüsteemi loojatele ja kasutajatele. Protsesside toimimise loogika programmeeritakse loojate poolt infosüsteemi.

2. Protsessipõhised infosüsteemid – protsessid kirjeldatakse spetsiaalses rakenduskeskkonnas kasutamiseks.

Kasutades spetsiaalseid rakenduskeskkondi on tänapäeval võimalik protsessiskeem vahetult teisendada programmiloogikaks ning saavutada nö protsessipõhine infosüsteem. Peamine eesmärk sellisel lähenemisel on vähendada tarkvara arendamisele kuluvat aega ning võimaldada programmi käitumisloogika muutmist protsessiskeemi tasemel.

Tüüpiliselt juurutatakse sellised rakenduskeskkonnad koostöös teenustepõhise arhitektuuriga (SOA – service oriented architecture). Protsesside kirjeldamisele protsessipõhise infosüsteemi loomiseks võib valitud tarkvaraplatvorm seada teatud tehnilised piirangud, millega tuleb protsessi kirjeldamise käigus arvestada. Seejuures võivad erinevate tarkvaratootjate rakendusplatvormid seada erinevaid nõudeid.

Protsesside kirjeldamine protsessipõhise infosüsteemi loomiseks käib tüüpiliselt kahes etapis – kõigepealt kirjeldatakse protsessiskeem ning seejärel seotakse see standardiseeritud liideste kaudu olemasolevate infosüsteemidega. Sellisel tasemel protsesside kirjeldamine eeldab spetsiaalsete modelleerimisvahendite kasutamist.

Esialgse protsessiskeemi kirjeldamisega tegeleb organisatsiooni protsessianalüütik või selle puudumisel protsessi omanik. Protsessi täiendamiseks piisava detailsuse saavutamiseks võib olla vajalik rakenduskeskkonda tundva konsultandi kaasamine. Protsessi kirjeldamise teise etapiga tegeleb tüüpiliselt IT konsultant.

1.21.21.21.2 Protsessianalüüsi eeldused ja põhimõtted Enne protsessianalüüsiga alustamist on soovitatav kontrollida erinevate eelduste täidetust ja põhimõtete järgimist organisatsioonis ning puuduste tuvastamisel need eelnevalt kõrvaldada. Vastasel korral võib kogu projekt takerduda ning selle jätkamise võimalikkus muutuda küsitavaks.

1.2.11.2.11.2.11.2.1 Organisatsiooni valmisolek

Protsessianalüüsi läbiviimine eeldab organsatsiooni poolt teatud ettevalmistuste tegemist. Sellised ettevalmistused on seotud nii organisatsioonis olevate inimestega kui ka üldise töökorraldusega.

Valdav enamus organisatsioone on liigendatud osakondadeks või allasutusteks. Organisatsiooni protsessid on sageli osakondade või allasutuste ülesed. Protsessianalüüsi edukaks läbiviimiseks on vajalik organisatsiooni eri osade soov ja võime koostööd teha. Tüüpiliseks takistuseks siin on „oma kastis“ mõtlemine, kus inimestel puudub motivatsioon või aeg tegeleda toimingutega, mis ei too otsest kasu nende igapäevatöös. Selle vältimiseks tuleb läbi viia piisav teavitus inimeste hulgas ning tagada piisava aja ja motivatsiooni olemasolu.

Protsessianalüüsi läbiviimine võib vajada ka täiendavate rollide määramist organisatsioonis. Näiteks protsessianalüütikud ja protsesside omanikud. Lisaks formaalsele rolli määramisele tuleb tagada nende inimeste piisav väljaõpe. Tänapäeval kasutatavad protsesside kirjeldamise tehnoloogiad on küllaltki intuitiivsed, mis võib jätta petliku mulje, et põhjalik koolitus ei ole tingimata vajalik. Tegelikkuses on protsessi kirjeldamisel vaja arvestada mitmete asjaoludega, kasutada ühtset stiili ning õigesti valitud lähenemist, mis on saavutatavad vaid piisava teoreetilise teadmise omandamise läbi.

9

1.2.21.2.21.2.21.2.2 Eesmärgi seadmine

Enne protsessianalüüsi alustamist tuleb seada analüüsi eesmärk, sest protsessi kirjeldamise stiil ja detailsuse aste võivad olla erinevate eesmärkide saavutamiseks küllaltki erinevad. Enamlevinud eesmärgid ning nende eripärad on loetletud käesoleva juhendi peatükis 1.1.

Eesmärgi seadmisel on soovitatav arvestada lisaks hetkevajadustele ka pikemaajalise strateegiaga ning pigem valida pisut detailsem lähenemine. Lihtsustatud ja üldsõnaliselt kirjeldatud protsessid täidavad ainult formaalset rolli ning nende põhjal ei ole võimalik teha otsuseid protsessi parendamiseks. Samas tuleb vältida protsessi kirjeldamisel liigset detailsust, sest see muudab tervikpildi raskesti hoomatavaks ning kulutab asjatult organisatsiooni ressursse.

1.2.31.2.31.2.31.2.3 Vahendite valik

Oluline komponent protsessianalüüsi läbiviimiseks on protsesside kirjeldamise tarkvara. Erinevad tarkvarapaketid pakuvad erineval hulgal lisavõimalusi ning protsesside edasiarendamise vahendeid. Vahendi valikul tuleb jälgida vahendi sobivust seatud eesmärgiga. Liiga lihtsa või liiga keeruka tarkvarapaketi kasutamisel on oht, et vajalikul tasemel protsesside kirjeldamiseks kulub asjatult palju aega ning see võib vähendada inimeste motivatsiooni sellega tegeleda.

Lihtsustatult võib jagada protsesside kirjeldamise vahendid jagada kolme gruppi:

1. Joonestustarkvara – tarkvarapaketid, mis võimaldavad joonistada erinevates märgendkeeltes diagramme. Reeglina sellised vahendid ei paku täiendavaid võimalusi diagrammide sisuliseks analüüsiks või muudatuste haldamiseks.

2. Modelleerimistarkvara – tarkvarapaketid, mis võimaldavad lisaks protsesside kirjeldamisele teostada nende sisulist analüüsi, viia läbi simulatsioone. Reeglina on sellised vahendid ühe märgendkeele (näiteks BPMN) kesksed.

3. Integreerimistarkvara – tarkvarapaketid, mis võimaldavad lisaks modelleerimisele koostatud mudeleid siduda olemasolevate infosüsteemidega ning käivitada protsessidiagramme spetsiaalsetes rakenduskeskkondades ehk protsessiserverites.

Erinevad tarkvarapaketid võivad protsesside kirjeldamisele seada kitsendavaid tingimusi, seetõttu on soovitatav kasutajate koolituse valikul arvestada, et see käsitleks valitud tarkvarapaketi eripärasid.

Kui protsessid on organisatsioonide ülesed, on erinevates organisatsioonides soovitatav kasutada protsesside kirjeldamiseks samu vahendeid. Mitme erineva vahendi kasutamisel tuleb kontrollida nende kokkusobivust.

1.2.41.2.41.2.41.2.4 Üldpõhimõtted

Protsessianalüüs või protsessi modelleerimine on tehnika, mis kasutab graafilisi ja tekstilisi vahendeid olemasolevast või tulevasest protsessist arusaama dokumenteerimiseks mingis valdkonnas. Valdkonnaks võib olla kogum organisatsioonilisi üksusi või funktsioone, mis on omavahel seotud, kasutavad ühiseid andmeid ja informatsiooni ning jagavad ühiseid eesmärke.

Protsessianalüüsi juures on üheks läbivaks põhimõtteks dekomponeerimise meetod, ehk kõrgema taseme protsesside lahutamine väiksemateks alamprotsessideks kuni protsessi sammude ehk tegevuste tasemeni.

Protsesside analüüsi käsitluse juures on oluline defineerida põhimõistetena funktsioon ja protsess. Üldiselt on levinud, et organisatsioonid on üles ehitatud funktsioonipõhiselt. See tuleneb vajadusest koondada organisatsioonilistesse üksustesse sarnase kompetentsiga isikud, et täita mingit konkreetset funktsiooni (n. klienditeenindus, finantsarvestus, raamatupidamine). Võttes arvesse, et organisatsioonid on kutsutud ellu pakkuma teatud teenuseid, on selge, et antud teenuste osutamine kätkeb endas erinevate funktsionaalsete rollide täitmist. Näiteks on sotsiaaltoetuse väljamaksmiseks vajalik klienditeenindaja poolne suhtlus toetuse saajaga, finantsarvestuse poolne toetuste arvestamine, raamatupidaja poolne väljamaksmine jne. Selleks, et teenus saaks kvaliteetselt osutatud peavad toimima nii funktsioonid, ehk kõik osapooled peavad täitma oma rolli, kui ka protsessid – funktsioonide vahel peab toimuma sujuv tegevuste üleminek ja infovahetus.

10

1.2.51.2.51.2.51.2.5 Protsessianalüüs avalikus sektoris

Avalikus sektoris on seni kandnud protsessianalüüs eelkõige dokumenteerimise eesmärki. Protsessianalüüsi käigus kirjeldatud protsessid on sisendiks teistele analüüsidele, näiteks uue infosüsteemi loomise eelanalüüsile. Seetõttu on oluline viia läbi protsessianalüüs enne infosüsteemide loomise või muutmise planeerimist. Protsessi vaade aitab paremini aru saada menetlustoimingute olemusest ja leida erinevate protsesside lõikes sarnaseid tegevusi ning seeläbi juba olemasolevaid ressursse paremini kasutada.

Olemasolevate ressursside efektiivsem kasutamine on protsessianalüüsi üks eesmärkidest. Efektiivsuse tõstmine saavutatakse nii olemasolevate protsesside optimeerimisega kui uute protsesside kirjeldamisel teistes protsessides kasutatud ressursse taaskasutades.

1.31.31.31.3 Protsessianalüüsi läbiviimine Allpool on välja toodud peamised protsessianalüüsi etapid ning võtted.

1.3.11.3.11.3.11.3.1 Põhifunktsioonide määratlemine ja funktsioonihierarhia koostamine

Igal organisatsioonil on oma põhifunktsioonid (põhiülesanded), mis on määratletud erinevate õigusaktide ja eeskirjadega.

Põhifunktsioonide kirjeldamiseks tuleb tuvastada organisatsioonile õigusaktidega määratud põhifunktsioonid ja nendele vastavate struktuuriüksuste põhimäärused (nende puudumisel ametnike ametijuhendid).

Selle tulemina koostatakse tabel, milles seotakse põhifunktsioonid struktuuriüksuste või ametnikega ning fikseeritakse põhifunktsiooni regulatsioonina toimivad õigusaktid.

Põhifunktsioon Reguleerivad õigusaktid Täitja struktuur/ametnik

Põhifunktsiooni nimetus 1 Õigusakti nimetus Nimetus

Õigusakti nimetus Nimetus


Põhifunktsiooni nimetus 2 Õigusakti nimetus Nimetus



Funktsioonihierarhia koostamine seisneb põhifunktsioonide jaotamises alamfunktsioonideks ehk põhiülesande jagamises alamülesanneteks. Funktsioonihierarhia moodustamisel võib kasutada järgmisi tasemeid:

• valdkond

• alamvaldkond

• tegevus

Funktsioonihierarhiasse ei kuulu juhtimisfunktsioon, seda vaadeldakse protsessis tegevusena. Viimase taseme alamfunktsioonid jagatakse tegevusteks, mis on vajalikud alamfunktsiooni täitmiseks.

Kõik põhifunktsioonid, alamfunktsioonid ja tegevused on soovitatav tähistada vastavalt nende väljakasvamisele ülemise taseme funktsioonidest, mille alusel on võimalik hiljem lihtsalt tuvastada mingi põhifunktsiooni seoseid organisatsioonisiseselt ja -väliselt. Vastavalt kaardistamise lõppeesmärgile, koostatakse funktsioonihierarhia kas valitud või kõigi organisatsiooni põhifunktsioonide kohta.

11

Kohalike omavalitsuste põhifunktsioonide kaardistamiseks on Leopold Vegese poolt tehtud analüüs „Kohaliku omavalitsuse põhifunktsioonide hierarhia“, millega on võimalik tutvuda Siseministeeriumis.

1.3.21.3.21.3.21.3.2 Ulatuse ehk skoobi defineerimine

Ulatuse defineerimise etapi käigus määratletakse kirjeldatavate protsesside organisatsiooniline või funktsionaalne ulatus. Selleks võib kasutada funktsioonihierarhiat. Üldjuhul ei üritata ühe projekti raames kirjeldada kõigi organisatsiooni protsesse vaid valitakse välja mingi valdkond (business area), mida asutakse detailsemalt käsitlema ja analüüsima.

Ulatuse defineerimise käigus määratletakse valdkondade piirjooned, millega analüüsiobjekt on määratletud ehk protsessid, mis kuuluvad analüüsi ulatusse. Lisaks võib selguse huvides kasutada ka ulatuse nn välistavat defineerimist ehk määratleda need protsessid, mis jäävad analüüsi ulatusest välja.

Protsessianalüüsi ulatuse määratlemisele tuleb lisaks protsessidele tuvastada ka protsesside omanikud ehk isikud, kes on vastutavad protsesside toimimise eest ja on protsessianalüüsi juures võtmeisikud nii protsessi kirjeldamisel kui nende võimalikul modifitseerimisel.

1.3.31.3.31.3.31.3.3 Analüüs ja modelleerimine

Analüüsi ja modelleerimise käigus kirjeldatakse protsess detailsel tasemel. Selleks tuleb teostada järgmised sammud.

1.3.3.11.3.3.11.3.3.11.3.3.1 Tegijate tuvastamine

Protsessi kirjeldamiseks on vajalik kõigepealt tuvastada tegijad (actor) ehk osapooled, kes protsessis osalevad. See on eeldus protsesskeemi aluse loomiseks, sest osapoolte põhjal koostatakse basseinide ja radade struktuur (vt 2.3.2)

1.3.3.21.3.3.21.3.3.21.3.3.2 Protsessi alguse ja lõpu defineerimine

Kuna protsess on kindla alguse ja lõpuga tegevuste jada, tuleb protsessi jaoks alati defineerida protsessi algus ja lõpp. Protsessi alguseks võib olla mingi sündmus või ajaline kriteerium (mingi aja möödumine, kindel kuupäev vms). Samuti on igal protsessil ka lõpu kriteerium, ehk seisund, millega protsess on lõppenud, näiteks taotluse osas on tehtud otsus (kas positiivne või negatiivne).

1.3.3.31.3.3.31.3.3.31.3.3.3 Tegevuste määratlemine

Kui tegijad on tuvastatud, tuleb määratleda protsessi käigus teostatavad komponendid. Neist olulisemad on tegevused, millest igaühel on sisend ehk sündmus, mis seda käivitab ja väljund ehk tulemus. Sündmus on tegevuse toimumise eeltingimus. Ühe tegevuse väljund on teise tegevuse sisendiks. Kindlas järgnevuses toimuvad ja teineteist vastastikku mõjutavad tegevused moodustavad protsessi.

Tegevuste määratlemise juures on oluline nende korrektne nimetamine. Soovitatav on vältida üldsõnalisi või mitmeti mõistetavaid nimetusi (näiteks „tulemuste analüüs“, „taotluse ülevaatus“) ja kasutada selle asemel konkreetseid, üheselt mõistetavaid tegevusi (näiteks „tulemuste adekvaatsuse hindamine“, „andmete õigsuse kontrollimine“).

1.3.41.3.41.3.41.3.4 Protsessianalüüsi võtted protsesside kirjeldamisel

1.3.4.11.3.4.11.3.4.11.3.4.1 Sekundaarandmete analüüs

Sekundaarandmete analüüs on protsessi reguleerivate õigusaktide, normide, standardite ja muu dokumentatsiooni läbitöötamine nõuete väljaselgitamiseks ning selle põhjal protsessi koostamiseks.

Sekundaarandmete analüüs on sobiv meetod kui protsess on tugevalt reguleeritud või kui organisatsioonis puudub inimene, kellel on protsessist või selle osadest ülevaade.

12

1.3.4.21.3.4.21.3.4.21.3.4.2 Töötubade korraldamine

Töötuba on arutelu etteantud teemal, mille eesmärk on selgitada välja protsessi põhijooned. Näiteks organisatsiooni põhiprotsesside defineerimisel on oluline kaasata kõigi oluliste protsesside omanikud, kes arutelu käigus peavad jõudma ühisele arusaamale organisatsiooni põhiprotsessidest.

Töötuba on sobiv meetod üldisel tasemel protsesside määratlemiseks.

1.3.4.31.3.4.31.3.4.31.3.4.3 Intervjueerimine

Intervjuud viiakse protsessi kaardistaja poolt läbi protsessis osalevate inimestega. Intervjuu käigus küsitleb kaardistaja intervjueeritavaid protsessi detailide osas ja dokumenteerib saadud informatsiooni.

Intervjueerimine on sobiv meetod protsessi detailide väljaselgitamiseks, kus informatsiooni allikaks on väike arv inimesi.

1.3.4.41.3.4.41.3.4.41.3.4.4 Vaatlemine

Vaatlemine on meetod, kus protsessi kirjeldaja jälgib protsessis osalejate tegevusi ning selle põhjal koostab protsessiskeemi. Vaatlemine nõuab protsessi kirjeldajalt häid eelteadmisi protsessi olemusest.

Vaatlemine on sobiv meetod kui protsessi osalised täidavad samaaegselt mitmeid rolle ning ei oska oma tegevusi protsessipõhiselt liigitada.

1.3.4.51.3.4.51.3.4.51.3.4.5 Kontrollimine

Kontrollimise eesmärgiks on veenduda, et kas töötubade ja intervjuude käigus kogutud informatsiooni põhjal koostatud protsesside kaardistus vastab protsessiomanike tegelikule arusaamale protsessist.

13

2.2.2.2. Protsessianalüüsi notatsioon BPMN

2.12.12.12.1 Notatsioonide ülevaade Notatsioon on märkide keel protsessi kirjeldamiseks. Protsessi kirjeldamine tekstina ei pruugi anda piisavalt head ülevaadet protsessi struktuurist ning raskendab sellega protsessi ebaefektiivsuse tuvastamist.

Protsesside kirjeldamiseks on läbi aegade kasutatud erinevaid standardeid. Varasemalt on protsesside kirjeldamiseks kasutatud IDEF3 mudeleid ja UML (Unified Modeling Language) tegevusskeemi. IDEF modelleerimise keel loodi 1970ndatel, kuid seda toetavate modelleerimisvahendite vähese leviku tõttu ei ole see kujunenud üldkasutatavaks. UML modelleerimise keele loomisel on lähtutud eelkõige tarkvaraarenduse vajadustest ning protsessivaade (UML tegevusskeem) on üks osa tervikust. UML diagrammidest on tarkvaraarendamisega mitte kokkupuutuvatel inimestel tihtipeale keeruline aru saada.

Tänapäeval on levinuim protsesside kirjeldamise notatsioon BPMN (Business Process Modeling Notation), mis põhiprintsiipidelt on UMLile küllaltki sarnane. BPMNi peamiseks eeliseks on võimalus protsessi esitada BPEL (Business Process Execution Language) formaadis ning seeläbi realiseerida protsess vahetult tehnoloogilisel platvormil. Samuti pakub BPMN rikkalikuma hulga elemente protsessi kirjeldamiseks kui UML sisaldades muuhulgas sündmuste, veavoogude ja transaktsioonide kirjeldamist.

BPMN notatsiooni arendab ja haldab Object Management Group (http://www.omg.org). BPMNi on oma protsessihalduse tarkvara toodetes juurutanud valdav enamus suuremaid tarkvarafirmasid.

2.22.22.22.2 BPMN notatsioon Käesolev juhend on koostatud BPMN v1.2 spetsifikatsiooni põhjal, mis on hetkel viimane kinnitatud versioon. 2010. aasta keskel on välja tulemas BPMN v2.0, mis lisab mõningaid uusi elemente lisaks olemasolevatele.

2.2.12.2.12.2.12.2.1 Elementide liigitamine

BPMN arendamise üheks eesmärgiks oli luua lihtne süsteem protsessiskeemide loomiseks ning samal ajal oli teiseks eesmärgiks tagada piisav hulk vahendeid, et kirjeldada reaalses maailmas ette tulevaid keerulisi olukordi. Nende kahe vastandliku eesmärgi samaaegseks täitmiseks on notatsiooni elemendid jagatud graafilise kujunduse järgi kategooriatesse. Selline lähenemine tagab põhisümbolite suhteliselt väikese arvu ning lihtsustab protsessiskeemide loetavust. Keerulisemate olukordade kirjeldamiseks on kategooria põhisümbolile lisatud disainielemente, mis ei muuda oluliselt sümboli väljanägemist.

Elemendid jagunevad nelja põhikategooriasse ja nende alamkategooriatesse:

1. Vooelemendid (Flow Objects)

• Sündmused (Events)

• Tegevused (Activites)

• Lüüsid (Gateways)

2. Ühenduselemendid (Connecting Objects)

• Järgnevusvoog (Sequence Flow)

• Sõnumivoog (Message Flow)

• Seos (Association)

3. „Ujumisrajad“ (Swimlanes)

• Basseinid (Pools)

• Rajad (Lanes)

14

4. Artefaktid (Artifacts)

• Andmeobjekt (Data Object)

• Grupp (Group)

• Märkus (Annotation)

Artefakte kasutatakse lisainfo kandmiseks protsessiskeemile. Siinjuures on oluline, et artefakt ei ole protsessi sisuline osa. BPMN standard lubab kasutajatel vastavalt vajadusele artefakte juurde kirjeldada.

2.2.22.2.22.2.22.2.2 BPMN põhielemendid

Element Kirjeldus Sümbol

1. Vooelemendid Sündmus (Event)

Sündmus on midagi, mis „juhtub“ protsessi täitmise käigus. Sündmused mõjutavad protsessi voogu ning tavaliselt on neil põhjus ja tagajärg. Sündmuseid on kolme tüüpi vastavalt sellele, millal need voogu mõjutavad: Algus (Start), Vahepealne (Intermediate), Lõpp (End)

Tegevus (Activity)

Tegevus on üldine termin tööle või toimingule, mida organisatsioonis tehakse. Tegevus võib olla atomaarne või mitte-atomaarne (kombineeritud). Protsessiskeemil kasutatakse 3 tüüpi tegevusi: Protsess, Alamprotsess ja Toiming. Toiming ja alamprotsess kujutatakse protsessiskeemil ümarate nurkadega ristkülikuna. Protsess kujutatakse basseini sisuna.

Lüüs (Gateway)

Lüüse kasutatakse protsessi hargnevuste ja koonduvuste kirjeldamiseks. Hargnevused võivad olla tingimuslikud või paralleelsed. Koonduvused võivad olla sulanduvad või liituvad. Lüüsi tüübi tähistamiseks kasutatakse sisemisi markereid.

2. Ühenduselemendid Järgnevusvoog (Sequence Flow)

Järgnevusvoogu kasutatakse protsessi tegevuste täitmise järjekorra tähistamiseks.

Sõnumivoog (Message Flow)

Sõnumivoogu kasutatakse protsessi osapoolte vahelise sõnumiedastuse tähistamiseks. Osapoolte valmisolek sõnumeid saata ja vastu võtta peab olema protsessis tähistatud. BPMNis paigutatakse erinevad osapooled erinevatesse basseinidesse.

Seos (Association)

Seoseid kasutatakse vooelementidele info lisamiseks. Igale vooelemendile võib lisada tekstilist või graafilist lisainfot. Vajadusel võib info (andmete) liikumise suunda illustreerida noolega.

15

3. Ujumisrajad Bassein (Pool)

Basseiniga tähistatakse protsessi osapoolt. Ühtlasi võib basseini kasutada teatud tüüpi tegevuste visuaalseks grupeerimiseks eesmärgiga lihtsustada protsessiskeemi loetavust.

Nimi

Rada (Lane)

Rada on basseini alamgrupp, mis ulatub basseini ühest otsast teise. Radasid kasutatakse tegevuste liigitamiseks ja loogiliseks grupeerimiseks.

Nimi

Nimi

Nimi

4. Artefaktid Andmeobjekt (Data Object)

Andmeobjekte käsitletakse artefaktidena, sest need ei oma otsest mõju portsessi järgnevus- ja sõnumivoole. Andmeobjektid annavad infot selle kohta, mida tegevuse tegemiseks on tarvis või milline on tegevuse tulem. Nimi

Grupp (Group)

Gruppe kasutatakse samasse kategooriasse kuuluvate tegevuste rühmitamiseks. Kategooria nimi märgitakse grupi raami ülaäärde. Grupp ei mõjuta protsessi järgnevusvoogu. Gruppe kasutatakse dokumenteerimise või analüüsi eesmärkidel.

Märkus (lisatud seosega) (Annotation)

Märkused on üks viisidest, millega on võimalik protsessiskeemile kanda lisainfot protsessi lugejale.

Kirjeldavtekst

2.2.32.2.32.2.32.2.3 BPMN lisaelemendid

2.2.3.12.2.3.12.2.3.12.2.3.1 Sündmused

Sündmus on midagi, mis „juhtub“ protsessi täitmise käigus. Sündmused mõjutavad protsessi voogu ning tavaliselt on neil põhjus ja tagajärg. Sündmused jagunevad kolme kategooriasse.


Algus (Start)

Alguse sündmusega näidatakse protsessiskeemil protsessi algus.

Vahepealne (Intermediate)

Vahepealne sündmus toimub alguse ja lõpu vahel. Vahepealsed sündmused mõjutavad protsessi, kuid otseselt ei alusta ega lõpeta seda.

Lõpp (End)

Lõpu sündmusega tähistatakse protsessiskeemil protsessi lõppu.

Sündmustele võib lisada tüübi, mis näitab selle sündmuse toimumise põhjust. Vastavalt sündmuse iseloomule eristatakse püüdvaid (triggering) ja väljastavad (throwing) sündmuseid. Püüdvad sündmused reageerivad kui sündmus toimub (näiteks saabub sõnum). Väljastavad sündmused tekitavad vastava tüübilise sündmuse (näiteks väljastatakse sõnum). Protsessi alustavad sündmused saavad olla ainult püüdvad. Protsessi lõpetavad sündmused saavad olla ainult väljastavad. Vahepealsed sõnumid võivad olla nii püüdvad kui väljastavad.

Lubatud sündmuste tüübi, kategooria ja iseloomu kombinatsioonid on toodud järgnevas tabelis.

16


Püüdvad Väljastavad

Sõnum (Message)

Sõnum on teade, e-mail, kiri vms. Sündmuse käivitab sõnumi saabumine või väljastamine.

Taimer (Timer)

Taimeriga määratakse ajahetk, millal sündmus käivitatakse. Ajahetk võib olla määratud ühekordselt (täna kell 13:00), tsükliliselt (iga 2 tunni tagant) või tingimuslikult (7 minuti pärast).

Viga (Error)

Vea sündmusega tähistatakse veaolukorra (kõrvalekaldumine protsessi peavoost) lahendamist protsessis. Vigadele saab lisada veakoodi. Väljastav viga kutsub välja vastava veakoodiga püüdva vea.

Tühistamine (Cancel)

Tühistamise sündmustega tähistatakse protsessi voo peatamist tõrke korral. Väljastav tühistamise sündmus kutsub välja püüdva tühistamise sündmuse.

Kompensatsioon (Compensation)

Kompenseerivaid sündmuseid kasutatakse transaktsiooni ebaõnnestumisel juba täidetud transaktsiooni osategevuste tagasi pööramiseks.

Tingimuslik (Conditional)

Tingimuslik sündmus võimaldab kirjeldada avaldise, mille täitumisel sündmus aset leiab. Avaldise sisu võib olla kirjeldatud välise vahendiga (Rules Engine).

Link (Link)

Link sündmuseid kasutatakse paari kaupa protsessi järgnevusvoo ümbersuunamiseks. Linke võib kasutada näiteks pikkade ühenduste katkestamiseks või tähistamaks väljatrükil ühelt lehelt teisele minevaid ühendusi.

Teavitus (Signal)

Teavitus sündmuseid kasutatakse protsessi eri osade või erinevate protsesside vaheliseks teadete saatmiseks. Teavitustel puudub kindel adressaat, need paisatakse väljastava sündmuse poolt eetrisse ja kõik püüdvad sündmused saavad need kätte.

Katkestamine (Terminate)

Katkestamine peatab protsessi koheselt, ilma kompenseerivate või muudest sündmustest tulenevate toiminguteta. Protsessi katkestamine peatab ka kõikide protsessi paralleelharude täitmise.

Mitmik Mitmik tähendab, et sündmus võib toimuda mitut tüüpi sisendi puhul. Alguse

17

(Multiple) elemendi juures piisab ühe tingimuse täitmisest. Lõpp elemendi juures peavad täidetud olema kõik tingimused.

2.2.3.22.2.3.22.2.3.22.2.3.2 Tegevused

Tegevus on üldine termin tööle või toimingule, mida organisatsioonis tehakse. Tegevus võib olla atomaarne või mitte-atomaarne (kombineeritud). Tegevusel on üheselt mõistetav sisu ja tegija. Tegevust on võimalik mõõta ajas ja rahas ning tegevuse käigus võib kuluda ressursse. Tegevustega seotud lisaelemendid on toodud allolevas tabelis.


Toiming (Task)

Toiming on atomaarne tegevus protsessi käigus. Toimingu elementi kasutatakse kui protsessi kontekstis ei kirjeldata selle tegevuse läbiviimist detailsemalt.

Alamprotsess (Sub-Process)

Alamprotsess on protsess protsessi sees. Alamprotsessi kasutatakse kui protsessi kirja paneku käigus on vajadus mõni tegevus detailsemalt lahti kirjeldada, kuid protsessi kontekstis on see vaadeldav ühe tegevusena. Alamprotsessid võivad olla mitmetasemelised. Tasemete arv ei ole piiratud. +

Tsükkel (Loop)

Tsükkel on toiming või alamprotsess, mida täidetakse protsessis käigus mitu korda järjest. Iga käivituse alguses või lõpus kontrollitakse korduvustingimust, kui see on tõene minnakse uuele kordusele, kui see on väär lõpetatakse kordused ning väljutakse tsüklist.

Paralleeltsükkel (Parallel Loop)

Paralleeltsükkel on toiming või alamprotsess, mida täidetakse protsessi käigus mitu korda. Täitmiskordade arv määratakse numbriliselt. Kõiki korduseid peab saama täita paralleelselt st. need ei tohi teineteisest sõltuda.

Transaktsioon (Transaction)

Transaktsioon on alamprotsess, mille täitmisel kontrollitakse, et kõikide toimingute täitmine õnnestub. Kui mõni toimingutest ebaõnnestub, siis juba täidetud toimingud tühistatakse. Toimingute tühistamiseks on neile võimalik kirjeldada kompenseerivad tegevused.

Kompenseeriv tegevus (Compensation Activity)

Kompenseeriv tegevus on toiming, mis tehakse transaktsiooni ebaõnnestumisel juba täidetud toimingute tühistamiseks. Kompenseerivaid tegevusi saab kirjeldada ainult vahepealse kompensatsiooni sündmusega tähistatud vooahelas. Kui transaktsioon õnnestub, siis kompenseerivaid tegevusi ei täideta.

2.2.3.32.2.3.32.2.3.32.2.3.3 Lüüsid

Lüüse kasutatakse protsessi hargnevuste ja koonduvuste kirjeldamiseks. Hargnevused võivad olla tingimuslikud või paralleelsed. Koonduvused võivad olla sulanduvad või liituvad. Lüüsi tüübi tähistamiseks kasutatakse sisemisi markereid.

Kasutatavad sisemised markerid ja nende tähendused on toodud järgnevas tabelis

18


Välistav andmepõhine (Exclusive Data-Based)

Välistava andmepõhise lüüsi tingimus kirjeldatakse järgnevusvoos liikuvate andmete tunnuste põhjal.

Välistav lüüs hargnevuse korral tähendab, et korraga saab õige olla ainult 1 hargnevuse tingimustest.

Välistav lüüs koonduvuse korral tähendab, et voogu jätkatakse kui üks sisenditest on täidetud.

või

Välistav sündmuspõhine (Exclusive Event-Based)

Välistava sündmuspõhise lüüsi hargnevuse tingimuseks on mingi sündmuse toimumine, tavaliselt sõnumi vastuvõtmine. Otsus tehakse vastavalt sündmuse tüübile (mitte sisule).

Koonduvuse korral jätkatakse voogu kui üks sisenditest on täidetud. Reeglid on analoogsed välistava andmepõhise lüüsiga. Eelkõige kasutatakse sündmuspõhist koonduvat lüüsi juhul kui hargnevus on toimunud sündmuspõhiselt.

Sisaldav (Inclusive)

Sisaldav lüüs on andmepõhine ning lüüsi tingimus kirjeldatakse järgnevusvoos liikuvate andmete tunnuste põhjal.

Sisaldav lüüs hargnevuse korral tähendab, et kontrollitakse üle kõik hargnevuse tingimused ning korraga võivad neist õiged olla üks või mitu.

Sisaldav lüüs koonduvuse korral sünkroniseerib kõik sisendid, mis eespool sisaldava hargneva lüüsiga tõesed olid.

Keerukas (Complex)

Keerukas lüüs hargnevuse korral arvestab lisaks järgnevusvoos liikuvatele andmetele ka muid tingimusi (näiteks protsessi staatust). Väljunditest peab õige olema vähemalt üks.

Keerukas lüüs koonduvuse korral leiab vastavalt kirjeldatud tingimustele, milliste sisendite täitumine on vajalik enne voo jätkamist.

Paralleelne (Parallel)

Paralleelne lüüs hargnevuse korral tähendab, et alati täidetakse kõik harud.

Paralleelne lüüs koonduvuse korral tähendab, et protsessi voogu jätkatakse kui kõik sisendid on täidetud.

2.32.32.32.3 BPMN notatsiooni kasutamine Järgnevalt on välja toodud mõned enam-levinud tüüpolukorrad ning nende lahendamine BPMN notatsioonis.

19

2.3.12.3.12.3.12.3.1 Privaatsed ja avalikud protsessid

BPMN kirjeldab kolme tüüpi protsesse:

1. Privaatsed ehk sisemised protsessid – protsessid, mis kirjeldavad organisatsiooni sisest korraldust. Sellistel protsessidel puuduvad välised osapooled

2. Abstraktsed ehk avalikud protsessid – protsessid, kus on kirjeldatud sisemiste tegevuste käigus toimuv suhtlus väliste osapooltega. Väline osapool kaasatakse abstraktselt st. välise osapoole tegevused jäetakse kirjeldamata

3. Koostöö ehk globaalsed protsessid – protsessid, kus kirjeldatakse kõikide osapoolte tegevused paralleelsete protsessidena ning märgitakse ära nende kokkupuute kohad

Järgnevatel joonistel on toodud näited eri tüüpi protsessidest.

Taotluse vastuvõtmine

Andmete korrektsuse kontrollimine

Taotluse edastamine

Joonis 1 – Privaatne protsess

Kõne vastuvõtmine

Visiidi aja broneerimine

Haigussümptomite tuvastamine

Ravimi retsepti väljastamine

Patsient

Tahan minna arsti juurde Mine arsti juurde Tunnen ennast halvasti Mine osta rohtu

Polikliinik

Joonis 2 – Abstraktne protsess

Polikliinik

Kõne vastuvõtmine




Patsient

Arstile helistamineVisiidi aja teada

saamineHaigussümptomite

kirjeldamineRavimi retsepti

vastuvõtt


Joonis 3 – Globaalne protsess

20

2.3.22.3.22.3.22.3.2 Basseinid ja rajad

BPMNis kasutatakse erinevate osapoolte tähistamiseks basseine ja radasid. Basseiniga tähistatakse protsessi osapooli. Osapooleks võib siinkohal olla kas organisatsioon või konkreetne inimene või roll organisatsioonis. Standard ei määratle täpselt radade kasutamist basseini sees. Tüüpiliselt kasutatakse radasid tähistamaks ühise nimetajaga (näiteks samasse organisatsiooni kuuluvaid) erinevaid osapooli. Vajadusel võib radasid jagada veel omakorda radadega. Kõik rajad ja basseinid peavad olema ühepikkused, mitme raja või basseini paigutamine pikisuunas teineteise kõrvale ei ole lubatud. Basseinid ja rajad võib paigutada horisontaalselt või vertikaalselt, erinevad modelleerimise tarkvarad võivad selles osas seada piiranguid.

Joonisel 4 on toodud näidised basseinide ja radade kasutamisest.

Polikliinik

Registratuur

Arst

Patsient

Joonis 4 – Basseinid ja rajad

2.3.32.3.32.3.32.3.3 Artefaktid

Artefaktide kasutamine on BPMNis suhteliselt vähe reguleeritud. Kõige rangem piirang artefaktide juures on see, et artefakt on informatiivne ning ei tohi osaleda protsessis. BPMN kirjeldab kolme tüüpi artefakte nendele lisaks on lubatud kirjeldada lisaartefakte.

• Andmeobjekt artefaktiga näidatakse andmete liikumine protsessis. Andmete liikumist andmeobjektidena näidatakse tüüpiliselt juhtudel, kus see protsessi järgnevusvoost ei ole kergelt loetav või kui vaja esile tõsta näiteks dokumentide liikumist

• Grupp artefakti kasutatakse tegevuste grupeerimiseks. Grupeerimine võib käia basseinide siseselt või üleselt. Grupi raami ülaosas tuuakse välja grupi kirjeldus.

• Annotatsiooni artefakti kasutatakse kommenteeriva teksti lisamiseks portsessiskeemile. Kui kommentaar on seotud konkreetse tegevusega, viidatakse sellele punktiirjoonega.

Joonisel 5 on toodud BPMNi kirjeldatavate artefaktide kasutamise näited.

21

Polikliinik

Kõne vastuvõtmine




Patsient

Arstile helistamineVisiidi aja teada

saamineHaigussümptomite

kirjeldamineRavimi retsepti

vastuvõtt


Polikliinikus toimuvad tegevused

Kõne võtab vastu registratuuri töötaja

Retsept

Joonis 5 – Artefaktid

2.3.42.3.42.3.42.3.4 Välistavad ja paralleelsed lüüsid

Joonisel 6 on toodud välistava lüüsiga protsessi näide. Korraga saab tõene olla üks lüüsi tingimustest ning vastavalt sellele valitakse täidetav protsessiharu. Välistava lüüsiga protsessi puhul jääb osa tegevustest alati täitmata. Koondav välistav lüüs suunab tegevusjärje edasi kohe peale esimese sisendi täitumist.

Sobib?Taotluse andmete

õigsuse kontrollimine

Taotlus vastuvõtmise teate

koostamine

Taotlus tagasi lükkamise teate koostamine

Jah

Ei

Teate välja saatmine

Joonis 6 – Välistav lüüs

Joonisel 7 on toodud paralleelse lüüsiga protsessi näide. Paralleelse lüüsi puhul suundub protsessi täitmine paralleelsetesse harudesse. Selliselt tähistatakse tegevusi, mida saab teha teineteisest sõltumatult. Paralleelsed ahelad võetakse kokku koondava paralleelse lüüsiga. Koondav lüüs ootab kuni kõik paralleelsed harud on oma tegevuse lõpetanud ja alles siis suunab tegevuse edasi.

Digitaalse taotluse arhiivi saatmine

Taotluse salvestamine digiarhiivi

Taotluse väljatrükk ja köitmine kausta

Taotluse arhiivi vastuvõetuks märkimne

22

Joonis 7 – Paralleelne lüüs

2.3.52.3.52.3.52.3.5 Transaktsioonid ja kompensatsioonid

Joonisel 8 on toodud transaktsioonide ja kompensatsioonide näide reisi reserveerimise protsessina. Reisi reserveerimiseks on vajalik nii hotellitoa ja lennukipiletite olemasolu. Korraga peavad täidetud olema mõlemad tingimused, samas nende reserveerimine võib käia erinevate süsteemide kaudu. Seepärast kirjeldatakse reserveerimine transaktsioonina e. tegevuste kogumina, mis kõik peavad õnnestuma. Transaktsiooni sees on mõlemad reserveerimised kirjeldatud paralleelsete voogudena.

Kui üks voogudest lõppeb veaga (reserveerimine ebaõnnestub), teavitatakse sellest teist voogu ning kutsutakse välja juba läbiviidud tegevuse jaoks kirjeldatud kompenseeriv tegevus. Näiteks kui lennukipilet õnnestub broneerida, aga hotelli mitte, siis teavitatakse lennukipileti broneerimise voogu, et transaktsioon on tühistatud ning kutsutakse välja kompenseeriv tegevus „Lennukipileti tühistamine“. Kui kompenseerivad tegevused on tehtud, siis väljutakse transaktsioonist tühistamise väljundi kaudu. Selline tegevuste konstruktsioon on kontrollitud veahalduse situatsioon, kus vea tekkimine ei põhjusta liigsete või poolikute andmete produtseerimist.

Lisaks tühistusväljundile on transaktsioonil ka veaväljund „Süsteemi viga“. Sellesse väljundisse suundub tegevusjärg ootamatute vigade korral. Näiteks lennukipileti reserveerimise süsteem ei vasta päringutele ja seetõttu ei saa teada, kas reserveerimine õnnestus või mitte. Oluline erinevus tühistus- ja veavoogude vahel on see, et veavoosse suundumise korral jäävad kompenseerivad tegevused täitmata ning seetõttu on oht, et süsteemi jäävad poolikud või liigsed andmed.

Veavoogusid kirjeldatakse tüüpiliselt juhul kui eesmärgiks on protsessi automatiseerimine protsessiserveris.

Reserveeringud

Lennupileti reserveerimine

Hotelli reserveerimine

Reisi eest tasumine

Reserveerimine õnnestus

Klienditeeninduse teavitamine

Süsteemi viga

Teate saatmine vabade kohtade puudumise kohta

Reserveeringu ebaõnnestumine

Lennupileti tühistamine

Hotelli tühistamine

Joonis 8 – Transaktsioonid ja kompensatsioonid

2.3.62.3.62.3.62.3.6 Meeldetuletused ja aegumised

Joonisel 9 on toodud üks võimalikke protsessikonstruktsioone meeldetuletuste kirjeldamiseks. Kuna meeldetuletuse saatmine ei ole enamasti protsessi põhitegevus, siis on võimalik lisaks protsessi peavoole kirjeldada kõrvalvoog. Peavoos kirjeldatakse protsessi tavapärased tegevused ning kõrvalvoos lisategevused. Mõlemat voogu täidetakse paralleelselt. Kõrvalvoos kasutatakse antud juhul vahesündmusena taimerit, mis peatab voo täitmise 7 päevaks. Kui selle ajaga jõuab peavoog

23

lõpuni, siis protsess katkestatakse, kõrvalvoo täitmine peatatakse koos sellega ning meeldetuletust ei saadeta välja. Kui põhivoo täitmine võtab rohkem kui 7 päeva, siis saadetakse kõrvalvoo kaudu välja meeldetuletus. Kuna kõrvalvoog lõpeb Lõpp elemendiga, siis peavoo täitmine jätkub.

Taotluse vastuvõtmine

Andmete korrektsuse kontrollimine

Taotluse edastamine

7 päeva

Meeldetuletuse saatmine

Joonis 9 – Meeldetuletus

Joonis 10 käsitleb tüüpilist aegumise situatsiooni, kus peale tellimuse koostamist oodatakse kliendilt tellimuse kinnitamist. Kui seda 2 päeva jooksul ei tule, siis tekib „Tellimuse kinnitamine kliendi poolt“ tegevuses aegumise viga ning tellimus tühistatakse. Vea korral peavoo täitmine katkestatakse seega võib protsessi lõpetada tavalise Lõpp elemendiga ning Katkesta elemendi kasutamine ei ole otseselt vajalik, aga ei ole ka keelatud.

Tellimuse koostamine

Tellimuse kinnitamine kliendi

poolt

2 päeva

Tellimuse täitmisse saatmine

Tellimuse tühistamine

Joonis 10 - Aegumine

24

3.3.3.3. Protsesside arendamine / efektiivsus

3.13.13.13.1 Protsesside arendamise etapid Protsessi arendamine tähendab selle muutmist eesmärgiga protsessi optimeerida või täiendada vastavalt muutunud vajadustele.

Protsessi muutmise aluseks on hetkeolukorda (as-is) kirjeldav protsessiskeem. Kui seda ei ole, siis tuleks see kindlasti eelnevalt koostada. Oluline on siinjuures vältida protsessi muutmist kirjeldamise käigus ka nendes kohtades, mille muudatustes on juba põhimõtteliselt kokku lepitud. Selline käitumine välistab muudatuste planeerimisel mõjutused realiseerimata muudatustes. Vastasel korral võib uue muudatuse tasuvuse hinnang muutuda ebaadekvaatseks.

Muudatuse planeerimiseks koostatakse tuleviku olukorda (to-be) kirjeldav protsessiskeem. Tuleviku olukorda võrreldakse hetke olukorraga ning antakse hinnang muudatuse otstarbekusele. Siinjuures tuleb arvestada, et teatud muudatused võivad lühiajaliselt ressursikulu suurendada, kuid anda kokkuhoiu pikemas perspektiivis või tulemuse kvaliteedis. Muudatuse mõju korrektseks hindamiseks on soovitatav planeerida muudatused küllaltki väikesemahulistena. Vajadusel tuleks muuta protsessi pigem tihemini kui harva ja suures mahus.

Hetke olukorra ja tuleviku olukorra hindamiseks ja võrdlemiseks kasutatakse erinevaid tehnikaid. Näiteks tehakse tolerantsianalüüsi (gap analysis), tasuvusanalüüsi (cost-benefit analysis) ja protsesside simulatsioone. Protsessi simulatsioon on mõnede protsesside kirjeldamise tarkvarapakettide lisafunktsioon, kus protsessile kirjeldatakse erinevaid detaile (hind, kestvus, kasutatavad ressursid) ning mõõdikuid. Seejärel simuleeritakse protsessi läbimist korduvalt erinevate sisenditega ning kogutakse mõõdikute tulemused. Hetke olukorra ja tuleviku olukorra mõõdikute tulemuste hindamine annab ülevaate planeeritava muudatuse mõjust.

3.23.23.23.2 Protsesside arendamise metoodikad Protsesside optimeerimiseks on välja töötatud mitmeid erinevaid metoodikaid. Metoodikad erinevad nii lähenemise kui kasutusvaldkonna poolest. Suurem osa metoodikatest on alguse saanud tootmisettevõtetest ning on seotud tootmisprotsessi parendamisega. Samas on tänapäeval sarnaseid põhimõtteid järgides neid edukalt kasutatud ka teistes eluvaldkondades nagu avalik sektor, meditsiin, sõjavägi, telekommunikatsioon, pangandus jne. Tüüpiliselt valitakse organisatsioonis välja 1 või 2 metoodikat, millele tuginedes protsesse parendatakse.

Järgnevalt on välja toodud mõned enamlevinud metoodikad koos nende lühikirjelduse ja iseloomulike joontega.

3.2.13.2.13.2.13.2.1 Six Sigma

Six Sigma on Motorola poolt 1980ndate aastate keskel välja töötatud metoodika protsesside ja tootmise optimeerimiseks. Tänapäeval on see üks tuntumaid metoodikaid, mis on laialdast kasutamist leidnudki eelkõige tootmissektoris, aga ka muudes eluvaldkondades.

Six Sigma keskendub protsessi variatsioonide vähendamisele st. protsessi muudetakse nii, et seal toimuks võimalikult vähe hargnevusi ning eriolukordade lahendamisi. Selle läbi on võimalik protsessi lihtsamalt ja odavamalt automatiseerida. Six Sigma loetakse saavutatuks kui protsessi töökindlus on 99,99966% ehk ühe miljoni protsessi käivituse kohta tekib alla 3,4 vea.

3.2.23.2.23.2.23.2.2 Lean

Lean on 1990ndate alguses levima hakanud, peamiselt tootmisettevõtetes kasutatav protsesside optimeerimise raamistik. Lean põhineb 1940ndate lõpus välja arendatud Toyota Production Systemil. Lean keskendub prügi ehk kõrvaliste tegevuste elimineerimisele protsessist. Eelduseks on, et sellised tegevused on üldteada. Prügiks loetakse tegevusi, mis ei lisa väärtust, mida tehakse mitmel erineval viisil või mille käigus toimub ressursside ülekoormamine. Leani eesmärk on vähendada protsessi läbimiseks kulutatavat aega ning tõsta kvaliteeti.

25

3.2.33.2.33.2.33.2.3 Lean Sigma

Lean Sigma kombineerib Lean ja Six Sigma metoodikad. Samaaegselt tegeletakse protsessi läbimise aja vähendamisega ja protsessi variatsioonide vähendamisega. Selle tulemusena muutub protsess nii kvaliteetsemaks kui lihtsamini korratavaks.

3.2.43.2.43.2.43.2.4 Kaizen

Kaizen tähendab jaapani keeles parendus. Kaizeni lähenemine on sarnane Leanile. Tüüpiliselt kasutatakse Kaizenit kiirete muudatuste tegemiseks. Kaizeni viis põhielementi on meeskonnatöö, isiklik distsipliin, kõrge moraal, kvaliteedi ringid, muudatusettepanekud.

3.33.33.33.3 Protsesside arendamise tehnikad Eelmises peatükis kirjeldatud protsesside arendamise metoodikad panevad paika põhimõtted, millele pööratakse tähelepanu protsesside parendamisel. Lisaks metoodikale on vaja leida ka sobiv tehnika muudetavate või probleemsete kohtade leidmiseks.

Mõned levinumad tehnikad koos lühikirjeldusega on toodud allpool.

3.3.13.3.13.3.13.3.1 Ajurünnak

Ajurünnak on tehnika, kus grupp inimesi pannakse genereerima ideid ilma neid jooksvalt analüüsimata. Genereeritud ideed kogutakse kokku ning analüüsitakse hiljem, sõeludes välja ebaolulise. Paremate ideede puhul viiakse läbi täiendavaid kontrolle nende teostatavuse ja otstarbekuse kohta.

Ajurünnak sobib eelkõige uuenduslike lahenduste sissetoomiseks.

3.3.23.3.23.3.23.3.2 Küsimustike koostamine

Küsimustike koostamine on tehnika, kus koostatakse valitud sihtgruppidele protsessi või mõne tegevuse kohta küsimustik. Sõltuvalt sihtgrupist võib küsimustiku koostada rahulolu uuringu või muudatusettepanekute kogumise eesmärgil. Küsimustik võib olla iseseisvaks täitmiseks või ka abimaterjal intervjuu läbiviimiseks.

Küsimustikud sobivad suure hulga inimeste arvamuse teadasaamiseks.

3.3.33.3.33.3.33.3.3 Algpõhjuse analüüs

Algpõhjuse analüüs (Root cause analysis) on tehnika, kus tuvastatakse probleemid ning analüüsitakse sammhaaval nende tekkimise põhjuseid. Algpõhjuse analüüs aitab leida vastuseid küsimustele mis, kuidas ja miks juhtub. Algpõhjuse analüüsi tulemused visualiseeritakse nö kalaluu (fishbone) diagrammil.

Algpõhjuse analüüs sobib probleemide lahendamiseks, mille tekkepõhjus ei ole teada või ei ole üheselt määratud.

3.3.43.3.43.3.43.3.4 Võrdlev analüüs

Võrdlev analüüs (benchmarking) on tehnika, kus lähenetakse tuvastatud probleemide lahendamisele tsükliliselt. Kõigepealt tuvastatakse kitsaskoht ja määratletakse see võimalikult täpselt, seejärel kogutakse selle jaoks piisaval hulgal andmeid, analüüsitakse andmeid ning koostatakse tegevuskava kitsaskoha kõrvaldamiseks järgides sarnase valdkonna parimaid praktikaid. Muudatuse elluviimisel tsükkel lõppeb ning alustatakse jälle kitsaskohtade otsimist.

Võrdlev analüüs sobib organisatsioonidele, mis on sarnased paljude teiste organisatsioonidega maailmas ning millede jaoks on parimaid praktikaid kogutud.

protsesside analuus ja kaardistamine

Government & Nonprofit