Informacijska rešitev za pregled proceso organizacije · jih pretvarjajo v izhode. Ker je organizacija močno povezana z okoljem, jo z vidika teorije sistemov obravnavamo kot odprt

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO,

RAČUNALNIŠTVO IN INFORMATIKO

Monika Malok

INFORMACIJSKA REŠITEV ZA PREGLED PROCESOV ORGANIZACIJE

Diplomsko delo

Maribor, september 2017

i

INFORMACIJSKA REŠITEV ZA PREGLED PROCESOV ORGANIZACIJE

Diplomsko delo

Študentka: Monika Malok

Študijski program: Univerzitetni študijski program

Informatika in tehnologije komuniciranja

Smer: Informacijski sistemi

Mentor: doc. dr. Gregor Polančič

Lektorica:

Lea Vöröš, dipl. slov. (UN) in prof. ped. (UN)

ii

iii

ZAHVALA

Zahvaljujem se mentorju, doc. dr. Gregorju

Polančiču, za vodenje, nasvete in strokovno

pomoč pri pisanju diplomskega dela.

Posebna zahvala velja mojim bližnjim, ki so mi

v času študija nudili podporo, in vsem ostalim,

ki so na kakršnenkoli način pripomogli k

nastanku diplomskega dela.

iv

Informacijska rešitev za pregled procesov organizacije

Ključne besede: poslovni proces, modeliranje poslovnih procesov, procesna pokrajina

UDK: 658.51:659.21(043.2)

Povzetek

Vsako zaporedje aktivnosti predstavlja nek proces. Za podjetja je pomembno, da se procesov,

ki potekajo znotraj njih, zavedajo ter jih upravljajo, saj lahko tako izboljšajo učinkovitost

poslovanja. V sklopu diplomske naloge so bile raziskane tehnike modeliranja procesnih

pokrajin. Notaciji BPMN in Procesne verige sta bili ocenjeni s stališča primernosti za prikaz

procesnih pokrajin. S stališča modeliranja procesov je bila predstavljena rešitev Signavio,

rešitvi SmartDraw in Draw.io pa s stališča modeliranja procesnih pokrajin. Po študiji literature

in obstoječih rešitev je bila načrtovana in implementirana spletna aplikacija, ki je tudi rezultat

diplomskega dela.

v

IT solution for an overview of organisational processes

Ključne besede: business process, business process modeling, process landscape

UDK: 658.51:659.21(043.2)

Abstract

Each sequence of the activities represents a process. For organizations it is important to

acknowledge and manage them, as doing so can increase effectiveness of the business. As a

part of this thesis, techniques for modeling of the process landscape were researched. BPMN

notation and Value chains were evaluated from the suitability for display of the process

landscape point of view. Existing solution Signavio was presented from a process modeling

perspective while SmartDraw and Draw.io were presented from a process landscape

modeling perspective. Following the study and the research of the literature and existing

solutions, as the result of this thesis, web application was designed and implemented.

https://sl.pons.com/prevod/angle%C5%A1%C4%8Dina-sloven%C5%A1%C4%8Dina/effectiveness

https://sl.pons.com/prevod/angle%C5%A1%C4%8Dina-sloven%C5%A1%C4%8Dina/research

https://sl.pons.com/prevod/angle%C5%A1%C4%8Dina-sloven%C5%A1%C4%8Dina/evaluate

https://sl.pons.com/prevod/angle%C5%A1%C4%8Dina-sloven%C5%A1%C4%8Dina/display

https://sl.pons.com/prevod/angle%C5%A1%C4%8Dina-sloven%C5%A1%C4%8Dina/design

vi

KAZALO VSEBINE

1 UVOD ............................................................................................................................................... 1

1.1 Opredelitev problema .................................................................................................................. 1

1.2 Cilji diplomskega dela ................................................................................................................... 1

1.3 Omejitve diplomskega dela .......................................................................................................... 1

1.4 Osnovne metode diplomskega dela ............................................................................................. 1

1.5 Struktura diplomskega dela .......................................................................................................... 2

2 POSLOVNI PROCESI .......................................................................................................................... 3

2.1 Procesi v organizaciji .................................................................................................................... 4

2.2 Arhitektura procesov in pokrajina procesov ................................................................................ 5

2.3 Tehnike modeliranja pokrajin procesov ....................................................................................... 6

2.3.1 Notacija BPMN ....................................................................................................................... 7

2.3.2 Procesne verige ..................................................................................................................... 9

3 INFORMACIJSKA REŠITEV .............................................................................................................. 11

3.1 Pregled obstoječih rešitev .......................................................................................................... 12

3.1.1 Signavio ................................................................................................................................ 13

3.1.2 SmartDraw ........................................................................................................................... 16

3.1.3 Draw.io ................................................................................................................................ 17

3.2 Specificiranje zahtev in načrtovanje informacijske rešitve ......................................................... 18

3.2.1 Opredelitev zahtev .............................................................................................................. 18

3.2.2 Diagram primerov uporabe in scenariji funkcionalnosti ..................................................... 19

3.2.3 Načrtovanje podatkovne baze ............................................................................................. 24

3.3 Razvoj informacijske rešitve ....................................................................................................... 25

3.3.1 Uvoz procesa ....................................................................................................................... 26

3.3.2 Algoritem za vzpostavitev pokrajine procesov .................................................................... 28

3.3.3 Izris pokrajine procesov ....................................................................................................... 31

4 ZAKLJUČEK ......................................................................................................................................... 32

4.1 Končne omejitve .......................................................................................................................... 32

4.2 Možnosti za nadaljnje delo ......................................................................................................... 33

5 VIRI IN LITERATURA ........................................................................................................................... 34

A PRIMER UPORABE APLIKACIJE: PRIKAZ UPORABNIKOV .................................................................... 36

B PRIMER UPORABE APLIKACIJE: PRIKAZ SEZNAMA PROCESOV .......................................................... 37

C PRIMER UPORABE APLIKACIJE: IZRIS POKRAJINE PROCESOV ........................................................... 38

vii

KAZALO SLIK

Slika 2.1: Sestavni deli poslovnega procesa [1] .......................................................................... 3

Slika 2.2: Procesi glede na nivo abstrakcije ................................................................................ 5

Slika 2.3: Procesna veriga [19].................................................................................................... 9

Slika 3.1: yUml .......................................................................................................................... 12

Slika 3.2: PlantUml .................................................................................................................... 13

Slika 3.3: BPMN-nabori elementov v orodju Signavio ............................................................. 14

Slika 3.4: Čarovnik za dodajanje novih elementov v orodju Signavio ...................................... 14

Slika 3.5: Primer verifikacije procesa ob shranjevanju v orodju Signavio ................................ 15

Slika 3.6: Natančni podatki o validaciji v orodju Signavio ........................................................ 15

Slika 3.7: Predloge, ki jih ponuja orodje Draw.io ..................................................................... 17

Slika 3.8: Diagram primerov uporabe ...................................................................................... 19

Slika 3.9: Grafični vmesnik – registracija podjetja (korak 1) .................................................... 20

Slika 3.10: Grafični vmesnik – registracija podjetja (korak 2) .................................................. 20

Slika 3.11: Grafični vmesnik – registracija podjetja (korak 3) .................................................. 20

Slika 3.12: Grafični vmesnik – dodajanje uporabnika .............................................................. 21

Slika 3.13: Primer elektronskega sporočila, ki se pošlje ob tem, ko je uporabnik dodan ........ 21

Slika 3.14: Grafični vmesnik – ročno dodajanje procesa .......................................................... 22

Slika 3.15: Grafični vmesnik – uvoz procesa ............................................................................ 22

Slika 3.16: Grafični vmesnik – urejanje procesa po uvozu ....................................................... 23

Slika 3.17: Model podatkovne baze ......................................................................................... 24

Slika 3.18: Struktura projekta ................................................................................................... 26

Slika 3.19: Predstavitev nivojske podatkovne strukture .......................................................... 29

Slika 3.20: Primer nadaljevanja podatkovne podstrukture, ko ta že obstaja .......................... 29

KAZALO TABEL

Tabela 3.1: Elementi xml in atributi, ki so pomembni za uvoz ................................................ 27

Tabela 3.2: Elementi, ki se uporabljajo za gradnjo SVG-slike .................................................. 31

viii

SEZNAM UPORABLJENIH KRATIC

SIKOP Sistem Informacij Komunikacij Odločanja in Planiranja BPMN Business Process Model and Notation UML Unified Modelling Language JPA Java Persistence API MVC Model - View- Controller architecture SQL Structured Query Language JSP Java Servlet Pages DOM Document Object Model XML Extensible Markup Language SVG Scalable Vector Graphics PEG Photographic Experts Group GIF Graphics Interchange Format


1

1 UVOD

