--------------------------- doc. dr Milan Zdravković. Mašinski fakultet u Nišu, Inženjerski menadžment, studijski profil Industrijski menadžment, master studije, 1.godina --------------------------- Pristup online kursu: http://ekursevi.masfak.ni.ac.rs:9000/courses/course-v1:MEF+UPRO+2019-20_S2/about

1. 1
Predmet Upravljanje procesima
Predavanje 2: BPMN
Modeli poslovnih procesa se koriste u različitim fazama životnog ciklusa BMP-a. Pre
nego što se krene sa modeliranjem procesa vrlo je važno da se definiše svrha tog
modeliranja. U zavisnosti od razloga modeliranja i modeli će izgledati različito. Od mnogih
razloga za modeliranje prvi je pokušaj da se proces shvati i da se to predstavi na način da
model mogu da razumeju i ljudi koji svakodnevno koriste taj proces. Učesnici u procesu
najčešće uočavaju samo svoje aktivnosti, tako da često ne sagledavaju celinu procesa.
Modeliranje procesa može da pomogne da se proces bolje shvati i da se identifikuju i spreče
eventualni problemi. Potpuno upoznavanje sa procesom je preduslov za njegovu analizu,
redizajn i automatizaciju.
Uvod u BPMN (Business Process Modeling Notation)
BPMN je prilično složen jezik, koji se koristi za modeliranje procesa. U njemu postoji
veliki broj simbola. Počećemo sa jednostavnim procesom naručivanja.
Slika 1: Dijagram procesa naručivanja proizvoda
Kao što je već pomenuto, poslovni proces sadrži dogaĎaje i aktivnosti. DogaĎaji
predstavljaju stvari koje se dešavaju trenutno (na primer, primljen je ugovor), dok se aktivnosti
odnose na jedinice posla koje imaju neko trajanje (plaćanje ugovora). Proces, dogaĎaji i
aktivnosti su logički povezani. Najjednostavniji oblik te veze je sekvenca, što označava da
posle dogaĎaja ili aktivnosti A, sledi dogaĎaj ili aktivnost B. U skladu sa ovim, osnovni
koncepti u BPMN-u su dogaĎaj, aktivnost i tok. DogaĎaji se predstavljaju krugovima,
aktivnosti pravougaonicima sa zaobljenim uglovima, a tokovi se predstavljaju linijama sa
strelicama.
Na slici 1 je prikazan niz aktivnosti koje modeliraju proces naručivanja. Proces počinje
kad god se od kupca primi poružbenica. Prva aktivnost je potvrda narudžbe. Nakon toga se
odreĎuje adresa za isporuku, proizvod se isporučuje, posle čega se pravi ugovor, nakon čega
sledi plaćanje i arhiviranje narudžbenice.
Sa slike se može videti da su dva dogaĎaja opisana sličnim, ali ipak pomalo različitim
simbolima. Početak se obeležava krugom sa tanjom linijom, a kraj krugom sa debljom linijom.
Ovi dogaĎaji označavaju početak i kraj instance procesa. U primeru sa narudžbenicom
proces počinje kad god se primi nova narudžbenica i završava se njenim arhiviranjem.
Ako bi se ovo odvijalo u nekom preduzeću, onda bi svakog dana postojao odreĎen broj
instanci procesa, pri čemu su sve te instance meĎusobno nezavisne. Kad se jednom pokrene
instanca procesa, za praćenje toka procesa se koristi pojam tokena. Tokeni se kreiraju na
početku instance procesa i prate tok kroz proces, dok se ne doĎe do kraja, kad se uništavaju.
Tokeni se opisuju tačkama na modelu procesa. Na slici 2 su prikazane tri instance opisanog

2. 2
procesa. Jedna instanca je tek krenula (crni token kod početnog dogaĎaja), druga je kod
isporuke proizvoda (crveni token kod aktivnosti isporuke) i treća je kod plaćanja (zeleni
token).
Slika 2: Praćenje tri instanci procesa
Svakoj aktivnosti treba dati odgovarajuće ime. Isto se odnosi i na dogaĎaje. Ako se
označi početni dogaĎaj, onda se lako može videti šta je to što taj proces pokreće, dok ime
krajnjeg dogaĎaja omogućava da vidimo kada se i kako proces završava.
Grananje i spajanje
Aktivnosti i dogaĎaji ne moraju da se obavezno odvijaju sekvencijalno. Na primer, ako
se radi o procesu rukovanja zahtevom za osiguranjem, aktivnosti odobravanja i odbijanja
zahteva isključuju jedna drugu. To znači da se te dve aktivnosti ne mogu obavljati paralelno.
Kada dve ili više aktivnosti predstavljaju alternative jedna drugoj, kaže se da se one uzajamno
isključuju.
Razmotrimo drugačiju situaciju. U procesu rukovanja zahtevom za osiguranjem, kad se
zahtev jednom odobri, podnosilac o tome biva obavešten i vrši se isplata. Obaveštavanje i
isplata su dve aktivnosti koje obično obavljaju dva različita odeljenja, pošto su u pitanju
aktivnosti koje su meĎusobno nezavisne i ne moraju da se obavljaju redom. One se mogu
izvršavati istovremeno, odnosno paralelno. Kada aktivnosti nisu meĎusobno zavisne kaže se
da su uporedne.
Ovakvo ponašanje se modelira pomoću kapije. Termin kapija ukazuje na to da postoji
mehanizam koji dozvoljava ili zabranjuje prolaz kroz nju. Kada do kapije stignu podaci, oni se
mogu spojiti ili podeliti u zavisnosti od tipa kapije.
Kapije se označavaju rombovima i postoje kapije za spajanje i razdvajanje (engl. split i
join). Kapija tipa split je tačka u kojoj dolazi do razdvajanja procesa, dok je join mesto gde se
tokovi procesa spajaju. Kapija tipa split ima jedan ulazni tok i više izlaznih, dok kapije tipa join
imaju više dolaznih tokova, a jedan izlazni.
Isključive odluke
Za označavanje podele na dve ili više alterativnih aktivnosti koristi se isključivi split
(XOR). Za spajanje se koristi XOR join. XOR kapija se predstavlja rombom u kome se nalazi
slovo X.
Pogledajmo na primer, proces provere ugovora (slika 3). Kada se od kupca primi
ugovor on treba da se proveri za slučaj da u njemu postoji neka greška. Posle provere može
da se desi da nema grešaka u kom slučaju ugovor može da se pošalje, da postoje greške
koje se mogu ispraviti, u kom slučaju se ugovor ponovo šalje do kupca, kao i da postoje
greške koje se ne mogu ispraviti u kom slučaju se ugovor blokira. Kad se izvrši jedna od ovih
aktivnosti ugovor se skladišti i proces se završava.