1.1 Opredelitev problema

Cilj diplomskega dela je razviti rešitev, ki bo podjetjem, ki se zavedajo procesov znotraj

organizacije, omogočala pregled posameznih procesov s poudarkom na medsebojni

povezanosti teh procesov.

Na trgu že obstaja veliko rešitev, ki omogočajo upravljanje s procesi, tj. risanje in urejanje

diagramov, možnosti različnih analiz procesov ipd., mi pa želimo predstaviti rešitev, ki ponuja

izključno pregled nad procesi.

Najpomembnejša funkcionalnost naše informacijske rešitve bo mreža procesov, ki so med

seboj povezani preko vhodov in izhodov, tako da imajo tako vodilni v podjetju kot zaposleni v

vsakem trenutku dostop do informacij o procesu ter so zmožni umestiti sam proces v

procesno shemo podjetja.

Vodilnim v podjetju z našo rešitvijo omogočimo hiter pregled nad procesi, ki potekajo znotraj

podjetja, ter hrambo procesov na skupni lokaciji, zaposlenim pa takojšen dostop do

informacij o samem procesu in produktih, ki morajo nastati znotraj procesa, komu jih naj

posredujejo ...

1.2 Cilji diplomskega dela

Cilj 1: Pregled obstoječih tehnik in rešitev za predstavitev pokrajin procesov.

Cilj 2: Razvoj spletne informacijske rešitve za upravljanje procesov organizacije.

Cilj 3: Vizualizacija procesne sheme (povezava procesov glede na vhode in izhode).

1.3 Omejitve diplomskega dela

Omejitev 1: Omogočen bo samo uvoz formata .bpmn (xml), ne pa tudi .sgx.

Omejitev 2: Preverjanje pravilnosti diagramov in skladnosti z dobrimi praksami

modeliranja procesov ne bo vključeno.

Omejitev 3: Informacijska rešitev bo implementirana v programskem jeziku Java.

Omejitev 4: Uporaba lokalne baze in serverja.

1.4 Osnovne metode diplomskega dela

Študija literature.

Razvoj informacijske rešitve.


2

1.5 Struktura diplomskega dela

V nadaljevanju diplomskega dela bomo za lažje razumevanje problema, ki ga obravnava naša

rešitev, najprej predstavili koncept poslovnega procesa in njegove osnovne značilnosti.

Procese bomo umestili v organizacijo ter jo predstavili z vidika sistema. Na kratko bomo

predstavili arhitekturo procesov, pri čemer se bomo osredotočili predvsem na organizacijske

poslovne procese. Prav tako bomo predstavili nekaj tehnik modeliranja poslovnih procesov

ter raziskali že obstoječe rešitve za prikaz vrhnjega nivoja procesne organiziranosti.

V praktičnem delu naloge se bomo najprej dotaknili problema, ki nastane pri povezovanju

procesov preko njihovih vhodov in izhodov. Predstavili bomo fazo načrtovanja spletne

aplikacije in razvoj glavnih funkcionalnosti.


3

2 POSLOVNI PROCESI

Avtorji poslovni proces opredelijo kot skupek aktivnosti z vnaprej definiranim vrstnim redom

izvajanja1 za dosego skupnega cilja. Aktivnosti so lahko avtomatizirane ali pa se izvajajo z

udeležbo enega ali več posameznikov. Tako procesi kot aktivnosti, ki jih sestavljajo, so med

seboj povezni preko vhodov in izhodov (izhod/rezultat enega procesa/aktivnosti je vhod v

drugega) [1, 2, 3, 6].

Sestava poslovnega procesa je razvidna iz slike 2.1.

Slika 2.1: Sestavni deli poslovnega procesa [1]

V organizaciji vsak proces prispeva k enemu ali več poslovnim ciljem. Da bi ugotovili, kako

učinkoviti so procesi pri doseganju ciljev organizacije, se izvajajo kontrolne aktivnosti [6].

Iz različnih definicij poslovnih procesov lahko hitro prepoznamo nekaj osnovnih značilnosti,

ki bi jih morali biti zmožni prepoznati pri kakršnemkoli obravnavanem procesu. Te so [5]:

cilji procesa,

lastnik procesa,

opredelitev procesa (začetek in konec),

vhodi in izhodi,

zaporedje in koraki v samem procesu,

možnost ugotavljanja učinkovitosti procesa,

ciljne skupine notranjih ali zunanjih kupcev in dobavitelji ter

možnost stalnega izboljševanja.

1 Aktivnosti se lahko izvajajo vzporedno ali zaporedno.


4

2.1 Procesi v organizaciji