3. 3
Slika 3: Primer XOR kapija
Model procesa počinje aktivnošću Provera ugovora. Ova aktivnost je aktivnost u kojoj
se donose odluke, što znači da iz nje vodi više izlaza. U primeru aktivnost ima tri različita
moguća izlaza, koji su svi uzajamno isključivi. Ovo će se modelirati pomoću XOR splita koji
ide iza aktivnosti. Izlazi vode do različitih aktivnost "Slanje ugovora", "Ponovno slanje ugovora
do kupca" i "Stopiranje ugovora".
Grana koja vodi ka stopiranju ugovora je označena kosom crticom. Ovo se može
koristiti za označavanje grane koja je podrazumevana, odnosno koja će se izvršiti ako svi
uslovi koji izlaze iz kapije budu netačni.
Nakon što se izvrši jedna od tri alternative, one se spajaju u jedan tok pomoću
aktivnosti skladištenje ugovora. Za ovo se koristi XOR join (spajanje).
Paralelno izvršenje
Ako izmeĎu dve ili više aktivnosti ne postoje nikakve zavisnosti vezane za redosled (ni
jedna od njih ne mora da sledi posle druge), onda se one mogu izvršavati paralelno. Za
modeliranje takve relacije se koristi paralelna kapija tipa AND. Za modeliranje paralelnog
izvršenja dve ili više grana se koristi AND razdvajanje (engl. AND split), dok se za
sinhronizaciju izvršenja tih grana koristi AND spajanje (engl. AND join). Kapija tipa AND se
označava rombom sa znakom plus u sredini.
Na slici 4 je prikazan primer provere sigurnosti na aerodromu. Nakon što preuzmu
karte, putnici idu na proveru. Tamo treba da proĎu skeniranje tela i prtljaga. Nakon toga mogu
da produže do aviona. Proces se sastoji od četiri aktivnosti. Počinje se aktivnošću Transport
do provere sigurnosti, a završava aktivnošću Transport do terminala. Ove dve aktivnosti su
očigledno zavisne jedna od druge. Putnik može da ode do terminala, samo ako je pre toga
prošao sigurnosne provere. Posle prve, a pre poslednje aktivnosti treba da se izvrše još dve
aktivnosti. Redosled po kojem će se one dve izvršavati nije bitan. To su aktivnosti Skeniranje
osobe i skeniranje prtljaga. Ovo se modelira pomoću dve kapije tipa AND. Jedna se postavlja
posle aktivnosti transport do provere sigurnosti, a druga pre aktivnosti transport do terminala.

4. 4
Slika 4: Primer upotrebe kapije tipa AND
Ovde treba obratiti pažnju na to da se aktivnost transport do terminala ne može izvršiti
dok se ne završe obe aktivnosti koje se odvijaju paralelno.
Da pogledamo sada proširenu verziju primera sa popunjavanjem narudžbe.
Pretpostavka je da se narudžbenica popunjava samo ako deo postoji na zalihama. Ako dela
nema na zalihama proces se završava odbijanjem narudžbe. Ako je narudžba potvrĎena,
prezima se adresa za isporuku i traženi proizvod se isporučuje. U isto vreme se šalje i ugovor
i vrši plaćanje. Na kraju se narudžba arhivira, čime se proces završava.
Novi model je prikazan na slici 6.
Slika 6: Proširena verzija procesa naručivanja
Kao što se vidi u modelu postoje dve aktivnosti koje se uzajamno isključuju. To su
aktivnosti Potvrda narudžbe i Odbijanje narudžbe. One se modeliraju pomoću XOR split
kapije. Aktivnosti OdreĎivanje adrese za isporuku i isporuka, kao i aktivnosti Slanje ugovora i
prijem plaćanja mogu da se obavljaju nezavisno, pa su zbog toga modelirane pomoću AND
split kapije i AND join kapije. Ove dve grupe aktivnosti obično u organizaciji obavljaju različiti
resursi (prodavac i neko iz odeljenja finansija).

5. 5
Ako se ova proširena verzija modela uporedi sa prvobitnom, vidi se da ovde postoje
dva dogaĎaja koji označavaju kraj procesa. U BPMN modelu može postojati više dogaĎaja
koji označavaju kraj procesa. Svaki od njih se odnosi na različit način završetka i izlaza iz
procesa.
U BPMN-u se koristi tzv. implicitna semantika završetka, što znači da se instanca
procesa završava samo ako svaki token koji teče kroz model stigne do krajnjeg dogaĎaja. Na
isti način mogu da postoje i više dogaĎaja početka procesa.
Uključive odluke
Ponekad je potrebno da se posle aktivnosti u kojoj se donosi odluka izvrši jedna ili više
drugih grana. Pogledajmo proces distribucije narudžbe.
Preduzeće ima dva magacina u kojima se skladište različite vrste proizvoda. Jedno
skladište je u Amsterdamu, a drugo u Hamburgu. Kad se primi nova narudžba ona se
obraĎuje u ovim magacinima. Ako se neki proizvod nalazi u Amsterdamu tamo se šalje deo
narudžbe, a ako se neki proizvod nalazi u Hamburgu i tamo se šalje deo narudžbenice. Na
kraju se narudžba registruje i proces se završava.
Ovakav scenario se može modelirati pomoću kapija tipa AND i XOR. Kod takvog
modeliranja, meĎutim, postoje odreĎeni problemi. Na slikama 7 i 8 su prikazana dva moguća
rešenja.
Kod prvog rešenja se koristi XOR split, sa tri alternativne grane. Jedna se izvršava ako
u narudžbi postoje samo proizvodi koji se skladište u Amsterdamu, druga ako su u pitanju
isključivo proizvodi koji se nalaze u Hamburgu i treća, ako se u narudžbi nalaze i proizvodi iz
Amsterdama i Hamburga. U tom slučaju se delovi narudžbe šalju i u jedno i u drugo skladište.
Slika 7: Prvi pokušaj modeliranja
Iako ovakav model ispravno opisuje scneario, rezultujući dijagram je komplikovan, jer
smo morali da dupliciramo dve aktivnosti koje šalju podnarudžbe do odgovarajućih magacina.
Ako bismo imali više od dva magacina, dijagram bi postao još složeniji.

6. 6
Kod drugog rešenja je upotrebljena AND split kapija, sa dva izlaza, od kojih svaki vodi
ka jednoj XOR kapiji sa dve alternativne grane. Jedna se izvršava ako narudžba sadrži
proizvode iz Amsterdama (Hamburga), u kom slučaju postoji dodatna aktivnost slanja
podnarudžbe u Amsterdam (Hamburg), a druga grana se koristi ako narudžba ne sadrži
proizvode iz odgovarajućeg magacina. U tom slučaju se ništa ne dešava, sve dok se ne doĎe
do XOR spajanja, posle čega se proces nastavlja.
Slika 8: Drugi pokušaj modeliranja narudžbe sa dva magacina
Problem sa drugim modelom je u tome da pored tri osnovne mogućnosti koje proces
poznaje, a to je da su u narudžbenici proizvodi iz Amsterdama ili Hamburga ili iz oba
magacina, postoji još jedna mogućnost, a to je da proizvod nije ni u jednom magacinu. Ovo je
slučaj kad se izvrše dve prazne grane kod XOR deljenja. To znači da ovo rešenje ne može da
se primeni.
Za modeliranje situacija kada odluka vodi ka tome da se mogu izvršiti više opcija u
istom trenutku, koristi se uključiva (OR) kapija za razdvajanje (engl. OR split). Ova kapija je
slična sa XOR split kapijom, ali uslovi u izlaznim granama ne moraju da se uzajamno
isključuju, odnosno više njih može biti tačno u istom trenutku. Kad se naiĎe na OR split
nastavlja se sa jednom ili više grana u zavisnosti od izlaznih uslova. Ako se govori o
tokenima, to znači da OR split prima ulazni token i generiše onoliko izlaznih koliko je izlaznih
uslova zadovoljeno, pri čemu taj broj mora biti najmanje 1 i najviše jednak broju izlaznih
grana. I kod OR split kapije može da postoji podrazumevana grana, koja se izvršava ako su
svi uslovi netačni.
Na slici 9 je prikazano rešenje prethodnog primera, ali sada sa OR kapijom. Nakon što
se podnarudžba pošalje do jednog ili oba skladišta, pomoću OR spajanja se tok sinhronizuje,
nakon čega se nastavlja sa registracijom narudžbe. Ono što sledi posle OR spajanja se
izvršava tek kad se sve aktivne grane završe. OR spajanje čeka na završetak samo aktivnih
grana. Kad doĎu tokeni iz svih aktivnih grana, oni se spajaju u jedan, koji se šalje dalje. Ovaj
dogaĎaj se naziva sinhronizovanim spajanjem.