Komite za standarde pri razvoju programske opreme (angl. "Software Engineering Standards

Committee") sistem definira kot kolekcijo komponent, ki so organizirane za dosego

specifičnih ali seta funkcij2 [7].

Anton Mihelič sistem opiše kot organizirano celoto, ki je sestavljena iz dveh ali več med seboj

odvisnih delov, komponent oziroma podsistemov in je ločena od svojega okolja z mejami, ki

jih je lahko določiti [8].

Glede na zgornje definicije lahko kaj hitro potegnemo vzporednice med organizacijo in

sistemom, posledično pa lahko organizacijo obravnavamo kot sistem.

Sistemi so lahko glede na vpliv zunanjih faktorjev odprti ali zaprti. Kot pove že samo ime, so

odprti sistemi tisti, ki imajo svoje zunanje okolje. To je od sistema ločeno z bolj ali manj

natančno definirano mejo. Odprti sistemi od okolja sprejemajo vhode (informacije, snovi) in

jih pretvarjajo v izhode. Ker je organizacija močno povezana z okoljem, jo z vidika teorije

sistemov obravnavamo kot odprt in živ sistem [8].

Organizacija je živ sistem, ker v njej potekajo komunikacije – torej obstaja prenašanje

informacij, ki so pomembne za odločanje. Da bi bili rezultati odločitev ugodni, pa je potrebno

planiranje. Glede na prej omenjene procese lahko osnovno delovanje organizacije opišemo s

procesom SIKOP (Sistem Informacij Komunikacij Odločanja in Planiranja) [9].

Organizacijo lahko opišemo s funkcijskega ali procesnega vidika. Funkcijski pristop k

organizaciji predstavlja delitev podjetja glede na funkcije. Ta pristop ni primeren za

upravljanje s procesi, saj je pri izvedbi določenih procesov potrebno vključevanje več

oddelkov, torej funkcij. Na primer celotni proces izdelave nekega izdelka zaobjema

načrtovanje, izdelavo ter preverjanje kakovosti izdelka, torej poteka najmanj preko treh

različnih funkcij v podjetju. Zaradi tega stremimo k procesni organiziranosti podjetja.

2 Angl. "A collection of components organized to accomplish a specific function or set of functions".


5

2.2 Arhitektura procesov in pokrajina procesov

Načrtovanje je pomemben korak pri uspešnem ter učinkovitem reševanju problemov. Načrt

lahko, odvisno od problema, ki se nam predstavi, predstavlja vse od enostavne skice,

entitetno-relacijskega modela, načrta podatkovne baze pa do kompleksne arhitekture

celotne programske rešitve, nove hiše ali v trenutno obravnavanem kontekstu – arhitekture

poslovnih procesov v nekem sistemu.

V sklopu Komiteja za standarde pri razvoju programske opreme so arhitekturo definirali kot

temeljno organizacijo sistema, vključeno v njegove komponente, razmerja med njimi in

okoljem ter principi, ki definirajo njegov prikaz in evolucijo3 [7].

Poslovne procese lahko delimo glede na različne kriterije. Za nadaljnje potrebe te diplomske

naloge bomo na kratko predstavili arhitekturo procesov s stališča delitve procesov glede na

nivo abstrakcije (slika 2.2).

Slika 2.2: Procesi glede na nivo abstrakcije

Nivoje abstrakcije definiramo glede na stopnjo podrobnosti prikaza nekega procesa. Najnižje

v piramidni shemi procesne arhitekture (slika 2.2) se nahajajo implementirani poslovni

procesi, ki nam prikazujejo posamezne procese z največ detajli. Prikazan je procesni tok

(zaporedje aktivnosti v procesu), natančno so definirani vhodi in izhodi procesa, končni

dogodki (proces se lahko konča uspešno ali neuspešno), aktivnostim so določeni akterji –

torej prikaz vsebuje vse potrebne informacije za učinkovito izvajanje posameznega procesa.

Za modeliranje procesov na tem nivoju se uporabljajo notacije, kot je na primer BPMN

(Business Process Model and Notation) [6].

Drugi nivo zaobjema t. i. operativne poslovne procese. Procesni model na tem nivoju že

vključuje poglavitne aktivnosti procesa, vendar je vse skupaj prikazano bolj abstraktno kot

proces na nižjem nivoju. Vsak element po navadi kaže na posamezen proces na nivoju

3 Angl. "Architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution".


6

implementacije, hkrati pa proces sam predstavlja del organizacijskega poslovnega procesa

[6].

Organizacijski poslovni procesi (v nadaljevanju diplomskega dela pokrajina procesov) se

nahajajo v samem vrhu piramidne strukture, prikazane na sliki (2.2). To so visokonivojski

procesi, ki so predstavljeni na zelo abstraktnem nivoju. Pokrajina procesov vsebuje

poglavitne procese v organizaciji ter relacije med njimi, s čimer lastnikom ter udeležencem v

procesih omogoča hiter pregled nad procesi znotraj organizacije in posledično lažje

upravljanje [6]. Procese, ki so predstavljeni znotraj pokrajine procesov, delimo v tri skupine –

glavni, podporni in upravljavski procesi [21].

Ravno zaradi tega se tisti, ki načrtujejo procesno arhitekturo organizacije, srečujejo z največ

izzivi pri definiciji procesne pokrajine, saj je pomembno, da najdejo pravo ravnovesje med

preglednostjo ter zadostno količino informacij za učinkovito upravljanje procesov v

organizaciji [6].

V nadaljevanju diplomske naloge bomo predstavili nekaj tehnik modeliranja pokrajin

procesov, s problematiko definicije procesne pokrajine v mislih pa bomo razvili informacijsko

rešitev, ki bo omogočala delno avtomatizirano združitev procesov nižjih nivojev v procesno

pokrajino.

2.3 Tehnike modeliranja pokrajin procesov

Tako kot imamo poseben nabor znakov za zapis glasbe (note), imamo posebne notacije, s

katerimi zapišemo/narišemo procesne diagrame. Zapis elementov se od notacije do notacije

razlikuje, osnovni nabor elementov pa pri vseh ostaja enak.

Osnovni elementi, ki tvorijo procese, so [18]:

aktivnosti,

dogodki,

prehodi,

povezave (med aktivnostmi, sporočili, podatki, asociacije),

podatki (vhodi, izhodi, objekti, repozitoriji podatkov) in

artefakti (komentar, skupina)4.

Ker je približno četrtina naših možganov namenjena vidu [10], smo ljudje nagnjeni k

vizualnim predstavitvam informacij. Po raziskavah je kar 60 % ljudi vizualnega tipa, torej

zaznavajo pretežno s pomočjo vida [11], zato ni presenetljivo, da se za predstavitev procesov

uporabljajo vizualne notacije. Te informacije predstavijo bolj jedrnato in učinkovito, kot če bi

za njihovo predstavitev uporabili npr. tekstovno oziroma opisno obliko zapisa [12, 13, 14].

4 Vsebujejo dodatne informacije o procesih.


7

Vsaka vizualna notacija je sestavljena iz grafičnih simbolov5. Simbol je predstavitev nekega

elementa v procesu6, ki nam poda informacijo o njegovem poteku [15].

Notacije za predstavitev poslovnih procesov se med drugim razlikujejo tudi glede na njihovo

kompleksnost [16]. V nadaljevanju diplomskega dela se bomo osredotočili na manj

kompleksne, katerih prednost je lažje razumevanje elementov ter s tem boljša preglednost

nad procesom oziroma procesi, kar je eden od primarnih ciljev, h katerim težimo, ko hočemo

predstaviti vrhnji sloj procesne organiziranosti – procesno pokrajino.

2.3.1 Notacija BPMN

BPMN je notacija, ki vsebuje več kot 100 gradnikov, s čimer jo lahko štejemo med dokaj

komplekse. Kljub temu je primerna za začetnike v procesnem modeliranju, saj je ena izmed

njenih poglavitnih prednosti ta, da lahko že iz majhnega nabora osnovnih elementov

pokrijemo večino potreb, ki se pojavijo med modeliranjem, ostale simbole pa bomo brez

večjih problemov osvojili s prakso [1].

Notacija BPMN je že v osnovi zasnovana tako, da pokriva različne vrste modeliranja, pri

čemer lahko tip diagrama hitro prepoznamo iz strukturnih elementov, iz katerih je

sestavljen. Osnovni tipi diagramov, ki jih lahko gradimo z notacijo BPMN, so [18]:

procesni diagram (angl. "Processes orchestration diagram"),

diagram koreografije (angl. "Choreographies diagram") in

diagram sodelovanja (angl. "Collaborations diagram")7.

Diagram komunikacij (angl. "Conversation diagram") predstavlja posebno uporabo in opis

diagrama sodelovanja [18].

Modelirni jezik BPMN prej navedene osnovne elemente modeliranja poslovnih procesov

razdeli v 5 osnovnih kategorij [18]:

• Objekti procesnega toka (angl. "Flow Objects") so glavni grafični elementi, ki

definirajo obnašanje procesa. To so:

o dogodki,

o aktivnosti in

o prehodi.

• Podatki (angl. "Data"):

o podatkovni objekti,

o vhodi,

o izhodi in

o podatkovni repozitoriji.

5 Sintaksa notacije. 6 Semantika notacije. 7 Lahko vsebuje tako diagrame procesov kot diagrame koreografij.


8

• Povezovalni elementi (angl. "Connecting objects") povezujejo objekte

procesnega toka med seboj ali z ostalimi informacijami. Med povezovalne

elemente štejemo:

o tok zaporedja aktivnosti,

o tok sporočil,

o asociacije in

o tok podatkov.

• Bazeni in steze (angl. "Swimlanes") služijo za grupiranje primarnih modelirnih

elementov.

• Z artifakti (angl. "Artifacts") podamo dodatne informacije o procesu. Med

artifakte spadajo:

o skupine in

o komentarji.

Za lažje delo z gradniki notacije BPMN lahko nabor elementov razdelimo v tri razrede [18]:

• Deskriptivni nabor elementov, ki vsebuje vse vidne elemente in atribute, ki jih

potrebujemo pri visokonivojskem modeliranju.

• Analitični nabor elementov, ki vsebuje vse elemente iz deskriptivnega nabora,

skupno pa približno polovico elementov celotnega nabora. Uporabljamo ga za

podrobno modeliranje procesov.

• Izvajalni nabor elementov se osredotoča na nabor, ki je potreben za strojno

izvajanje procesnih modelov.

V sklopu te diplomske naloge se bomo s stališča predstavitve pokrajine procesov osredotočili

predvsem na deskriptivni nabor podatkov, pri čemer bodo procesi predstavljeni kot t. i. črne

škatlice (angl. "black-box").

Za potrebe diplomskega dela smo za grajenje procesov uporabljali notacijo BPMN verzije 2.0.

Ena izmed pomembnih prednosti te verzije je standardizacija serializacije procesov v

strukturo XML (Extensible Markup Language). To smo tudi izkoristili, saj smo procese, ki smo

jih uvažali v našo aplikacijo, zgradili v orodju Signavio ter jih izvozili v formatu .xml. S tem, ko

je serializacija standardizirana, dobimo možnost prenosa procesov med različnimi

modelirnimi orodji (seveda v primeru, da orodja podpirajo uvoz in izvoz procesov). Čeprav je

bila serializacija standardizirana, se še vedno srečujemo z resnim problemom. Pravilnost

serializiranih BPMN-modelov ni zagotovljena. Zaradi tega so definirane različne zahteve in

omejitve, ki jih moramo med gradnjo procesa upoštevati. Ta pravila in omejitve variirajo od

grafičnih (npr. prikaz posameznih gradnikov in oblik) do pravil semantike za izvajanje

procesov [4].

Zgoraj omenjeni problem za nas ne predstavlja težave, saj bomo iz serializiranih zapisov

procesov pridobivali le podatke iz deskriptivnega nabora, ki pa niso tako zelo kompleksni, da

bi lahko povzročali težave pri serializaciji. Katere podatke bomo pridobivali in kako so


9

predstavljeni v zapisu .xml poslovnega procesa, bomo opisali v naslednjih poglavjih

diplomskega dela.

2.3.2 Procesne verige

M. E. Porter predstavi procesne verige kot sistematični način pregleda vseh aktivnosti, ki se

izvajajo znotraj organizacije. Tako procesne verige organizacijo razgradijo na strateško

pomembne aktivnosti [19, 20].

Procesna veriga, kot je razvidno iz slike 2.3, je sestavljena iz aktivnosti, ki se v skladu s

splošno definicijo procesov in aktivnosti delijo na glavne in podporne, ter iz dodane

vrednosti (razlika med skupno vrednostjo in ceno izvedbe procesa).

Zanimivo je, da so v procesni verigi definirane relacije med glavnimi in podpornimi

aktivnostmi (iz diagrama lahko razločimo, na kateri stopnji glavna aktivnost potrebuje

podporno), medtem ko je vrstni red izvajanja primarnih aktivnosti neznan [21].

Slika 2.3: Procesna veriga [19]

Procesna veriga je sicer manj kompleksna od procesnega diagrama, zmodeliranega v BPMN-

notaciji, a še vseeno prikazuje preveč podrobnosti za namene naše diplomske naloge.

M. Malinova v svoji doktorski tezi navaja, da model procesne pokrajine velikokrat bazira na

procesnih verigah. S pomočjo teh so prikazani glavni procesi v organizaciji. Podporni in

upravljavski procesi so predstavljeni z isto obliko puščice, vendar z različno orientacijo [21].

Notacijo BPMN kot primarno notacijo za modeliranje procesnih pokrajin zavrača, saj bi zaradi

preveč detajlnih elementov lahko prišlo do napačnega razumevanja modela – BPMN je

namenjen podrobnemu prikazu procesa, medtem ko predstavitev pokrajine procesov teži k


10

abstraktnosti. Prav tako navaja, da je namen procesnih verig za predstavitev procesov

preozek – porajajo se potrebe po uvedbi dodatnih konceptov, ki jih modeliranja verige ne

omogočajo. Kot alternativo zgoraj omenjenima notacijama predlaga tekstualno obliko

zapisa, ki bo za razliko od BPMN-diagramov omogočila nedvoumno predstavitev konceptov

[21].


11

3 INFORMACIJSKA REŠITEV

Pri razvoju informacijske rešitve za pregled pokrajine procesov ne bomo ločevali med tipi

procesa, torej nas ne bo zanimalo, če proces spada v skupino glavnih, podpornih ali

upravljalskih procesov, pač pa bomo vse obravnavali enako. Zaradi tega uporabnikom

priporočamo, da se pri uporabi naše aplikacije osredotočijo le na glavne procese.

Za prikaz procesa znotraj procesne pokrajine smo se odločili, da bomo uporabili element

pravokotnika, ki zaradi svoje enostavnosti doprinese k preglednosti procesne pokrajine. Prav

tako nas pravokotnik kot uporabnike BPMN-notacije asociira na gradnik za predstavitev

bazena, ki predstavlja posamezen proces.

Med generiranjem procesne pokrajine bomo povezave med procesi vzpostavljali s pomočjo

vhodov in izhodov. Ti elementi so v procesnih diagramih predstavljeni kot podatkovni

objekti. Ker se pri naši rešitvi osredotočamo le na vhode in izhode, ki so vezani na začetni

oziroma končni dogodek, je problem, ki se pri tem pojavi, sledeč.

Informacija ali izdelek (v nadaljevanju podatkovni objekt) je lahko produkt celotnega procesa

ali le neke aktivnosti znotraj njega. Prav tako ni nujno, da je podatkovni objekt v procesu

prisoten že ob začetku izvajanja. Čisto normalno je, da se proces začne brez vhoda, je pa

znotraj procesa aktivnost, ki rabi dodatno informacijo. V takem primeru lahko pride

podatkovni objekt v proces ob začetku ter se prenaša naprej ali pa se ga vključi šele na točki,

ko ga dejansko potrebujemo.

Poleg tega, da ne moremo zagotoviti, da bodo vsi vhodi in izhodi v procese imeli stik le z

začetnim ali končnim dogodkom, tudi ne moremo z gotovostjo trditi, da bo izhod nekega

procesa vhod v naslednjega. Tako lahko proces tvori nek izhod, ta pa bo vhod procesu šele

kasneje v procesni verigi – med procesoma se bo zvrstil en ali več drugih procesov.

Prav tako ni nujno, da imajo vsi procesi vhode in/ali izhode, kar pa ne pomeni, da tak proces

ni vključen v procesno verigo. Proces brez vhoda lahko ima predhodnika in proces brez

izhoda naslednika.

Zaradi tega se pri vzpostavljanju povezav med procesi ne moremo zanašati le na vhode in

izhode, saj ni nujno, da nam bodo dali popolno predstavo o povezavah med procesi.

Da bi se zgoraj opisanemu problemu izognili, bomo za potrebe informacijske rešitve dodali

nov element k opisu procesa, in sicer referenco na naslednji proces. S tem uporabnikom

omogočimo, da procese med seboj povežejo neposredno. Tako zagotovimo, da se procesna

veriga nadaljuje, čeprav proces nima nobenega vhoda in/ali izhoda.


12

3.1 Pregled obstoječih rešitev

Pred predstavitvijo naše informacijske rešitve bomo najprej pregledali nekaj že obstoječih

orodij za modeliranje poslovnih procesov.

Orodja za definiranje procesov lahko v grobem razdelimo na modelirna (angl. "modeling") in

diagramska (angl "drawing") orodja, vendar je kljub delitvi lahko orodje modelirno in

diagramsko hkrati [22, 23, 24].

Orodje lahko definiramo kot diagramsko, če ima podporo za risanje diagramov – tako orodje,

ki je sposobno izrisati besedilne definicije elementov, ni nujno diagramsko. Med besedilna

modelirna orodja spadajo yUml, Nomnoml, PlantUML in podobni [22].

Na spodnjih slikah lahko vidimo kodo ter rezultat diagrama aktivnosti, sestavljenega z

orodjem yUml8 (slika 3.1), in diagrama sodelovanja, kreiranega s pomočjo orodja PlantUml9

(slika 3.2).

Slika 3.1: yUml

8 Dostopno na: https://yuml.me/diagram/scruffy/activity/draw [Poskus dostopa 3. 9. 2017]. 9 Dostopno na: http://plantuml.com/ [Poskus dostopa 3. 9. 2017].

http://www.nomnoml.com/

http://plantuml.sourceforge.net/

https://yuml.me/diagram/scruffy/activity/draw

http://plantuml.com/


13

Slika 3.2: PlantUml

Prednost modelirnih orodij je, da omogočajo verifikacijo diagramov, saj temeljijo na meta

modelih. Modelirna orodja so običajno namenjena določeni notaciji, zato prepoznavajo

namen gradnikov [22, 23]. Taka orodja niso najbolj primerna za predstavitev procesnih

pokrajin, saj za to obstajajo le smernice, ne pa specifična notacija oziroma predpisana

semantika [21].

Med drugimi med modelirna orodja zaradi preverjanja semantike spada orodje Signavio, ki

pa prav tako zaradi možnosti grafičnega grajenja procesov spada med diagramska orodja.

Na drugi strani imamo diagramska orodja, katerih poglavitna prednost je, da je modeliranje

procesov enostavno za začetnika, saj ni potrebno poznavanje sintakse določene notacije [23,

24]. Uporabnik običajno s principom "povleci in spusti" (angl. "drag and drop") sestavlja svoj

proces. Ta orodja ne preverjajo pravilnosti sestavljenih diagramov, zato so za predstavitev

procesnih pokrajin primernejša od modelirnih orodij. Med diagramska orodja spadajo npr.

Visio, Draw.io in SmartDraw.

V nadaljevanju poglavja bomo na kratko predstavili orodje Signavio, saj ga uporabljamo za

kreiranje posameznih procesov, ki jih potem lahko uvozimo v našo aplikacijo, orodji Draw.io

in SmartDraw pa bomo predstavili s stališča modeliranja procesne pokrajine.

3.1.1 Signavio

Orodje Signavio10 torej spada med modelirna orodja. Da lahko verificira diagrame, ob

kreiranju novega dokumenta izberemo tip diagrama, ki ga želimo ustvariti. Izbiramo lahko

med v drugem poglavju omenjenimi tipi diagramov, ki temeljijo na BPMN-notaciji (procesni

diagram, diagram koreografije in diagram sodelovanja), UML-diagrami (Unified Modelling

Language; razredni diagram, diagram primerov uporabe), procesnimi verigami in ostalimi.

Za generiranje procesnega diagrama izberemo diagram poslovnega procesa (angl. "Business

process diagram"). Ker smo izbrali diagram, ki uporablja BPMN-notacijo, imamo možnost

10 Dostopno na: https://www.signavio.com/ [Poskus dostopa: 3. 9. 2017]


14

izbire prikaza različnih naborov elementov (slika 3.3). Deskriptivni, analitični in izvajalni

nabor elementov smo predstavili v drugem poglavju. Osnovni (angl. "core") vsebuje osnovne

gradnike za grajenje procesov, celotni nabor pa vse gradnike BPMN-notacije. Pri prikazu

katerega od kompleksnejšega naborov elementov (vsi, razen osnovnega), so elementi

razvrščeni in prikazani po kategorijah (glej poglavje 2).

Slika 3.3: BPMN-nabori elementov v orodju Signavio

Orodje Signavio omogoča dva načina grajenja procesov. Elemente lahko s principom "povleci

in spusti" dodajamo na delovno površino in jih potem ročno med seboj povezujemo ali pa

uporabimo čarovnika za dodajanje novih elementov. Ob kliku na posamezni gradnik, ki ga že

imamo na delovni površini, nam orodje Signavio ponudi možnosti za vezavo gradnikov (slika

3.4). Ob izbiri naslednjega gradnika v procesni verigi se na delovno površino doda gradnik,

hkrati se pa ustvari povezava med elementoma.

Slika 3.4: Čarovnik za dodajanje novih elementov v orodju Signavio

Ko zgradimo procesni diagram in ga hočemo shraniti, Signavio preveri pravilnost diagrama.

Odpre se nam okno, v katerem lahko določimo ime datoteke, dodamo opis, na dnu okna pa

nam orodje prikaže število napak, opozoril in priporočila (slika 3.5).


15

Slika 3.5: Primer verifikacije procesa ob shranjevanju v orodju Signavio

Ob kliku na puščico desno se okno za shranjevanje procesa zapre. Namesto njega se odpre

tabela, v kateri so predstavljene napake in opozorila – ta so označena tudi na diagramu (slika

3.6)

Slika 3.6: Natančni podatki o validaciji v orodju Signavio

Tako nam Signavio pomaga, da so diagrami, ki jih v njem ustvarimo, skladni z dobrimi

praksami modeliranja procesov.


16

3.1.2 SmartDraw

Orodje SmartDraw11 ponuja osnovne predloge za raznovrstne diagrame, kar olajša ter

pospeši postopek izdelave izbranega tipa diagrama. Glede na ponujene predloge se izkaže

kot raznovrstno orodje – omogoča izdelavo procesnih diagramov, miselnih vzorcev, form,

različnih ikonografskih diagramov pa vse do specializiranih diagramov kot različnih

zdravstvenih prikazov (od razčlembe celice do celotnega človeškega organizma) ali celo

arhitekturnih predlog (tlorisi, krajinsko načrtovanje ipd.). Glede na njegovo raznovrstnost ter

pokritost specifičnih področij navduši bolj kot orodje, ki bi ga lahko učinkovito uporabljali za

ustvarjanje učnih pripomočkov in predstavitev, kot orodje za modeliranje procesov.

Orodje sicer ponuja predlogo za procesno mapo, torej pokrajino procesov, vendar primeri

prikazujejo posamezne procese in ne le vrhnjega sloja. Prav tako je osnovni nabor gradnikov,

ki se odpre, če izberemo to predlogo, namenjen za kreiranje posameznega procesa. Nabori

gradnikov za posamezni modelirni sklop so definirani kot knjižnice. Če izberemo knjižnico

"Process Mapping", dejansko dobimo gradnike, ki so jih razvijalci orodja namenili za grajenje

pokrajine procesov.

SmartDraw omogoča intuitivno dodajanje elementov le s klikanjem na puščice (gor, dol, levo

desno). Tip elementa, ki ga želimo vezati na trenutnega, izberemo s seznama elementov.

Orodje prav tako omogoča kostumizacijo posameznega elementa ali skupine podobnih

elementov. Enostavno spreminjamo tip povezave, meje elementov (barva, tip črte) in polnilo

elementa (barva, gradient, tekstura, vzorec). Prav tako lahko vsem elementov diagrama

nastavljamo prosojnost.

S kostumizacijo lahko navadne in monotone procesne diagrame spremenimo v barvite in

zabavne, zaradi česar se orodje znova izkaže kot učinkovito za pripravo pripomočkov za

poslovne predstavitve.

11 Dostopno na: https://www.smartdraw.com/ [Poskus dostopa: 3. 9. 2017].


17

3.1.3 Draw.io

Orodje Draw.io12 prav tako kot SmartDraw ponuja nekaj osnovnih predlog oziroma primerov

za gradnjo raznovrstnih diagramov, kar lahko vidimo na sliki 3.7.

Slika 3.7: Predloge, ki jih ponuja orodje Draw.io

Za gradnjo procesnih pokrajin sicer ne ponuja predloge ali nabora elementov, vendar se da iz

osnovnih gradnikov (ali gradnikov izbrane notacije) brez pretiranih naporov definirati svojo

notacijo za prikaz procesne pokrajine.

Podobno kot v prej predstavljenem orodju gradnja diagramov ne predstavlja velikega

problema. S klikom na puščico ob izbranem elementu lahko prav tako enostavno dodamo

nov element, ki je povezan s trenutnim. Za razliko od SmartDrawa, kjer lahko s klikom na

element iz seznama elementov izberemo, kateri element želimo dodati, lahko v orodju

Draw.io na tak način dodajamo le elemente enakega tipa.

12 Dostopno na: https://www.draw.io/ [Poskus dostopa: 3. 9. 2017].


18

3.2 Specificiranje zahtev in načrtovanje informacijske rešitve

Preden se lotimo izdelave informacijske rešitve, je pomembno, da jo dobro načrtujemo, saj si

tako lahko prihranimo veliko časa in težav pri implementaciji. V tem podpoglavju bomo na

kratko opisali nekaj korakov načrtovanja naše aplikacije.

3.2.1 Opredelitev zahtev

Za dober načrt in posledično rešitev je pomembno, da dobro razumemo cilj, ki ga želimo

doseči. V našem primeru je to aplikacija, ki omogoča pregled procesne pokrajine. Da bi

uporabnikom omogočili čim boljšo uporabniško izkušnjo, smo si zastavili naslednje osnovne

cilje/zahteve:

• registracija podjetja,

• urejanje podatkov o podjetju,

• registracija uporabnika (v okviru podjetja),

• odločanje o uporabniških pravicah uporabnika (v okviru podjetja),

• izbris uporabnika (v okviru podjetja),

• dodajanje procesa,

• urejanje procesa,

• odstranitev procesa,

• uvoz procesa in

• grafični prikaz povezanosti procesov znotraj organizacije.


19

3.2.2 Diagram primerov uporabe in scenariji funkcionalnosti

Za lažjo predstavo različnih vlog ter povezav med osnovnimi funkcionalnostmi aplikacije naj

služi diagram primerov uporabe (angl. "Use case diagram"), ki je predstavljen na sliki 3.8.

Slika 3.8: Diagram primerov uporabe

Iz diagrama je razvidno, da imamo dva tipa uporabnikov. Navaden uporabnik se lahko

registrira (a šele po tem, ko ga je administrator dodal v sistem), prijavi v sistem, pregleda

seznam uporabnikov in procesov ter diagram procesne pokrajine. Uporabnik, ki je tipa

administrator, lahko doda uporabnika in spreminja njegove administratorske pravice. Prav

tako lahko dodaja in ureja procese. Iz diagrama je razvidno, da poleg uporabnikov naše

aplikacije obstaja še tretji akter. To je ponudnik spletne pošte, ki se vključi v proces

dodajanja uporabnika, in sicer na stopnji, ko se uporabniku pošlje elektronsko sporočilo, da

se lahko registrira v sistem.

V nadaljevanju poglavja bomo s pomočjo načrtov grafičnih vmesnikov predstavili pozitivni scenarij nekaterih funkcionalniosti.

Registracija podjetja:

• podjetje se odloči za uporabo naše aplikacije,

• administrator podjetja vstopi v postopek registracije,

• administrator podjetja izpolni podatke o podjetju (korak 1) (slika 3.9),


20

Slika 3.9: Grafični vmesnik – registracija podjetja (korak 1)

• administrator podjetja izpolni podatke o administratorju (korak 2) (Slika 3.10),


• administrator se prijavi (korak 3) (slika 3.11),



21

• zgodi se preusmeritev na stran organizacije.

Dodajanje uporabnika:

• administrator doda uporabnikov elektronski naslov in določi, če bo uporabnik imel

administratorske pravice ali ne (slika 3.12),

Slika 3.12: Grafični vmesnik – dodajanje uporabnika

• uporabnik dobi elektronsko sporočilo, da lahko začne uporabljati aplikacijo (slika

3.13),

Slika 3.13: Primer elektronskega sporočila, ki se pošlje ob tem, ko je uporabnik dodan

• s klikom na povezavo v elektronskem sporočilu uporabnik pride na stran za

registracijo,

• uporabnik vnese svoje podatke (korak 1) (enak grafični vmesnik kot za registracijo

administratorja pri registraciji podjetja),

• uporabnik se prijavi v sistem (korak 2),

• zgodi se preusmeritev na stran matične organizacije.

Dodajanje procesa:

• administrator klikne na gumb za dodajanje procesa,

• administratorju se odpre nova stran, kjer lahko izbere, ali bo proces dodal ročno ali

ga bo uvozil,

• če administrator izbere ročno dodajanje procesa, se mu odpre forma, kjer vnese

podatke o procesu (slika 3.14), polje "next process" se prikaže le, če ima podjetje že

dodan kak proces,


22

Slika 3.14: Grafični vmesnik – ročno dodajanje procesa

če administrator izbere uvoz procesa, preko vmesnika izbere datoteko, ki jo želi uvoziti (slika 3.15),

Slika 3.15: Grafični vmesnik – uvoz procesa

iz vsebine izbrane datoteke se preberejo osnovni podatki o procesu,

administratorju se odpre enaka forma kot pri ročnem dodajanju procesa, le da je

tokrat preizpolnjena s podatki, ki so prišli v sistem z uvozom procesa (slika 3.16),


23

Slika 3.16: Grafični vmesnik – urejanje procesa po uvozu

administrator lahko podatke o procesu dopolni oziroma spremeni,

s klikom na gumb "Shrani" se proces shrani v podatkovno bazo.


24

3.2.3 Načrtovanje podatkovne baze

Za shranjevanje podatkov o registriranih podjetjih, njihovih procesih in uporabnikih bomo

uporabili podatkovno bazo. Načrt podatkovne baze smo naredili s pomočjo entitetno-

relacijskega modela (slika 3.17).

Slika 3.17: Model podatkovne baze

Kot je razvidno iz modela, je naša baza dokaj preprosta. Sestavljajo jo 4 entitete: uporabnik

(v modelu entiteta "User"), organizacija (v modelu entiteta "Organization"), proces (v

modelu entiteta "Process") in povezovalni element (v modelu entiteta "ConnectionElement).

Vse entitete so vezane na organizacijo, saj lahko obstajajo le znotraj njenih okvirjev. Entiteta

povezovalni element hrani vhode v procese in izhode iz procesov. S procesom jo povežemo

preko primarnega ključa elementa, in sicer je v entiteti proces ta shranjen kot tuji ključ v

polju "input", če element predstavlja vhod v proces, in v polju "output", če predstavlja izhod

iz procesa. Povezava, ki jo je še smiselno razložiti, je krožna povezava procesa s samim sabo.

Ta relacija ena proti mnogo služi za shranjevanje dodatnega elementa, ki smo ga definirali za

povezovanje procesov. Kardinalnost ena je na strani procesa, ki ga shranimo v trenutni

proces kot tuji ključ v polje "nextProcessId", kardinalnost mnogo pa nam pove, da lahko ta

proces vključimo v poljubno število drugih procesov.


25

3.3 Razvoj informacijske rešitve

Pred začetkom razvoja informacijske rešitve smo se odločili za orodja in tehnologije, ki jih

bomo uporabili.

Informacijska rešitev je razvita v programskem jeziku Java. Za izvajanje kode na strani

odjemalca smo uporabljali Javascript. Kodo aplikacije smo razvijali v razvojnem okolju IntelliJ

IDEA.

Projekt je maven projekt. Za vzpostavitev projekta smo za osnovo vzeli spring-boot projekt,

ki sam vzpostavi ogrodje za aplikacijo. V projekt smo vključili naslednje dependencyje:

spring-boot-starter-web,

tomcat-embed-jasper,

jstl,

spring-boot-starter-data-jpa,

mysql-connector-java in

spring-boot-starter-mail.

Prve tri dependencyje s seznama rabimo za razvoj spletne aplikacije, mysql connector in jpa

dependency nam služita za uporabo in povezavo z mysql bazo, starter-mail pa za pošiljanje

elektronskih sporočil ob dodajanju uporabnikov.

Za uporabo baze smo se odločili za MySql. Uporabljali smo MySql Workbench in MySql

Community Server, ki smo ga poganjali lokalno. Povezavo z bazo smo vzpostavili s pomočjo

mysql connectorja. Za shranjevanje in delo z objekti smo uporabili JPA (Java Persistence API).

Za to smo se odločili, ker smo lahko tako bazo kreirali s pomočjo anotacij neposredno iz Java

kode, prav tako pa JPA sam poskrbi za enostavne operacije nad objekti (shranjevanje,

pridobivanje ene ali več objektov). Za kompleksnejša povpraševanja smo poskrbeli sami.

Projekt je zasnovan v skladu z arhitekturo MVC (model-view-controller), ki smo jo še

dodatno razčlenili. Zasnova projekta je prikazana na sliki 3.18.


26

Slika 3.18: Struktura projekta

Paket "Beans" vsebuje razrede, ki skrbijo za generiranje tabel ter atributov v bazi. Vsebuje

torej entitete, s katerimi operiramo na nivoju baze. Povpraševanja SQL (Structured Query

Language) so shranjena v razredih, ki so v paketu "Dao". S stališča JPA so to repozitoriji. Po

MVC-arhitekturi bi do razredov dao lahko dostopali kar s kontrolerjev, mi smo pa uvedli še

dva vmesna nivoja, in sicer servise ter fasade. Razredi na servisnem nivoju so edini, ki delajo

neposredno z repozitoriji. Tu rezultatom, ki jih dobimo s pomočjo metod v repozitorijih,

lahko dodamo poslovno logiko. Fasade skrbijo za pretvarjanje objektov, s katerimi delamo na

nivoju baze, v objekte, ki jih uporabljamo v kontrelerjih in JSP (Java Servlet Pages). V paketu

"Forms" imamo definirane forme, ki jih uporabljamo za zajem podatkov s form na

uporabniškem vmesniku, paket "Utils" pa vključuje funkcionalnosti, ki ne spadajo na

nobenega od zgoraj naštetih nivojev oziroma jih lahko uporabljamo vsepovsod.

V nadaljevanju poglavja bomo na kratko predstavili nekatere ključne funkcionalnosti

informacijske rešitve.

3.3.1 Uvoz procesa

Ena izmed prvotno zastavljenih specifikacij za razvoj aplikacije je bila možnost uvoza procesa.

Pri uvozu smo se omejili le na format .bpmn (xml).

Med programskim branjem datoteke ne prepoznavamo vseh elementov, temveč le tiste, ki

jih rabimo, da lahko proces shranimo. Za zajemanje podatkov smo uporabili parser DOM

(Document Object Model). Podatki, ki se avtomatsko zajamejo z uvozom procesa, so naziv

procesa, vhod in izhod.

V tabeli 3.1 so predstavljeni elementi xml, ki smo jih prepoznavali, atributi, ki so bili za nas

pomembni, ter razlaga, zakaj so bili pomembni za uvoz.


27

Tabela 3.1: Elementi xml in atributi, ki so pomembni za uvoz

XML-element Atribut Namembnost

process Element, ki opiše proces. Njegovi podelementi vključujejo informacije, pomembne za predstavitev procesa.

name Naziv procesa

dataObject Element, ki predstavlja podatkovni objekt – pozneje so ti elementi shranjeni kot vhodi/izhodi v procese.

id Id elementa – služi nam, da definiramo, če je podatkovni objekt vhod v proces oziroma izhod iz procesa.

name Naziv vhoda oziroma izhoda.

dataObjectReference Vmesni element med asociacijo in podatkovnim objektom.

dataObjectRef Predstavlja id podatkovnega objekta.

id Id elementa – uporabljen kot referenca v asociaciji.

association Element, ki predstavlja povezave med podatkovnimi objekti in procesnimi gradniki.

sourceRef Predstavlja vir (začetek) povezave.

targetRef Predstavlja vir (konec) povezave.

Tip podatkovnega objekta, torej če je zajeti podatkovni objekt vhod ali izhod, določimo s

pomočjo elementa "association". Element "association" obstaja le, če je podatkovni objekt

vezan na začetni ali končni dogodek. Če je vezan na kateri drugi element, se za povezavo

med podatkovnih objektom in tem elementom uporablja "dataInputAssociation" ali

"dataOutputAssociation". Če ima element referenco podatkovnega objekta "association"

definirano v atributu "sourceRef", je podatkovni objekt vhod, če je kot atribut "tagretRef" pa

izhod.

Spodnji izsek kode prikazuje del procesiranja strukture xml, da bi pridobili podatke o

produktu.

HashMap<String, String> dataObjectReferenceMap = new HashMap<>();

ArrayList<String> associatioMapSources = new ArrayList<>(); ArrayList<String>

associatioMapTargets = new ArrayList<>();

DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();

DocumentBuilder dBuilder = dbFactory.newDocumentBuilder();

Document doc = dBuilder.parse(file);

doc.getDocumentElement().normalize();

NodeList xmlProcess = doc.getElementsByTagName("process");

NamedNodeMap processAttributes = xmlProcess.item(0).getAttributes();

process.setProcessTitlE(processAttributes.getNamedItem("name").getNodeValue());

NodeList dataObjects = doc.getElementsByTagName("dataObject");


28

3.3.2 Algoritem za vzpostavitev pokrajine procesov

Za lažji izris pokrajine procesov smo uvedli novo strukturo "ProcessMap". Je rekurzivna

podatkovna struktura, saj vsebuje listo same sebe. Vse procese neke organizacije

premapiramo v to strukturo s pomočjo rekurzije13. Osnovna elementa, s katerima gradimo

strukturo naprej, sta trenutni proces tipa "Process" in lista elementov podatkovnega tipa

"ProcessMap". Listo na nultem nivoju sestavljajo procesi, ki nimajo ne vhodnega elementa

ne predhodnega procesa. Vsakemu elementu v listi pripišemo novo listo elementov ter

trenutni proces. Listo sestavljajo elementi, katerih predhodni proces je trenutni proces, ali

elementi, katerih vhodi so izhodi trenutnega procesa. Če ima proces nastavljeno referenco

13 Rekurzija je tehnika programiranja, pri kateri pri definiciji funkcije, postopka ali jezikovnega konstrukta uporabimo to isto funkcijo, postopek ali jezikovni konstrukt. Povzeto po: http://www.islovar.org/islovar [Poskus dostopa: 3. 9. 2017].

if(dataObjects.getLength()>0) {

NodeList associations = doc.getElementsByTagName("association");

NodeList dataObjReferences = doc.getElementsByTagName("dataObjectReference");

for (int i = 0; i < associations.getLength(); i++) {

NamedNodeMap associationAttributes = associations.item(i).getAttributes();

associatioMapSources.add(associationAttributes.

getNamedItem("sourceRef").getNodeValue());

associatioMapTargets.add(associationAttributes.

getNamedItem("targetRef").getNodeValue());

}

for (int i = 0; i < dataObjReferences.getLength(); i++) {

NamedNodeMap dataObjReferencesAttributes =

dataObjReferences.item(i).getAttributes();

dataObjectReferenceMap.put(dataObjReferencesAttributes.

getNamedItem("dataObjectRef").getNodeValue(),

dataObjReferencesAttributes.getNamedItem("id").getNodeValue());

}

for (int i = 0; i < dataObjects.getLength(); i++) {

String key = dataObjects.item(i).getAttributes().

getNamedItem("id").getNodeValue();

String value;

if(dataObjectReferenceMap.containsKey(key)){

value = dataObjectReferenceMap.get(key);

if(associatioMapSources.contains(value)){

input= dataObjects.item(i).getAttributes().

getNamedItem("name").getNodeValue();

}

else if(associatioMapTargets.contains(value)){

output = dataObjects.item(i).getAttributes().

getNamedItem("name").getNodeValue();

}

}

}

}


29

na naslednji proces, se vzpostavi povezava preko reference ne glede na to, če ima proces

izhode ali ne. Veriga procesnih struktur se konča, ko zadnji proces nima ne izhoda ne

reference na naslednji proces. Proces generiranja strukture se začne z naslednjim

elementom iz liste na nultem nivoju (slika 3.19). Če je bil proces že obravnavan, se veriga

tam konča, saj imamo podstrukturo tistega procesa enkrat že definirano (slika 3.20).

Za lažjo predstavo naj služita sliki 3.19 in 3.20.

Slika 3.19: Predstavitev nivojske podatkovne strukture

Slika 3.20: Primer nadaljevanja podatkovne podstrukture, ko ta že obstaja


30

Slika 3.20 prikazuje primer, v katerem dve različni procesni verigi uporabljata enako

procesno podverigo. V tem primeru se bo na točki 2 proces generiranja strukture ustavil, saj

imamo od točke 1 naprej podstrukturo že sprocesirano, ter se bo nadaljeval s procesom na

točki 3.

Spodnji izsek kode ponazarja generiranje podstrukture.

ProcessMap map = new ProcessMap();

map.setCurrentProcess(process);

map.setPreviousProcess(idCurrentProcess);

//determines if it is last process or his substructure was allready

processed

if(process.getNextProcessId()!=null || process.getOutput()!=null)

map.setEnd(false);

else

map.setEnd(true);

//so we dont process same process substructure twice

if(!wasAllreadyInTheProcess.get(process.getId())){

wasAllreadyInTheProcess.put(process.getId(), true);

ArrayList<ProcessMap> submaps= new ArrayList<>();

if (process.getNextProcessId()!=null){

submaps.add(generateSubStructure(processHashMap.get

(process.getNextProcessId()), process.getId()+""));

}

else if(process.getOutput()!=null){

if(inputs.get(process.getOutput())!=null){

for(Process p : inputs.get(process.getOutput())){

submaps.add(generateSubStructure(processHashMap.get

(p.getId()),process.getId()+""));

}

}

}

map.setNextProcesses(submaps);

}

else{

if (process.getNextProcessId()!=null){

map.setNextProcessIds(process.getNextProcessId()+"");

}

else if(process.getOutput()!=null){

if(inputs.get(process.getOutput())!=null){

for(Process p : inputs.get(process.getOutput())){

map.setNextProcessIds(p.getId() +"");

}

}

}

}

return map;


31

3.3.3 Izris pokrajine procesov

Za izris pokrajine procesov se kot osnova uporablja struktura, ki je bila predstavljena v

prejšnjem podpoglavju. Na tem koraku zgenerirano strukturo preslikamo v sliko SVG

(Scalable Vector Graphics)v izbrani notaciji.

Kot že samo ime pove, je SVG-slika, ki je definirana z vektorji. Zaradi tega jo lahko

povečujemo in zmanjšujemo, brez da bi imeli izgube pri kvaliteti slike. To je tudi ena izmed

poglavitnih prednosti pred formatoma JPEG (Joint Photographic Experts Group) in GIF

(Graphics Interchange Format). Koda slike je zapisana s formatom xml, zato jo lahko

ustvarimo in urejamo s kakršnimkoli urejevalnikom besedila14. Ravno zaradi tega smo jo

izbrali za predstavitev procesne pokrajine.

SVG-sliko sestavljamo v Java kodi. Podobno kot pri generiranju osnovne strukture tudi sliko

sestavljamo s pomočjo rekurzije. Sprehodimo se po podatkovni strukturi, ki smo jo

predstavili v prejšnjem sklopu. Ker vsak element v podatkovni strukturi predstavlja proces, za

vsako tako vozišče izrišemo kvadratek z nazivom procesa znotraj njega. Če ima ta proces

naslednika, med njima izrišemo tudi povezavo – puščico.

Za prikaz procesne pokrajine uporabljamo elemente, prikazane v tabeli 3.2.

Tabela 3.2: Elementi, ki se uporabljajo za gradnjo SVG-slike

Element Uporaba

svg Določimo platno, na katerem bomo risali – s tem, ko elementu določimo višino in širino, definiramo velikost platna.

rect Pravokotnik, ki na sliki predstavlja proces – velikost pravokotnik določimo z višino in širino.

text S tem elementom dodamo ime procesa v sredino pravokotnika.

polyline Narišemo povezave med procesi in puščice – potek črte definiramo s pomočjo atributa "points". S koordinatami definiramo začetek, konec ter morebitne vmesne točke črte.

14 Povzeto po: https://www.w3schools.com/graphics/svg_intro.asp [Poskus dostopa: 3. 9. 2017].


32

4 ZAKLJUČEK

V diplomskem delu smo najprej na kratko predstavili poslovne procese, njihove značilnosti

ter notacijo BPMN in Procesne verige. Ugotovili smo, da nobena od predstavljenih notacij s

svojega stališča ni primerna za prikaz pokrajin procesov. Prav tako smo predstavili tehnike in

rešitve za modeliranje pokrajin procesov. Pri pregledu že obstoječih rešitev smo ugotovili, da

nobena od izbranih rešitev ni namenjena modeliranju pokrajin procesov, čeprav ga

omogočajo. S tem smo zadostili cilju 1, ki smo si ga zastavili ob zasnovi diplomske naloge –

pregled obstoječih tehnik in rešitev za predstavitev pokrajine procesov.

V nadaljevanju diplomskega dela smo predstavili problematiko, s katero se srečamo, če

hočemo procese med seboj povezovati preko vhodov in izhodov. Prav tako smo razložili,

kako se bomo s tem spopadli mi. Za potrebe povezovanja procesov med seboj smo tako

uvedli dodatni element – referenco na naslednji proces.

Da bi dosegli cilj 2 (razvoj spletne informacijske rešitve za upravljanje procesov organizacije),

smo naredili načrt spletne aplikacije. Fazi načrtovanja je sledila implementacija.

Glavna cilja aplikacije, ki smo si ju zadali pred razvojem, sta bila uvoz procesa in vizualizacija

procesne sheme (cilj 3). V diplomski nalogi smo najprej predstavili proces načrtovanja

aplikacije, na koncu pa funkcionalnosti, ki smo jih implementirali za dosego prej omenjenih

ciljev.

Diplomsko delo je primarno namenjeno podjetjem, ki se zavedajo procesov znotraj

organizacije. Ker razvita informacijska rešitev ponuja le pregled procesov, je namenjena le

tistim, ki želijo imeti hiter pregled nad vrhnjim slojem procesov. Tako naša informacijska

rešitev pripomore k učinkovitejšemu upravljanju s procesi.

Sekundarno je teoretični del diplomskega dela namenjen širši množici, ki želi spoznati

osnovni koncept poslovnega procesa, arhitekturo procesov ter tehnike modeliranja

poslovnih procesov. Ker smo na kratko opisali tudi nekatera orodja za modeliranje poslovnih

procesov, lahko diplomsko delo koristi tudi tistim, ki se odločajo, katero orodje bi uporabili

za modeliranje procesne pokrajine.

4.1 Končne omejitve

Aplikacija je le v angleškem jeziku – lokalizacija ni podprta.

Vsak proces ima lahko le en vhod in en izhod.

Pri uvozu procesa se upoštevajo le tisti vhodi, ki so vezani na začetni dogodek, in

izhodi, ki so vezani na končnega.

Za izris pokrajine procesov je uporabljena le ena oblika izrisa procesov – kvadrat.


33

4.2 Možnosti za nadaljnje delo

Omejitve, ki smo jih definirali pred začetkom diplomskega dela, in končne omejitve ponujajo

možnosti za razširitev naše aplikacije. Ena izmed osnovnih razširitev aplikacije bi bila, da

uporabnikom ponudimo možnost za pregled podrobnosti procesa. To bi lahko dosegli s tem,

da bi uporabniki naložili SVG-sliko procesa. Nadaljnja nadgradnja te funkcionalnosti je

razširitev uvoza procesa tako, da poleg osnovnih informacij o procesu, shranimo še vse

ostale in sliko izrišemo sami. Nadgradnja, ki ji lahko določimo visoko prioriteto, je nadgradnja

na področju izrisa procesne pokrajine. Trenutno aplikacija ponuja le eno obliko izrisa

procesov. To je pravokotnik, ki izhaja iz BPMN-notacije. Tako bi lahko uvedli še prikaz, ki bi

temeljil na primer na Procesnih verigah, torej puščico.

Prav tako pomemben korak nBdgradnje naše aplikacije bi bil, da bi jo naložili na spletni

strežnik ter tako omogočili dostop širši množici uporabnikov. Da bi uporabnikom aplikacijo še

približali, bi njeno vsebino lahko lokalizirali. Tako bi vsak uporabnik aplikacijo lahko

uporabljal v svojem maternem jeziku.


34

5 VIRI IN LITERATURA

[1] M. Dumas, M. La Rossa, J. Mendling in H. A. Reijers, Fundamentals of Business Process

Management, Berlin: Heidelberg: Springer, 2013.

[2] M. B. Jurič in K. Pant, Business process driven SOA using BPMN and BPEL: from

business process modeling to orchestration and service oriented architecture,

Birmingham: Packt Publishing, 2008.

[3] P. Harmon, Business process change: A Guide for Business Managers and BPM and Six

Sigma Professionals, 2. izdaja, Burlington: Elsevier, 2007.

[4] M. Geiger, G. Wirtz. BPMN 2.0 Serialization - Standard Compliance Issues and Evaluation of Modeling Tools. In: 5th International Workshop on Enterprise Modelling and Information Systems Architectures, St. Gallen, Switzerland, september 2013. Dostopno na: https://www.uni-bamberg.de/fileadmin/uni/fakultaeten/wiai_lehrstuehle/praktische_informatik/Dateien/Publikationen/emisa13-geiger-camReady.pdf [Poskus dostopa 20. 9. 2017].

[5] A.Mihelič,B. Škafar (2008). Učbenik:Poslovni procesi, Zavod IRC, Ljubljana, 208.

Dostopno na:

http://www.mizs.gov.si/fileadmin/mizs.gov.si/pageuploads/podrocje/vs/Gradiva_ESS/I

mpletum/IMPLETUM_62EKONOMIST_Posl_procesi_Mihelic.pdf [Poskus dostopa 5. 8.

2017].

[6] M. Weske, Business process management: Concepts, Languages, Architectures, 2.

izdaja Berlin: Heidelberg: Springer, 2012.

[7] IEEE Recommended Practice for Architectural Description of SoftwareIntensive

Systems. IEEE Std 1471-2000, pages i–23, 2000. doi: 10.1109/IEEESTD.2000.91944.

[8] A. Mihelič Organizacija poslovanja. Novo mesto: Ekonomska šola, Višja strokovna šola,

2004.

[9] A. Vila, J. Kovač Osnove organizacije in menedžmenta. Kranj: Založba Moderna

organizacija, 1998.

[10] S.M. Kosslyn, Graphics and Human Information Processing, Journal of the American

Statistical Association, Izv. 80, št 391, pp 499–512, 1985.

[11] A. Peklenik, Poslovno kuminuciranje. Kranj B&B, izobraževanje in usposabljanje,

2008/09.

[12] T. De Marco, Structured Analysis and System Sprecification, Yourdon Press, pp. 1–7 in

37-44, 1978.

[13] J. Bertin, Semiology of Graphics: Diagrams, Networks, Maps, The University of

Wisconsin Press, 1983.

[14] P. Goolkasian, Pictures, Words and sounds: From Which Format Are We Best Able to

Reason?, The Journal of General Psychology, Izv 127, št 4, pp 439–459, 2000.

[15] D. L. Moody, P. Heymans, R. Matulevičius, Visual sytax does matter: improving the

cognitive effectiveness of the i* visual notation, Requirements Engineering, Izv 15, št 2,


35

pp 141-175. Dostopno na: https://link.springer.com/article/10.1007/s00766-010-0100-

1 [Poskus dostopa 5. 8. 2017].

[16] J. Valent, Primerjava notacij za modeliraje poslovnih procesov iz vidika podpore

procesnim vzorcem: diplomsko delo, september 2015. Dostopno na:

https://dk.um.si/IzpisGradiva.php?id=54212 [Poskus dostopa 5. 8. 2017].

[17] G. Polančič, Modeliranje poslovnih procesov z BPMN, 2. izdaja, 2014. Dostopno na:

https://estudij.um.si/mod/folder/view.php?id=93855. [Poskus dostopa 5. 8. 2017].

[18] OMG, Business Process Model and Notation (BPMN), v2.02, 20 januar 2014. Dostopno

na: http://www.omg.org/spec/BPMN/2.0.2 [Poskus dostopa 5. 8. 2017].

[19] Michael E Porter. Competitive advantage: Creating and sustaining superior

performance. SimonandSchuster. com, 2008.

[20] R. Kaplinsk, M. Morris, Mike. A handbook for value chain research. Brighton, England:

Institute of Development Studies, University of Sussex, 2001.

[21] M. Malinova. A Language for Designing Process Maps: Doctoral thesis, Vienna

University of Economics and Business, Vienna, Austria, 2016.

[22] J. Cabot. Drawing tools vs modeling tools. MOdeling LAnguages, 2011. Dostopno na:

https://modeling-languages.com/drawing-tools-vs-modeling-tools/ [Poskus dostopa 3.

9. 2017].

[23] Shannon. Modeling and Draing Tools - What's the Difference?. GenMyModel, 2014.

Dostopno na: http://blog.genmymodel.com/modeling-and-drawing-tools-whats-the-

difference.html [Poskus dostopa 3. 9. 2017].

[24] K. Hicks. Drawing Tools and Process Modeling: The Benefits and Limitations. BPTrends,

2012. Dostopno na:

http://www.bptrends.com/publicationfiles/Microsoft_Word__09_04_2012_ART_Drawi

ng_Tools_and_Process_Modeling_Hicks_final.pdf [Poskus dostopa 3. 9. 2017].

https://dk.um.si/IzpisGradiva.php?id=54212

https://estudij.um.si/mod/folder/view.php?id=93855

http://www.omg.org/spec/BPMN/2.0.2

https://en.wikipedia.org/wiki/Raphael_Kaplinsky

https://globalvaluechains.org/publication/handbook-value-chain-research


36

A PRIMER UPORABE APLIKACIJE: PRIKAZ UPORABNIKOV


37

B PRIMER UPORABE APLIKACIJE: PRIKAZ SEZNAMA

PROCESOV


38

C PRIMER UPORABE APLIKACIJE: IZRIS POKRAJINE

PROCESOV


39


40


41


42

Documents

Informacijska rešitev za pregled proceso organizacije · jih pretvarjajo v izhode. Ker je organizacija močno povezana z okoljem, jo z vidika teorije sistemov obravnavamo kot odprt