7. 7
Slika 9: Modeliranje isključive odluke pomoću OR kapija
Ponovno izvršenje posla i ponavljanje
Sve strukture su do sada bile linearne, odnosno svaka aktivnost se obavljala najviše
jednom. Ponekad je potrebno da se jedna ili više aktivnosti ponove. Razlozi mogu biti različiti,
kao što je na primer, ponovno izvršenje posla jer kontrola nije dozvolila nastavak.
Na primer, ako se u ministarstvu primi neki zahtev, on se prvo registruje od strane
sistema. Nakon toga se taj zahtev ispiituje, tako da može da se pripremi odgovor
ministarstva. Odgovor priprema službenik ministarstva, ali pre slanja treba da ga pregleda
odgovorni sekretar. Ako sekretar ne odobri odgovor, on se vraća nazad do službenika, koji ga
je pripremao. Proces se završava kad se odgovor odobri.
Modeliranje ponavljanja posla traži da se prvo identifikuju aktivnosti koje treba da se
ponavljaju. U prethodnom primeru, to su aktivnosti Priprema odgovora ministarstva i Pregled
odgovora ministarstva. Možemo ih nazvati blokom koji se ponavlja. Za ovaj blok važi da
poslednja aktivnost u bloku mora biti aktivnost u kojoj se donosi odluka. To nam omogućava
da odlučimo da li se proces vraća nazad, pre početka bloka koji se ponavlja, ili se nastavlja
dalje. Ova aktivnost, prema tome, treba da ima dva izlaza. Aktivnost u kojoj se donosi odluka
je u ovom slučaju Pregled odgovora ministarstva, a izlazi iz nje su: "odgovor je odobren" (u
kom slučaju se proces nastavlja) i "odgovor nije odobren" (u kom slučaju se počinje iz
početka). Ovo se modelira pomoću kapije tipa XOR split, koja ima dva izlaza. Jedan izlaz
omogućava nastavak procesa, a drugi vraćanje nazad.
Slika 10: Model procesa komunikacije sa ministarstvom
Tokovi informacija
Poslovni proces obuhvata različite organizacione aspekte, kao što su funkcije, poslovni
podaci, ljudi i softverski sistemi. Različiti aspekti se modeliraju iz različitih perspektiva. Do
sada smo se upoznali sa funkcionalnom perspektivom, koja obuhvata aktivnosti koje se

8. 8
odvijaju u procesu, kao i sa perspektivom kontrole toka, koja ukazuje na redosled odvijanja
aktivnosti i dogaĎaja. Još jedna vrlo važna perspektiva je perspektiva podataka. Ova
perspektiva pokazuje koje informacije (poslovni dokumenti, datoteke) su potrebne za
obavljanje aktivnosti, kao i koje informacije nastaju kao rezultat odvijanja aktivnosti.
Da pogledamo proces naručivanja, ali sada sa podacima. Prvo ćemo definisati koji su
podaci potrebni za odvijanje svake aktivnosti, a onda i podatke koji nastaju kao rezultat
izvršenja aktivnosti. Prva aktivnost u procesu je, na primer, Provera zaliha. Ona kao ulaz traži
naružbenicu, jer pomoću nje proverava da li su traženi proizvodi na zalihama. Isti dokument je
potreban i za aktivnost Provera raspoloživosti sirovina, ako proizvod treba da se napravi.
Dokumenti kao što je narudžbenica se u BPMN-u nazivaju objektima podataka. Ovi
objekti opisuju tok informacija u i iz aktivnosti. To mogu biti fizički objekti, kao što su ugovor ili
pismo, ali mogu biti i u digitalnom formatu, kao što su elektronska poruka ili datoteka. Sve ovo
se grafički označava ikonicom dokumenta, sa savijenim uglom. Sa aktivnostima se ovi objekti
povezuju tačkastim linijama, sa otvorenim strelicama (veze podataka). Na slici 11 se može
videti kako ovo izgleda.
Slika 11: Proces naručivanja sa podacima

9. 9
Pomoću strelica se označava da li objekat podataka ulazi ili izlazi iz aktivnosti. Na
primer, objekat Narudžbenica (Purchase order) je ulazni objekat za aktivnost provere
raspoloživosti zaliha. Ako je potrebno isti objekat se može više puta prikazati na dijagramu,
da bi se izbegle mnogobrojne linije, koje bi presecale elemente dijagrama.
Često je izlaz iz jedne aktivnosti ulaz u narednu aktivnost. Objekti podataka
omogućavaju modeliranje tok informacija izmeĎu aktivnosti u procesu. Treba imati na umu da
objekti podataka i njihove veze sa aktivnostima ne mogu da zamene tok izvršenja procesa.
To znači da, čak i ako je neki objekat prosleĎen od aktivnost A do aktivnosti B, i dalje treba
modelirati da iza aktivnosti A sledi aktivnost B. Skraćena oznaka da se jedan objekat
prosleĎuje do druge je kad se objekat podataka poveže sa linijom toka koja povezuje te dve
aktivnosti (objekat Shipment Address na slici).
Ubacivanje objekta podataka na dijagram procesa može da usloži dijagram, tako da se
pdoaci prikazuju samo ako za to postoje dobri razlozi, na primer, ako treba pojasniti nešto u
toku procesa ili ako se planira automatizacija.
Ponekad je potrebno da se u model procesa ubace dodatne informacije, koje
povećavaju čitljivost modela. Na primer, u procesu sa prethodne slike, možemo definisati da
aktivnost isporuka proizvoda obuhvata i pakovanje. Takve dodatne informacije se na model
ubacuju pomoću tekstualnih napomena. Napomena se označava pravougaonikom bez jedne
stranice i povezana je sa elementom procesa tačkastom linijom. Napomene nemaju nikakvo
semantičko značenje, pa ne utiču na tokene koji se kreću kroz proces.
Resursi
Još jedan aspekt na koji treba obratiti pažnju tokom modeliranja poslovnog procesa je
perspektiva resursa. Resursi ukazuju na to ko ili šta obavlja aktivnost. Resurs je opšti termin
koji se odnosi na bilo koga ili bilo šta što obavlja aktivnost. Resurs može biti:
Učesnik u procesu, odnosno pojedinac, kao što je na primer Petar Petrović.
Softverski sistem, na primer, neki server ili aplikacija
Oprema, kao što je štampač ili mašina.
Postoje aktivni resursi, odnosno resursi koji mogu da samostalno obave aktivnost i
pasivni resursi, koji su samo uključeni u obavljanje aktivnosti. Na primer, fotokopirni aparat će
učesnik koristiti za kopiranje dokumenta. U tom slučaju je aparat pasivni resurs, dok je radnik
aktivni.
Kad se govori o modeliranju procesa, obično se posmatraju aktivni resursi. Obično se
u modelu ne prikazuju konkrektne osobe, već se prikazuje grupa resursa koji su meĎusobno
zamenljivi, tako da bilo koji član grupe može da obavi aktivnost. Takve grupe se nazivaju
klasama resursa. Primeri grupa mogu biti organizacione jedinice ili uloge.
Pogledajmo proces naručivanja. Njega izvršava organizacija prodavac, koja se sastoji
od dva odeljenja. To su odeljenje prodaje i odeljenje skladištenja i distribucije. Narudžbenica
koja se prima u odeljenju skladištenja se proverava u pogledu zaliha. Ovu operaciju
automatski obavlja ERP sistem, koji upit šalje u bazu podataka. Ako je proizvod na zalihama,
on se vadi iz magacina pre nego što prodaja potvrdi narudžbu. Posle toga prodaja pravi
ugovor i čeka na plaćanje, dok se proizvod iz odeljenja skladištenja isporučuje. Proces se
završava arhiviranjem narudžbe, koje radi odeljenje prodaje. Ako proizvoda nema na
zalihama ERP sistem u odeljenju skladištenja proverava da li postoje zalihe sirovina potrebne
za izradu proizvoda. Ovo se radi pretraživanjem kataloga snabdevača. Kad se jednom dobije

10. 10
materijal, o proizvodnji ponovo brine odeljenje skladištenja i distribucije. Proces se završava
potvrdom narudžbe i njenim arhiviranjem, što radi odeljenje prodaje.
Za modeliranje resursa se u BPMN-u koriste dva elementa. To su pulovi i staze. Pul se
koristi za modeliranje klase resursa, dok se staza koristi za podelu pula na podklase i
pojedinačne resurse. Pul se obično koristi za modeliranje cele organizacije (kao što je
prodavac u prethodnom primeru), dok se staza koristi za modeliranje odeljenja, tima ili
softverskog sistema.
U primeru je pul Prodavac podeljen na dve staze. Jedna označava odeljenje
skladištenja i distribucije, a druga odeljenje prodaje. Staze se mogu gnezditi jedna u okviru
druge, čime se postiže dalje grananje. Na primer, ako treba da se modeliraju i odeljenje i
uloge u tom odeljenju, za odeljenje se može upotrebiti jedna spoljašnja Staza, a onda se
svaka uloga predstavlja jednom unutrašnjom stazom. U primeru naručivanja, unutar staze
Skladištenja i distribucije je ubačena staza koja predstavlja ERP sistem u tom odeljenju.
Pulovi i staze se crtaju kao pravougaonici u okviru kojih se mogu da postave aktivnosti,
dogaĎaji, kapije i objekti podataka. Obično se ovi pravougaonici postavljaju horizontalno,
mada je moguće da se postave i po vertikali. Ime pula ili staze je prikazano sa leve strane ili
na vrhu.
Vrlo je važno da se aktivnosti postave u pravu staze. Na primer, aktivnost provera
zaliha je postavljena u stazu ERP sistema. Ovim se ukazuje na to da tu aktivnost automatski
izvršava ERP sistem. Isto važi i za dogaĎaje. U primeru je dogaĎaj Primanje narudžbe
postavljen u stazu ERP sistema, da ukaže na to da proces počinje unutar ERP sistema u
odeljenju skladištenja i distribucije.
Slika 12: Proces naručivanja sa stazama i pulovima

11. 11
Nije važno gde se postavljaju objekti podataka, jer su oni vezani za aktivnosti. Kapije
tipa XOR i OR se postavljaju u istu stazu u kojoj su i aktivnosti koje im prethode, dok se kapije
tipa AND mogu postaviti bilo gde.
Predstavljanje podprocesa
Ako se modeliraju složeni poslovni procesi, model koji tom prilikom nastaje može biti
suviše velik da bi ga bilo lako pratiti. Pogledajmo proces sa slike 12. Iako je u pitanju scenario
koji je relativno jednostavan, model već sadrži 14 aktivnosti, šest kapija i dva dogaĎaja. Ako
se još dodaju objekti sa podacima i tok poruka, model postaje još veći. U cilju poboljšanja
čitljivosti modela proces se može pojednostaviti ako se, u okviru podprocesa, sakriju pojedini
delovi procesa.
Podproces predstavlja samostalnu, složenu aktivnost, koja se može podeliti na manje
jedinice posla. Slično ovom, atomska aktivnost (zadatak) je aktivnost koja pokriva jednu
jedinicu posla koja se dalje ne može deliti.
Da bi podproces mogao da se koristi potrebno je prvo identifikovati grupu povezanih
aktivnosti, odnosno aktivnosti koje zajedno postižu konkretni cilj ili generišu konkretan izlaz. U
primeru sa naručivanjem, postoje aktivnosti Provera raspoloživosti sirovina i Kupovina
sirovina od Snabdevača, koje zajedno čine nabavku materijala. Ove dve aktivnosti i kapije
koje ih povezuju, mogu da se izdvoje u podproces. Drugim rečima, ove aktivnosti se mogu
posmatrati kao interni koraci makro aktivnosti "Nabavka sirovina". Slično ovom dve paralelne
grane za isporuku i fakturisanje narudžbe mogu da se grupišu u okviru jedne aktivnosti
(podprocesa) po imenu "Isporuka i fakturisanje". Na slici 13 je prikazan novi model. Ove
aktivnosti su na dijagramu predstavljene zaobljenim pravougaonikom koji okružuje interne
aktivnosti. U okviru svakog podprocesa su dodati i dogaĎaji početka i kraja, čime se
eksplicitno označava kada proces počinje i završava.

12. 12
Slika 13: Identifikacija podprocesa kod procesa naručivanja
Inicijalni cilj grupisanja aktivnosti u podprocese je bio da se model pojednostavi. Ovo
se može uraditi tako što bi se sakrio sadržaj podprocesa (slika 14). To se radi tako što se
makro aktivnost, sa svim koracima zameni standardnom aktivnosti. Da je ova aktivnost u
stvari podproces se može videti po malom kvadratiću, sa znakom plus.
Slika 14: Pojednostavljena verzija procesa posle sakrivanja sadržaja podprocesa
Sakrivanje aktivnosti u podprocesu ne vodi kao gubitku sadržaja. Podproces je i dalje
tu, ali je definisan na drugom nivou apstrakcije. Podprocesi mogu da se gnezde na više nivoa,
tako da se dobija hijerarhijski model procesa.

13. 13
Pogledajmo primer sa slike 15. U pitanju je model procesa isplate stambenih kredita.
Na prvom nivou postoje dva podprocesa. Jedan se koristi za proveru sposobnosti onog ko se
prijavljuje i drugi za potpisivanje kredita. Na drugom nivou se zakazivanje isplate kredita
unutar procesa potpisivanja izdvaja u poseban podproces.
Slika 15: Model procesa isplate stambenih kredita
Kako se ide naniže u hijerarhijskoj dekompoziciji procesa mogu se dodavati novi
detalji. Na primer, može se usvojiti pravilo da se na prvom nivou modeliraju samo osnovne
poslovne aktivnosti, na drugom se dodaju tačke donošenja odluka itd., sve dok se ne doĎe do
modeliranja izuzetaka i detalja koji su relevantni samo za automatizaciju procesa.
Podprocese bi trebalo koristiti kad god model postane suviše velik za praćenje. Teško
je precizno definisati kada model procesa postaje suviše velik, ali se mogu pratiti preporuke
da prikaz više od 30-ak objekata (aktivnosti, dogaĎaja, kapija) povećava verovatnoću da se
negde pogreši.
Još neki aspekti koji utiču na čitljivost modela su gustina veza kod modela procesa,
broj paralelnih grana, najduži put od početka do kraja, kao i kozmetički aspekti kao što su
raspored, stil označavana, boje koje se koriste, debljina linija itd.
Ponovna upotreba procesa
Podproces se podrazumevan ugraĎuje u model roditeljskog proces i kao takav se
može pozivati samo iz tog roditeljskog modela. Prilikom modeliranja se često javljaju situacije
da se isti model procesa koristi u više drugih modela. Na primer, u procesu odobravanja
kredita bi se mogao ponovo koristiti podproces potpisivanja kredita i za druge vrste kredita,
kao što je studentski kredit ili kredit za automobil.

14. 14
U okviru BPMN-a se sadržaj podprocesa može definisati i izvan roditeljskog procesa,
tako što se kreira tzv. globalni model procesa. U pitanju je model procesa koji nije ugraĎen ni
u jedan drugi model, i kao takav se može pozivati u okviru drugih modela procesa. Grafički se
to na modelu označava debljim granicama pravougaonika koji predstavlja taj podproces.
Slika 16: Model procesa dodele studentskih kredita koristi isti model potpisivanja kao
kod stambenih kredita
Generalno bi podprocese uvek trebalo kreirati kao globalne, čime se omogućava
njihova upotreba na više pozicija. Pored mogućnosti upotrebe na više mesta, još jedna
prednosti upotrebe globalnih podprocesa je u tome da se promena u originalnom modelu
automatski reflektuje na svim mestima gde je taj model ugraĎen.