3.

Osnove modeliranja poslovnih procesa

Ovo poglavlje predstavlja osnove modeliranja poslovnih procesa tako što ispituje
apstrakciju koncepta i predstavlja osnovna područja dejstva modeliranja poslovnih
procesa, odnosno modelirajućih funkcija, procesa, odataka, organizacije i ishoda.

3.1. Konceptualni model i terminologija

Modeliranje poslovnih procesa koje/kako je prikazano u poglavljima 1 i 2 je organizirano

pomoću konceptualnih modela. Slika 3.1. predstavlja model koncepta koji je osnova
menagementa poslovnih procesa. Dok su izrazi koji se pominju korišteni u prethodnom
poglavlju neformalno, koncepti koji se kriju iza ovih termina i njihovi odnosi će sada biti
detaljnije prodiskutirani, korištenjem konceptualnih modela. Ovi modeli se izražavaju
pomoću Jedinstvenog Modelirajućeg Jezika (Unified Modeling Language -UML), koji je
objekto-orjentisani modelirajući i dizajnirajuću jezik.

Poslovi procesi se sastoje od aktivnosti, čijim se koordiniranim izvršenjem realiziraju

neki poslovni ciljevi. Ove aktivnosti mogu biti sistemske aktivnosti(System Activity),
kotisničke interaktivne aktivnosti (User Interaction Activity) ili ručne/manuelne
aktivnosti(Manual Activity). Informacioni sustavi ne podržavaju manuelne aktivnosti.
Primjer manuelne aktivnosti je slanje pošiljke poslovnom partneru.

Korisničke interaktivne aktivnosi idu korak dalje: to su aktivnosti koje izvršavaju obučeni
radnici, koristeći informacione sustave. Kod ove vrste aktivnosti nije uključena fizička
snaga. Primjer korisničike interaktivne aktivnosti je unošenje podataka vezanih pri
ostvarivanju prava polise osiguranja u pozivnom centru,unošenje novog klijenta Banke
ili neke druge službe u bazu podataka koja sadrži sve klijente Banke, uz pomoć
aplikacije za unos klijenta. Da bi ljudi koristili informacione sustave za izvršavanje ovih
aktivnosti, potrebna je aplikacija sa odgovarajućik korisničkim sučeljem koja će
omogućiti efektivan rad. Ove aplikacije trebaju biti povezane za pozadinom aplikacionog
sustava koji pohranjuje unešene podatke i omogućava da isti budu dostupni za narednu
upotrebu. Pozadina aplikacionog sustava bi u ovom slučaju bila baza podataka, sa svim
potrebnim šemama, u kojim se čuvaju unešeni podaci.

Neke aktivnosti koje se provode tokom nekog poslovnog procesa su manuelne prirode
ali preko korisničkih interaktivnih aktivnosti donose promjene u menagementu poslovnih
procesa. Recimo, isporuka pošiljke može biti posmatrana i praćena informacionim
sustavom. Jasno, stvarnu isporuku pošiljke označava primatelj svojim potpisom.
Stvarna isporuka je bitna informacija u logistici poslovnih procesa koju treba da

1
predstavlja informativni sustav. Postoji nekoliko vrsta dogaĎaja koji se dešavaju tokom
logističkog procesa. Ovi dogaĎaji su često dostupni korisiku kao prateća informacija.
Dok su aktivnosti manuelne prirode, informacioni sustav – prateći sustav – prima
informacije o odreĎenom stanju procesa.

Kao primjer gore navedenog pasusa i slike 3.1 , možemo navesti zasjedanje Kreditnog
odbora i donošenje odluke vezano za odobrenje kredita.Kreditni službenik prima zahtjev
za kredit i interaktivnom akcijom kroz aplikaciju sustava unosi Zahtjev u Bazu podataka.
Potom se svi Zahtjevi daju na uvid Kreditnom Odboru Banke. Odbor donosi odluku o
odobrenju ili odbijanju zahtjeva za kredit (manuelna akcija), koja se proslijeĎuje nazad
kreditnim službenicima koji dalje odobravaju ili poništavaju kredit, ponovno
interaktivnom akcijom na aplikativnom sustavu. Unošenjem informacije o odobrenju ili
odbijanju Zahtjeva u bazu podataka, istovremeno se kroz sustav (Sustavska aktivnost)
proslijeĎuju informacije Uredu Šalterskog poslovanja koja, ukoliko je Kredit odobren,
vrši isplatu kredita.

Slika 3.1.

Sustavske aktivnosti(System Activity) ne uključuju korisnike ljudskog roda, one se

izvršavaju pomoću informacionog sustava. Primjer sustavske aktivnosti je dobivanje
informacije o dionicama na burzi pomoću brokerske aplikacije ili provjeravanje stanja
bankovnog računa. Podrazuimjeva se da su stvarni parametri koji potrebni za pozivanje,
dostupni. Ako korisnik obezbjeĎuje ove informacije, onda je to korisnička interaktivna
aktivnost. Obje vrste aktivnosti zahtjevaju pristup odgovarajućem softverskom sustavu.

2
OdreĎeni dijelovi poslovnog procesa mogu se objasniti(desiti,odvijati) tehnologijom
radnog toka(toka rada- Workflow). Management sustava toka rada može osigurati da
se aktivnosti poslovnog procesa izvršavaju prema odreĎenom redoslijedu i da
informacioni sustav bude pozvan da realizira poslovnu funkcionalnost. Ova veza izmeĎu
poslovnog procesa i toka rada je predstavljena povezanošću pojedinih klasa.
Napominjemo da tok rada nije pod klasa poslovnog procesa, iako tok rada realizira dio
poslovnog procesa.

U odnosu na vrste aktivnosti koje su spomenute, sustavske aktivnosti su povezane sa

tokom rada, jer sustavske aktivnosti mogu učestvovati u bilo kojoj vrsti toka rada,
sustavskog toka rada(System Workflow) ili korisničkog interaktivnog toka rada(Human
Interaction Workflow). Korisničke interaktivne aktivnosti i manuelne aktivnosti, mogu
učestvovati samo u korisničkim interaktivnim tokovima rada.

3.2. Abstraktni koncept

Da bi shvatili kompleksnosto managementa poslovnih procesa, predstavićemo nekoliko

abstrahtnik koncepta. Tradicionalni abstraktni koncept u kompjuterskoj nauci je
razdvajanje faza modeliranja, sto je poznato kao horizontalna abstrakcija, koja je
detaljnije pojašnjena u Odjeljku 3.2.1.

Čak i pri korištenju horizontalne abstrakcije, odvojene poddomene trebaju biti istražene.
Ovaj abstrakcioni mehanizam zove se verticalni i o njemu se diskutuje u Odjeljku 3.2.2.

Da bi se izborili sa kompleksnošću, takoĎer može biti primjenjena i agregacija. Na

višem nivou abstrakcije, više elemenata nižeg nivoa abstrakcije mogu biti grupirani i
predstavljati jedan element.

Na primjer, set funkcionalnih aktivnosti male granularnosti može doprinijeti odreĎenoj

poslovnoj funkciji na višem nivou granularnosti: više- granulirana poslovna funkcija
„management naručivanja“ može agregirati puno nisko-granuliranih aktivnosti, poput
primanja dolazeće narudžbe, provjeravanje zaliha i potvrĎivanje narudžbe. Ovaj tip
abstrakcije se zove agregaciona abstrakcija.

Agregaciona abstrakcija razlikuje se od hotizontalne po tome što su sve granulirane

aktivnosti nalaze na istom horizontalnom nivou.

3
3.2.1. Horizontalna abstrakcija

Model horizontalne abstrakcije prikazan je na slici 3.2.1.1. po principu na-gore, počevši

od instance.

Nivo instance reflektira konkretne entitete koji su uključeni u poslovni proces. Izvršene
akcije, konkretne vrijednosti podataka, izvori i osobe su predstavljeni na nivou instance.

Da bi se organizirala kompleksnost scenaria poslovnog procesa, set sličnih entiteta na

nivou instance je identificiran i klasificiran na nivo modela. U objektnom modeliranju,
set entiteta predstavljen je klasom, a u podatkovnom modeliranju predstavljen je
korištenjem ER modela (Entity Relationship tj model Entitet-veza). Set entiteta
redstavljen sa jednim tipom identiteta a sličnosti meĎu tipovima entiteta su
predstavljene vezama.

Slika 3.2. Nivoi abstrakcije

4
Modeli se prenose u metamodele koji su povezani sa notacijama (zabilješkama) koje su
obično grafičke prirode. Metamodel Petrijeve mreže definira Petrijevu mrežu koja se
sastoji od položaja i tranzicija koji čine direktni bipartitivni graf. Tradicionalna notacija
Petrijeve mreže povezuje grafičke simbole sa elementima metamodela. Položaji su
predstavljeni krugovima, tranzicije pravokutnicima,a struktura grafa direktnim rubovima.

U podatkovnom modeliranju, ER metamodel definira tipove entiteta, veza i povezanosti

meĎu njima. Tipična grafička obilježja ER metamodela su pravokutnici za tipove
entiteta, rombovi za vrste veza, povezani linijama.

Zato je važno napraviti razliku izmeĎu koncepata rezultta modeliranja i grafičke notacije
koja se koristi da bi se predstavili ovi koncepti. Cio set koncepata i veza izmeĎu
koncepata, zove se metamodel. Metamodel postaje koristan ako postoji notacija za taj
metamodel koja dozvoljava predstavljanje modela na prikladan način koji dozvoljava
komunikaciju izmeĎu članova u modeliranoj situaciji stvarnog svijeta.

Različiti nivoi abstrakcije i njihove veze su prikazane na slici 3.2.. Notacija vezana za
metamodel dozvoljava predstavljanje koncepata tog odreĎenog metamodela. Svaki
model objašnjen je metamodelom i izražen je u notaciji koja se veže za taj metamodel.

3.2.2. Vertikalna abstrakcija

Vertikalna abstrakcija u modeliranju poslovnih procesa je prikazana na Slici 3.3. gdje se

primjećuju različite medelirajuće poddomene. Kao što je prikazano, proces modeliranja
je u centru procesa modeliranja, ali on takoĎer integrira dijelove modelirajućeg procesa,
koji su smješteni u njihove poddomene.

Slika 3.3..Modeliranje poslovnog prcesa uključuje višestruke modelirajuće domene, integrirane

modeliranjem procesa

5
Modeliranje funkcija, podataka, organizacije i modeliranje podrućja operativnih
informacionih tehnologija su nužni da bi se obazbijedila kompletna slika poslovnog
procesa. Dok su ovi procesi najvažniji, dodatne poddomene mogu biti definirane ukoliko
je potrebno.

Funkcionalno modeliranje istražuje jedinice rada koje bivaju izvršene u kontekstu

poslovnog procesa. Specifikacija rada može biti izvršena na različitim agregacijskim
fazama.

Specifikacija ovih funkcija može biti neformalna, korištenjem Engleskog teksta ili
formalna, korištenjem sintaksičkih ili semantičkih specifikacija funkcije. Dok je
neformalna deskripcija najčešće primjenjena kod prostih poslovnih procesa, kod
softverskih slojeva, kada dolazi do implementacije odreĎene funkcije korištenjem
informacionih sistema, je neophodna preciznija deskripcija.

Istraživanje i odgovarajuća prezentacija podataka u poslovnom procesu je bitna, jer

odluka koja se donosi tokom poslovnog procesa ovisi o vrijenostima odreĎenih
podataka. TakoĎed podatkovna ovisnost izmeĎu aktivnosti treba biti uzeta u obzir
prilikom dizajniranja procesa, da bi se izbjegla situacija u kojoj funkcija zahtjeva
odreĎene podatke, koji nisu dostupni u tom momentu.

Odgovarajuća przentacija organizacijske strukture kompanije je bitan zahtjev. Aktivnosti

u poslovnom procesu mogu onda biti povezane sa odreĎenim ulogama ili odjelima u
organizaciji. Mnoge aktivnosti u poslovnim procesima su izvršene od strane ili uz
asistenciju informativnih sistema. Područje operativnih informativnih tehnologija,
informativni sistemi, njihove veze, i njihov programski interfejs, trebaju koristiti
funkcionalnosti obezbijeĎene od strane informativnih sistema.

Proces modeliranja predstavlja povezanost izmeĎu poddomena. Model procesa

povezuje funkcije poslovnog procesa sa izvršnim ograničenjima. Aspekti podataka su
pokriveni, jer odreĎene instance procesa mogu ovisiti od strukture i vrijednosti podataka
koje su uključene u odreĎeni poslovni proces. Na primjer, u procesu dobijanja kredita,
odobravanje kredita ovisi o traženom iznosu kredita.

6
3.3. Od poslovne funkcije do poslovnog procesa

Kao što je diskutovano u Odjeljku 2.3., nizovi vrijednosti obazbjeĎuju organizaciju

finkcija visokog nivoa.Da bi se obezbjedio pogled sa više detalja, ove poslovne funkcije
najvišeg nivoa se razbijaju u funkcije manje granularnosti i na kraju na aktivnosti
operetivnog poslovnog procesa. Funkcionalna dekompozicija je tehnika izbora.

Parcijalna funkcijska dekompozicija niza vrijednosti prikazana je na slici 3.4., gdje

sistem vrijednosti predstavlja najviši nivo agregacije. Svaki sistem vrijednosti sastoji se
od broja nizova vrijednosti, karakteriziranih diagramima klasa na lijevoj strani Slike 3.4.

Redanje nizova vrijednosti u sistemu vrijednosti nije predstavljena u ovom strukturalnom

dijagramu, jer nema formalno značenje. IzmeĎu ovih tvrtki postoje složeni odnosi, pa je
očito da se ne pojavljuju sve aktivnosti u vrijednosnom lancu potrošača prije svih
aktivnosti koje se dešavaju u tvrtci E.

3.4. Funkcionalna dekompozicija od vrijednosnog lanca do poslovne funkcije

7
Funkcionalna dekompozicija vrijednosnog lanca tvrtke E je precizirana jednim
odreĎenim obrascem o funkcijama marketinga i prodaje visokorangiranih uloga biznisa.
Pored mnogih drugih funkcija, marketing i prodaja (Marketing and Sales) uključuju i
poslovnu funkciju, Order Management, koji sadrži funkcije koje se odnose na
menagement pristiglih zahtjeva. Menagement o narudžbama se dalje dijeli na dobijanje
ishoda biznisa(GetOrder), te provjeravanja i ovjeravanje zahtjeva (CheckOrder). Kao
što je prikazano na figuri 3.4., različiti su simboli (oznake) za funkcije biznisa i funkcije
najboljih granula, pa su tako ove prve predstavljene pravougaonicima, dok su druge
predstavljene pravougaonicima sa zaobljenim uglovima. Tradicionalno, funkcionalne
dekompozicije (razlaganja) korištene su da se opišu tvrtke bazirana na funkcijama koje
obavljaju. Koncentriranje na funkcije, poduzetništva i ignoriranje njihovih uzajamnih
djelovanja pravilno prezentiraju kako tvrtke rade. Prema tome, funkcionalna
dekompozicija se koristi kao prvi korak u predstavljanju tvrtki baziranih na poslovnim
procesima.

Dakle, funkcionalna dekompozicija daje jednu sliku hijerarhijske strukture neke tvrtke,
posmatrajući tu tvrtku kao kariku u vrijednosnom lancu, odnosno lancu vrijednosti
cijena, od potrošača(Supplier Value Chains) do dobavljača(Channel Value Chains).
Bitnu funkciju u tom lancu predstavljaju odjeli Marketinga i Prodaje(Marketing i Sales),
koji i održavaju taj lanac i sponu izmeĎu potrošača, kao onog koji zahtjeva i inicira
nabavu, i dobavljača, koji putem tvrtke odgovara zahtjevima potrošača. Ove funkcije
unutar odjela Prodaje i Marketinga obavlja pododjel Management-a naručivanja (Order
Management), koji naručuje robu i provjerava narudžbe odreĎenim metodama, koje bi
bile u ovom slučaju elementi najnižeg stepena hijerarhijske strukture, ali kako sami ne
pripadaju hijerarhijskoj strukturi, nego su alat kojim se koriste nivoi hijerarhije u obavljnu
svojih funkcija, onda su u funkcionalnoj dekompoziciji označene na drugačiji
način(pravougaonik sa zaobljenim kutovima) od samih elemenata hijerarhijske
strukture. Ti alati zapravo predstavljaju dijelove poslovnog procesa, dok su raniji
elementi strukture imali uloge poslovne funkcije.

Operacioni biznis procesi prenose aktivnosti uzajamno ispunjavanjem prepreka izmeĎu

njih. Uglavnom, odnosi funkcija i poslovnih procesa mogu biti namijenjeni različitim
oblastima biznisa. U koliko se govori o visoko rangiranim funkcijama biznisa, koriste se
tekstualna objašnjenja, jer konkretna izvršavanja izmeĎu sastavnih dijelova (učesnika)
nisu bitna u običnim ulogama biznisa.

Podrazumijevaju se ipak prihodi, obezbjeĎenje zaliha i operacije funkcija biznisa. Na

ovom, jako jednostavnom nivou funkcionalnosti, nije moguće zahtijevanje realiziranja
ovakvih funkcija biznisa, obje funkcije se izvode istovremeno i samo na nižem nivou
granularnosti konkretno zahtijavanje (naručivanje) ima smisla. Naprimjer, kada
operacije zahtijevaju odreĎeni, dodatni materijal, tada postoje konkretni zahtjevi koji
diktiraju i potražuju konkretne narudžbe. Za vrijeme operacija, važna narudžba je
8
kreirana i poslana obezbjeĎenju zaliha. Pri samom dolasku narudžbe, materijal je
spreman za izvršavanje date operacije. U slučaju da materijal nije spreman u kompaniji
za proizvodnju, spoljašnja narudžba je spremna i poslata proizvoĎaču izvornog
materijala. Dakle, procesi biznisa koji se odnose na fina vlakna funkcija, su najčešće
predstavljena listovima na stablu dekompozicije. Figura 2.13 predstavlja visoko
rangirane funkcije mogu biti predstavljene grafički.

3.5. Poslovne funkcije male granularnosti su organizirane kao poslovni proces

Na primjeru prikazanom na slici 3.5, aktivnosti analiza narudžbe(AnalyzeOrder),

jednostavna provjera(SimpleCheck), i napredna/dodatna provjera (AdvCheck) odnose
se jedni prema drugima po ograničenjima izvršenja. Obrazac poslovnog procesa
počinje analiziranjem zahtjeva i onda rukovoĎenjem svakog jednostavnom ili
naprednom kontrolom zavisno od odluke donesene tokom procesa izvršenja. Ovaj
proces ima posvećeni početni dogaĎaj i krajnji dogaĎaj. Poslovni proces počinje sa
početnim dogaĎajem , kada je potpun, i završava krajnjim dogaĎajem. DogaĎaji imaju
presudnu ulogu kada su izraženi meĎusobni odnosi izmeĎu poslovnih procesa.

9
OdreĎena poslovna funkcija više granularnosti (CheckOrder) sastoji se od finih-
granularnih radnji, koje su povezane izvršnim granicama. MeĎutim, kontrola narudžbi
poslovne funkcije ( i poslovnog procesa koji je realizira) je povezana sa drugim
funkcijama i njihovim, dotičnim poslovnim procesima.

Primjer prikazivanja ove situacie je prikazan na slici 3.6, gdje je dio vrijednosnog lanca
prikazao, djelimično, poslovne funkcije Recieve Requests (zahtjev za prijem), Request
Analysis (zahtjev za ispitivanje) i Quota Management (udio managementa). Budući da
su jasni zahtjevi izmeĎu ovih poslovnih funkcija, prikazan je odnos izvršeja zahtjeva.

Slika 3.6. Povezani poslovni proces, prikaz visokog nivoa

Zahtjev za prijem(Recieve raquest) poslovne funkcije je realiziran poslovnim procesom

prikazenom na slici 3.7, a tako i poslovni procesi realiziraju druge poslovne funkcije.
Početni i krajnji dogaĎaji poslovnih procesa su povezani i kao takvi prikazani na slici, te
je prema tome realizirano izvršenje ograničenja zahtjeva poslovne funkcije.

Nakon završetka dijela poslovnog procea koji se odnosi na prijem zahtjeva, uslovljen je
krajnji dogaĎaj. Ovaj krajnji dogaĎaj je signal za početak narednog poslovnog procesa,
koji se odnosi na zahtjev za analizom(Request Analysis). Konačno, norma je spremna i
poslovni proces je upotpunjen. Ova diskusija pokazuje da poslovni procesi na nižem
nivou mogu biti prisutni, isto kao i oni na višem nivou. Veze izmeĎu poslovnih procesa
su predstavljene spojnim karikama, bolje objašnjene u dijelu 4.7.

Cjelokupna organizacija ovih nivoa je prikazana na slici 3.8. Na lijevoj strani ove slike je
UML strukturni dijagram koji prkazuje konceptualni model u cjelini. Da ponovimo, svaka
tvrtka je predstavljena vrijednosnim nizom, koji se sastoji od grubih vlakana (coarse-
grained) poslovnih funkcija koje su razložene u manje granule poslovnih funkcija,
realizirajući funkcionalno razlaganje. Aktivnosti su funkcije najljepših granularnosti; one
su materijal za izgradnju operacija poslovnih procesa.

10
 Slika 3.7. Povezani poslovni proces, detaljan prikaz

Kada proces počne, poslovne funkcije koje isti sadrži moraju biti izvršene. Stoga, svaka
aktivnost u poslovnom procesu zahtijeva izvršenje. Izvršenje aktivnosti može biti
bazirano na funkcionalnosti koja slijedi iz informativnih sustava, kao što su registriranje
novog korisnika ili rezerviranje leta. U svakom slučaju, proces izvršenja može biti
obezbijeĎen zahvaljujući znanju i vještini radnika bez korištenja informativnih sustava.

Definicija 3.1. Funkconalna dekompozicija (razlaganje) grubih čestica poslovnih

funkcija na fine čestice istih aktivnosti definira funkcionalnu perspektivu poslovnog
procesa.

11
3.4. Model aktivnosti i instanca aktivnosti

Poslovne funkcije obezbjeĎuju grubogranuliranu predstavu visokog nivoa u poslovima

kojim upravljaju tvrtke. Aktivnosti se mogu naći na stranama (listovima) funkcionalne
dekompozicije. Ova oblast istražuje kako se aktivnosti (radnje) mogu opisati. Uz to,
stvarni rad koji se izvodi tokom poslovnih procesa mora biti opisan, tj. funkcija instance
mora biti osobena. Uočava se da modeli aktivnosti predstavljaju M1 sloj Meta Object
Facility, dok instanca aktivnosti odgovara sloju M0. Slika 3.9. pokazuje odnose izmeĎu
poslovnih funkcija, modela i inastanci.

Slika 3.8. Nivoi menagamenta poslovnog procesa. Od vrijednosti sistema do implementacije aktivnosti

12
Model aktivnosti opisuje set sličnih funkcija instanci, analogno procesu opisivanja
modeliranja više instanci koje imaju istu strukturu. Dok je proces modeliranja izražen
tipičnom oznakom na dijagramu ( to će biti detaljno objašnjeno u narednom poglavlju),
model aktivnosti mogu biti označene različitim formama, na primjer, direktnim tekstom ili
nekim formalnim obilježjima programskih komponenti koje ih koriste.

Slika 3.9. Model aktivnosti i aktivnosti instanci

Instanca aktivnosti predstavlja stvarni rad koji se izvodi tokom poslovnog procesa,
stvarnu jedinicu rada. Da bi ova diskusija bila jasnija, instance procesa predstavlja
procesuiranje osiguranja u potraživanju Clare Smith na štetu koja iznosi $ 2000
američkih dolara, utvĎeno 11. Novembra 2006. Neka Unos Potraživanja(EnterClaim) (
Clara Smith, 2000, 11-11-2006) predstavlja aktivnosti instanci odgovornih za unošenje
potraživanja u program sustava kompanije za osiguranja. Kada kompanija primi tvrdnju,
proces instanci počinje. Unutar ovog procesa, aktivnost instanci EnterClaim (Clara
Smith, 2000, 11-11-2006.) počinje. Kada je potraživanje zabilježeno, aktivnost instanci
se završava. Drugi primjer je unošenje zatjeva za kredit u sustav banke. Instancama
aktivnosti se zahtjev za kredit unosi u sustav banke i tim unošenjem počinje proces
instanci. Dodatno, unutar toga, ponovo počinje instanca aktivnosti unutar koje se donosi
odluka o odobravanju ili odbijanju zahtjeva. Kada je ta odluka donešena, instanca

13
aktivnosti se završava, ali instanca procesa se nastavlja sve do samog zatvaranja
kredita.

Svaka instanca aktivnosti tokom svog trajanja je u različitim stanjima. Ova stanja i
dotični stanja prelaska mogu biti predstavljena dijagramom stanja prelaza. Ovakav
jednostavni dijagram je prikazan na slici 3.10. Stanje koje poprima jedna instanca
aktivnosti tokom svog životnog vijeka je opisano kako slijedi: kada je kreiran, unosi se
init (inicijalno-početno stanje). Po odobrenom(enabled) stanju prelaza, instanca
aktivnosti može stupiti u spremno stanje(Ready state).

Ako odreĎena aktivnost instanci nije potrebna, onda se ova aktivnost može biti
izostavljena(skipped), što se predstavlja skip (izostavljenim) prelazom i to od još uvijek
nezapočetog(not started) do preskočenog(skipped) stanja. Od spremnog stanja(ready
state), aktivnost instanci može koristiti početnu tranziciju i stupiti u stanje
izvršavanja(running state). Kada instanca aktivnosti završi svoj rad, konačno
stanje(terminate state) prelaza se transformiše u završno stanje(terminated state). Kada
je instanca aktivnosti u terminated(završnom) ili skipped (preskočenom) obliku, onda je
zatvorena.

Slika 3.10. Dijagram tranzicije stanja za aktivnosti instanci

14
Dok dijagram prelaza stanja na slici 3.10 predstavlja stanja većine instanci aktivnosti u
poslovnom procesu, u stvarnom svijetu, ove aktivnosti više iznose kompleksnije,
složenije karakteristike. Svi prelazi stanja koji su mogući na jednostavnom dijagramu su
takoĎer prisutni u dijagramu kompleksnih prelaza stanja. Aktivnost instanci je
pokrenuta, i stupa u spremni oblik prije stupanja u izvršavanje. Konačno, aktivnost
instanci je završena. U svakom slučaju, niža stanja prelaza nisu prikazana. Jednostavni
dijagram ne obezbjeĎuje različita stanja za uspješno(successful) ili
neuspješno(unsuccessful) okončanje rada I to je osnovna razlika izmeĎu jednostavnih I
složenih dijagrama stanja prelaza.

Kada aktivnost instanci počne, ona stupa u spremno stanje. Ukoliko tokom izvršenja
procesa odreĎene aktivnosti nisu dostupne za izvršenje, iste mogu biti
onesposobljene(disabled). Ovakve aktivnosti, odnosno one koje su
inicijalizirane(initialized), onesposobljene(disabled) ili odobrene(enabled) nalaze se u
još uvijek nezapočetom stanju(not started state). Onda kada je aktivnost instanci
spremna, može već započeti stupanjem u izvršni oblik(running state). Izvršne aktivnosti
mogu biti trenutno obustavljene(suspended), te kasnije obnovljene. Aktivnost instanci
pak može završiti uspješno(successful) ili neuspješno(failure). Završene aktivnosti
prema tome, mogu biti nedovršene(undone), ali se mogu koristiti dopune ili tehnike
tranzicijskih obnavljanja.

Baziran na opisu karakteristika aktivnosti instanci, postavlja se pitanje kako dobiti

stvarne karakteristike odreĎene aktivnosti instanci, na primjer, kako uraditi grafički crtež
općih stanja i stanja prelaza kroz koje su aktivnosti instanci prošle. U ovoj oblasti,
dogaĎaji i naredbe dogaĎaja su uvedeni da pravilno opišu suštinu aktivnosti instanci.

Osnovna ideja korištenja dogaĎaja je za predstavljanje aktivnosti na prilično

jednostavan način: svako stanje prelza u aktivnostima instanci je predstavljeno
dogaĎajem (naradbom). Ovi dogaĎaji imaju privremene naredbe. Svaka instanca
aktivnosti može biti predstavljena ureĎenim setom dogaĎaja, baziranim na dijagramu
stanja prelaza aktivnosti instanci. Za predstavljanje aktivnosti instanci uz pomoć
dogaĎaja, dovoljan je jednostavni dijagram tranzicije na slici 3.10.

Definicija 3.2 Neka je AM set modela aktivnosti i AI set aktivnosti instanci. Instanca
aktivnosti je jednaka i = (Ei, < i ) i pripada AI bazirana na aktivnostima modela gdje I
pripada AM i definirana je kao potpuno ureĎeni set zahtjeva Ei tako da svaka:

Aktivnost instanci i izvršena i u tom slučaju obavještenje o izvršenju je u

početnom, odobrenom, početnom i završnom obliku ili
Aktivnost instanci i preskočena i u tom slučaju obavještenje o izvršenju je dato u
početnom, odobrenom i skip (preskočenom) obliku
Funkcija oblika: AI slijedi u AM pokazuje svaku aktivnost instanci koja se odnosi na
model aktivnosti.

15
Bitno je zapamtiti da se aktivnost instanci može preskočiti ako je u inicijalnom ili
spremnom stanju. Kao rezultat, odobreni dogaĎaj može, ali ne mora biti dio seta
dogaĎaja preskočene aktivnosti instance.

Uobičajen raspored dogaĎaja naznačen ovom definicijom može biti grafički predstavljen
dijagramima dogaĎanja. U ovakvim dijagramima, vrijeme se kreće s lijeva na desno, a
dogaĎaji su prikazani tačkama. Uzročne veze izmeĎu dogaĎaja su prikazane
usmjerenim strelicama.

Zbog prirode dijagrama dogaĎanja, oni formiraju usmjerene neperiodične grafove, gdje
su tačke grananja dogaĎaji, a rubovi se odražavaju uzročnim naredbama izmeĎu
dogaĎaja. Jedan takav dijagram je prikazan na slici 3.12.

Slika 3.12. Dijagram dogaĎanja (a) izvršene aktivnosti instance i (b) izostale aktivnosti instance

16
U dijagramu prikazanom u prvom dijelu (a), prikazana je instanca aktivnost koja je
pravilno izvršena, dok je u drugom dijelu slike (b) prikazana preskočena instanca
aktivnosti. Da bi se predstavila veza izmeĎu dijagrama stanja prelaza i dijagrama
dogaĎanja, svako stanje prelaza u dijagramu stanja prelaza je povezano sa dogaĎajem
u odgovarajućem dijagramu dogaĎaja.

Aktivnost instanci počinje sa prelazom stanja u inicijalno stanje. Ovo stanje prelaza je
predstavljeno inicijalnim dogaĎajem u dijagramu dogaĎaja. Omogućeno(enable) stanje
prelaza, dovodi instancu aktivnosti u spremno stanje; ovo prelazno stanje je
predstavljeno omogućenim(enable) dogaĎajem. Instanca aktivnosti u spremnom stanju
može biti započeta, predstavljena sa početak(begin) stanjem prelaza. Konačno, završno
stanje prelaza završava instancu aktivnosti.

DogaĎaji su tačke u vremenu, ali oni ne traju u vremenu. Vremenski interval u kojem je
instanca aktivnosti u jednom stanju, ograničen je sa dva dogaĎaja, dogaĎajem koji
predstavlja stanje prelaza kojim se stupa u stanje i dogaĎajem koji predstavlja stanje
prelaza kojim se napušta stanje. Na primjer, vremenski interval gdje je aktivnost instanci
u izvršnom stanju je ograničen početnim i završnim dogaĎajem.

Izdavanje naredbi za dogaĎaje složenih aktivnosti u kontekstu poslovnih procesa je jako

bitan instrument za izvršenje značenjskih procesa u biznisu, a detaljno će biti
objašnjeno u četvrtom poglavlju.

Kao primjer možemo navesti punjenje ljekovitog bazena smjesom vode i ljekovitih tvari.
Vanjski dogaĎaj inicira pokretanje dijagrama stanja i pri tome se provjerava da li je
bazen spreman(ready) za punjenje, odnosno da li je prazan ili je bazen već napunjen,
pri čemu bi se automatski prešlo u skipped stanje, čime bi se aktivnost završila. Ukoliko
je bazen prazan, prelazi se u spremno(ready) stanje u kome bi se mogla desiti
otežavajuća okolnost da recimo nedostaje odreĎene tvari, npr. hlora koji se dodaje u
smjesu i u tom slučaju, prelazi se u onemogućeno(disabled) stanje. Kada se spremnik
dopuni odgovarajućom supstancom, prelaz ponova vraća stanje u spremno(ready).
Kada su stvoreni svi preduslovi, prelazi se u stanje izvršenja(running). Otžavajuća
okolnost koja bi se mogla desiti u stanju izvršenja je da tijekom punjenja nestane jedne
od supstanci koje čine smjesu, pri čemu bi stanje prešlo u suspendovano(suspended),a
nakon dopunjavanja spremnika, ponovo bi se aktiviralo stanje izvršenja. Nakon toga
postoje tri moguća stanja: bazen napunjen(succeeded), desila se neka pogreška tipa
kvara neke od pumpi što je uzrokovalo pad cijelog procesa punjenja(failed) ili je
aktivnost prekinuta(cancelled) ljudskim faktorom ili nekim uslovom, recimo da se bazen
puni samo do pola dubine.

Ako istim primjerom pokušamo prikazati dijagram dogaĎaja, aktivnosti, odnosno

dogaĎaji se dešavaju pounaprijed odreĎenom slijedu, odnosno slijed dogaĎaja bi bio:

17
pravljenje smjese → provjeravanje svih količina smjese→ provjeravanje stanja bazena i
ovisno od ishoda ovog dogaĎaja naredni dogaĎaj bi →odloženo stanje ili ako je bazen
prazan →punjenje bazena do odreĎenog uslova.

3.5. Modeli procesa i instance procesa

Poslovni procesi se sastoje od više povezanih aktivnosti, radnji koje koordiniraju pri
izvršenju i doprinose realizaciji funkcije biznisa u tehničkom i organizacionom okruženju.
Poslovni procesi su predstavljeni modelima istih. Budući da je ovaj dio posvećen
izvršavanju naredbi različitih aktivnosti, bez olbzira na tehničko i organizaciono
okruženje poslovnih procesa, koristi se model funkcije procesa.

Slika 3.13. Faze MOF-a sa aspekta procesa

Slika 3.13 pokazuje položaj Meta Object Facility (posljednji objekt) za proces podoblasti.
U M0 sloju su instance procesa koje reflektuju stvarne pojave poslovnih procesa.
Svaka instanca procesa je zapravo instanca modela procesa u sloju M1. Modeli
procesa su opisani metamodelima(završnim modelima) procesa, gradeći krajnji M2
odjeljak.

18
U cilju da se izraze modeli proces, neophodno je da postoji sistem bilježenja koji daje
pisane informacije o sveobuhvatnim elementima krajnjih modela. Na primjer, ukoliko
metamodel procesa ima koncepciju nazvanu radni model, onda mora postojati odreĎeni
pisani dokaz kako bi se mogle izraziti stvarni modeli aktivnosti.

Dakle, na slici 3.13, proces bilježenja je povezan sa procesom završnog modela i sa

nivoima istog; svaki ovakav proces je izražen sistemima znakova koji su povezani sa
procesom završnih obrazaca koji opisuju model procesa.

3.5.1. Model procesa

U ovom dijelu, uveden je jednostavni metamodel procesa. Bolje nego insistirati na

kompletnim konstrukcijama ovakvih oblika, akcenat se stavlja na dio koji pruža dobro
opisan metamodel procesa koji se može koristiti za ilustriranje temljnih komponenti bilo
kojeg ovakvog procesa. Poglavlje 4 će biti posvećeno kompleksnijim modelima procesa.

Svako modeliranje počinje identificiranjem osnovnih koncepata koji trebaju biti

predstavljeni. U modeliranju većih modela, koncepti koji su prikazani su zapravo modeli.
Sljedeći modeli su utvrĎeni kao koncepti većih modela.

Model procesa: Model procesa predstavlja plavi otisak za više slučajeva iste ili
slične strukture. Procesi imaju hijerarhiju na dva nivoa, tako da se svaki sastoji
od više modela aktivnosti. Ubacivanje jednog procesa u drugi nije predstavljeno,
jer bi tada došlo do kompleksnijih oblika, a to nije potrebno. Svaki ovakav model
procesa se sastoji od čvorova i usmjerenih krajeva.
Kraj, rub: Usmjereni krajevi, završeci se koriste da prikažu odnose izmeĎu
čvorova u modelu procesa.
Čvorovi: Čvor u modelu procesa može predstavljati model aktivnosti, dogaĎaj ili
model ulaza / izlaza

- Modeli aktivnosti: opisuju kompletni rad utrošen u poslovnom procesu. Svaka

aktivnost se najviše jednom može pojaviti u modelu procesa, a nijedna u višestrukim
modelima. Ova odredba se može ublažiti kvalificiranjem modela prema procesu
identificiranja; da bi se zadržao veći model jednostavnim, produžetak nije
obuhvaćen. Čvorovi u ovakvim aktivnostima nemaju ulogu spajanja ili razdvajanja,
nego svaki model ima tačno odreĎeni ulaz i tačno odreĎeni izlazni rub.

- Modeli dogaĎanja: hvataju pojavu stanja relevantnih u poslovnim procesima.

Instance procesa počinju i završavaju dogaĎajima, tako da model samih procesa
završava modelima dogaĎaja.

- Modeli ulaza / izlaza: koriste se kako bi se izrazile konstrukcije kontrole toka,

uključujući redoslijed(sekvencu), kao i razdvajanje i udruživanje čvorova.
19
Svaki model procesa sadrži elemente na nivou modela, na primjer, modela aktivnosti.
Instanca procesa se sastoji od instanci aktivnosti. Nivo modela i nivo instanci nisu
odgovorni samo za aktivnosti nego i za dogaĎaje. Budući da su dogaĎaji po definiciji
zasebni entiteti, instance dogaĎaja se takoĎer zovu tako – events(dogaĎaji).

Kontrolni slijed u modelu procesa je predstavljen modelima ulaza/izlaza. Kao što je bio
slučaj sa aktivnostima i dogaĎajima, ovi modeli su predstavljeni u modelima procesa sa
sopstvenima modelima. Ovo tačno predstavljanje dozvoljava nam da ove (ulaz/izlaz)
instance smatramo instancama procesa.

Različiti slučajevi datih ulaza mogu imati različite osobine. Na primjer, modela izlaza
može odabrati granu 1, dok u sljedećem ponavljanju može koristiti granu broj 2. Ova
situacija se može predstaviti bolje ako postoji složeni model izlaza za dati model u
kontekstu datog procesa. U datom primjeru, prvi ulaz instanci bio odabrao granu 1, a
drugi granu 2.

Slika 3.14. Model za procesne modele

Sljedeći korak u modeliranju podrazumijeva identifikaciju i formiranje odnosa izmeĎu

ovih koncepata. Slika 3.14 pruža prikaz koncepata i njihovih odnosa strukturalnim

20
dijagramom, definirajući proces metamodela.

Svaki model procesa se sastoji od čvorova(Nodes) i rubova/vrhova(Edges). Čvorovi

predstavljaju modele aktivnosti, modele dogaĎaja i modele ulaza/izlaza, dok rubovi
kontroliraju redoslijed izmeĎu čvorova. Svaki rub je povezan sa tačno dva čvora i takvim
odnosom ih dovodi u odreĎeni red.

Svaki čvor je povezan sa najmanje jednim rubom. Različite vrste čvorova su

predstavljene generaliziranjem odnosa. Modeli aktivnosti prikazuju jedinice rada koji se
izvršava, modeli dogaĎaja pokazuju pojave stanja relevantnih za poslovni proces i
modeli ulaza/izlaza predstavljaju ograničenja pri izvršavanju aktivnosti, kao što su
spajanje i razdvajanje čvorova.

Dok je udruživanje izmeĎu čvorova i rubova definirano na nivou čvorišta, kardinalnost

udruživanja meĎu posebnim tipova čvorova (modela aktivnosti, dogaĎaja i ulaznih,
odnosno izlaznih modela) se razlikuje. Svaka model aktivnosti ima tačno odreĎeni
ulazni i izlazni rub(vrh)(edge).

Svaki proces počinje tačno odreĎenim dogaĎajem, početnim, i završava tačno

odreĎenim, završnim dogaĎajem. Prema tome, izvjesni dogaĎaji mogu da nemaju
početni ili završni dogaĎaj. Modeli ulaza/izlaza imaju zadatak da kontroliraju redoslijed.
Dakle, svaki ovaj model može imati višestruke izlazne rubove ( razdvojeni izlazni
čvorovi) ili višestruke ulazne rubove ( ujedinjeni ulazni čvorovi).

Slika 3.15.Notacija procesa koja se koristi za predstavljanje koncepta meta modela procesa

21
Slika 3.15 prikazuje model procesa baziran na uvedenim modelima složenijih procesa.
Bilješke korištene da se prikaže ovaj proces je uzet iz Business Process Modeling
Notation (Bilješki o modeliranju poslovnih procesa):

- Čvorišta modela dogaĎaja su predstavljena krugovima; završni dogaĎaj je

predstavljen boldiranim krugom.

- Modeli aktivnosti su predstavljeni pravougaonicima za zaobljenim vrhovima.

- Modeli ulaza/izlaza su u obliku romba

- Vrhovi(rubovi) su predstavljeni usmjerenim vrhovima izmeĎu čvorišta

Da bi se lakše razumjela diskusija o ovom primjeru, čvorovi su obilježeni oznakama.

Model procesa je zapravo provjeravanje zahtjeva. Proces počinje početnim dogaĎajem
u čvorišu N1, predstavljenim krugom. Ovaj model dogaĎaja predstavlja oblike bitne za
poslovni proces.

Na primjer, naredba je primljena, a ona sada treba biti provjerena. Kada se to desi,
naredba treba da se analizira i to je predstavljeno u modelu AnalyzeOrder (analiziranje
naredbe) i vrhu koji povezuje čvorište N1 sa ovim modelom. Nakon što je naredba
analizirana, izlazni čvor odlučuje da li je zahtjevana jednostavna ili složena provjera.
Kada je odabrana provjerena aktivnost upotpunjena, izlazni model N6 je aktiviran i
proces završava krajnjim modelom dogaĎaja N7.

Prije instanci procesa, nivo je adresiran, a uveden je i formalni dio procesa i prikazan je
na slici 3.14.

Definicija 3.3 Neka je C set kontrola izgraĎenih po odreĎenom redoslijedu. P= (N, E,

tip) je model procesa ukoliko se sastoji od seta N čvorova, i seta E rubova.

(a) Sekvenca toka sa sekventnim izlazom

22
 (b) Sekvenca toka, pojednostavljena notacija

Slika 3.16. Alternativna prezentacija sekventnog izlaza

Slika 3.16 u prvom dijelu (a) prikazuje model procesa sa tačno odreĎenim prikazom
sekvence ulaza/izlaza. Više konstrukcija kontroliranja redoslijeda uključuje serijsko
izvršenje, dakle sekvenca pripada C. Model procesa je definiran po P=(N, E, tip), tako
da

Na = {A, B} – set modela aktivnosti

Ne = {N1, N2} – seto modela dogaĎaja

Ng = {G} – set modela ulaza/izlaza

E = { (N1, A), (A, G), (G, B), (B, N2) } – set usmjerenih rubova

tip ( G ) = sekvenca pripada C

Kada god postoji direktna kontrola redoslijeda vrhova koji povezuju dva modela
aktivnosti u modelu procesa, izlazni čvor G sa type (g) = sekvenca predstavlja sekvencu
toka koji može biti izostavljen, kao što je prikazano u drugom dijelu ( b ) iste slike. Ova
odredba pojednostavljuje model procesa predstavljajući ga bez uvodnih nejasnoća.

3.5.2 Instance procesa

Model procesa definira nedostatke na instancama procesa koji pripadaju modelu

procesa. Prema tome, to je glavni dio koji se mora definisati ne samo zbog modela
procesa, već i zbog instanci precesa. Modeliranje instanci procesa nije lagan zadatak
zbog njihove neodreĎene prirode. Kada ovaj proces počne, on traje jedno dreĎeno
vrijeme prije nego se obustavi, slično kao kod instanci aktivnosti.

Proces se sastoji od broja instanci aktivnosti kao i od instanci dogaĎaja i ulaznih

instanci. Odnosi izmeĎu instanci aktivnosti u instancama procesa je definisan kroz

23
odnose modela aktivnosti u modelu procesa.

Na primjer, ako model procesa definira izvršavanje naredbi ograničenja izmeĎu modela
aktivnosti A i B, onda za svaki odreĎenu instancu procesa, aktivnost koja pripada
modelu A mora završiti prije nego počne instanca aktivnosti za B.

Nastavak za metamodela procesa pomenutih iznad je predstavljen na slici 3.17. Postoje

dodatne kategorije za instance procesa i čvorova koji zapravo objedinjuju instance
aktivnosti, dogaĎaje i ulazne instance. Postoje veze 1:N izmeĎu odgovarajućih
koncepata na nivou modela i instanci, kao što je prikazano metamodelom.

Svaka instanca procesa je povezana sa tačno jednim modelom procesa i svaki taj
model procesa je povezan sa proizvoljnim brojem instanci procesa. Svaki instance
procesa je sastavljen od proizvoljnog broja aktivnosti instanci. Svaka instanca aktivnosti
je povezana sa tačno jednim modelom aktivnosti. Isto vrijedi i za dogaĎaje i ulaze.

Bitno je napomenuti da je svaki model aktivnosti povezan sa proizvoljnim brojem

instanci aktivnosti. U slučaju petlji, model aktivnosti je povezan sa više instanci
aktivnosti. Taj modeli koji leži na grani nije uzet tokom odreĎene instance procesa i nije
povezan ni sa jednom aktivnosti, objašnjavajući kardinalnost udruživanja. Dakle, mogu
potojati modeli aktivnosti u modelu procesa za koje nijedna instanca aktivnosti nije
nareĎena za odreĎenu instance procesa.

Nakon uvoĎenja dogaĎaja i naredbi dogaĎaja da predstavljaju instance aktivnosti, ova

oblast obraća pažnju na dogaĎaje i naredbe koje se dešavaju tokom procesa. Model
procesa se ograničava na instance procesa, dogaĎaja i naredbi koje nameću
izvršavanje i prevazilaženje prepreka, kao što je dosljedno izvršenje instanci aktivnosti.

24
 Slika 3.17. Model procesnih modela i procesnih instanci

Izvršenje ograničenja može biti precizno specificirano uz pomoć dogaĎaja i njihovih

zahtjeva. Izvšenje ograničenja može biti tačno precizirano dogaĎajima i njhovim
zahtjevima. Ako, na primjer, izvršenje ograničenja A slijedi u B diktira da početni
dogaĎaj instanci aktivnosti koji odgovara B, se može desiti nakon završnog dogaĎaja
instance aktivnosti koja odgovara A. Ovo je osnovna ideja opisa semantike izvršenja
instanci procesa.

Da bi se ilustrirao ovaj koncept, istražena je instance procesa bazirana na modelu

procesa prikazan ranije na slici 3.15. Svaka instanca procesa počiva na ovom procesu i
počinje analizom naredbi. Zavisno od odluke donesene na izlaznom čvoru, ili je izvšena
jednostavna provjera aktivnosti ili dodatna provjera.

Dijagrami dogaĎaja su takoĎer jako korisni za usvajanje instanci procesa. Dijagram

dogaĎaja odreĎene instance procesa je prikazan na slici 3.18, gdje je prikazan proces

25
tokom kojeg je odabrana jednostavna provjera aktivnosti.

Kada proces počne, proizvedene su instance aktivnosti za sva tri modela. U dijagramu
dogaĎaja, oznake za početni(init), odobreni(enable), završni(terminate) i
izostavljeni(skipped) dogaĎaj mogu biti izostavljene ukoliko je instanca aktvinosti kojoj
ovi dogaĎaji pripadaju jasna.

Slika 3.18. Dijagram dogaĎaja jednostavne instance procesa

Početni dogaĎaj je predstavljen čvorom N1 u procesu, a pojava ovog dogaĎaja je

predstavljena u dijagramu dogaĎaja, oznakom n1. Kada se dogaĎaj pojavi, aktivnost
analiziranja naredbi može početi i tada može stupiti u spremni oblik, predstavljen
odobrenim dogaĎajem.

Kada se ova aktivnost završi, (1)dodatna provjera aktivnosti(AdvCheck) nije potrebna,

tako da se preskočeni dogaĎaj pojavljuje spreman za svoju aktivnost i (2)jednostavna
provjera(SimpleCheck) instanca aktivnosti je odobrena, tako da kompletna aktivnost
može početi. Kada se aktivnost završi, finalni dogaĎaj n7 u instanci procesa se
pojavljuje.

Primjetite da dijagram na slici 3.18 ne predstavlja početni ili završni dogaĎaj u procesu
nego samo dogaĎaje povezane sa ulaznim/izlaznim instancama. Kompletna slika
dogaĎaja koji se pojavljuju je prikazana na figuri 3.19.

26
 Slika 3.19. Dijagram dogaĎaja jednostavne procesne instance, sa inicijalnim i finalnim dogaĎajima i
ishodom dogaĎaja

Definicija 3.4 Neka je PI set instanci procesa. Instanca procesa je bazirana na modelu
procesa i djelimično odreĎenim dogaĎajim Ei tako da:

- se Ei sastoji od dogaĎaja za cijelu instancu aktivnosti (j pripada AI) za koji model (j)
pripada N

- <i je dogaĎaj naredbi u Ei koji zadovoljava naredbe dogaĎaja u svakoj aktivnosti i

svakoj ulaznoj instanci, i naredbi dogaĎaja izmeĎu aktivnosti zadovoljava izvršenje
ograničenja kao što je definirano u modelu procesa.

Zapamtite da različiti tipovi čvorova kreiraju različite tipove dogaĎaja. Čvorovi koji
predstavljaju modela aktivnosti i oni koji predstavljaju modele izlaza mogu kreirati
dogaĎaje za započinjanje, odobravanje, početak, kraj i preskočen odreĎenih instanci,
dok se čvorovi koji predstavljaju dogaĎaje mogu samo pojaviti. To znači da se dogaĎaj
u modelu procesa može dešavati tokom akta instanci procesa baziranog na modelu.
DogaĎaj se može pojavljivati više puta, ako je na primjer dio karike u modelu procesa.

Dakle, abstrakcija je uvedena kako bi reducirala dogaĎaje aktivnosti instanci po nekoj

liniji kako bi bili prepoznatljivi po svom odobrenom, završnom ili preskočenom dogaĎaju.
Aktivnosti instanci koje su preskočene predstavljene su čistom linijom. Abstrakcija
dijagrama dodgaĎaja prikazanog na slici 3.19, je jasnije prikazana na slici 3.20.

Cijelo ovo poglavlje je zapravo temelj na kome su izgraĎena pravila koja se danas
koriste u programskim sustavima, naročito u području programiranja. Cijela logika
programskih jezika bazira se zapravo na navedenim konceptima, gdje se pokušava
pronaći najjednostavniji način dolaženja do željenog cilja,tj.rješenja, pisanjem upita
kojima se manipuliše samo odreĎenim/željenim setom podataka i time eliminiraju se
skupovi podataka za koje se vjeruje da ne sadrže rješenje, korištenjem različitih petlji (if,
if-then,if-then-else) kojima se manipuliše ograničenjima nad podacima i na osnovu
ograničenja dobijaju rješenja itd.

27
3.6 Međudejstvo procesa

Budući da tvrtke koordiniraju jedni s drugima, moguće je posmatrati i meĎudejstvo

izmeĎu tvrtki. Budući da su sve aktivnosti koje proizvode tvrtke dijelom nekih poslovnih
procesa, meĎudejstvo izmeĎu tvrtki može biti opisano meĎudejstvom poslovnih procesa
ovih tvrtki. Ove interakcije se dešavaju u peer-to-peer stilu. Primjer meĎudejstva
procesa je prikazan na slici 3.21. Kupaučujec nar neke poizvode za kompaniju za
preprodavanje. Unutar ovih vrijednosnih lanaca, poslovne funkcije su realizirane kroz
poslovne procese.

Vrijednosni lanac kupaca sadrži poslovnu funkciju naručenog proizvoda, a vrijednosni

lanac preprodavca sadrži poslovnu funkciju menagamenta naručivanja. Model
poslovnog procesa koji realizira meĎudejstvo je prikazan na slici 3.21. Poslovna funkcija
narudžbe proizvoda od strane kupca počinje njegovim stavljanjem u odreĎeni red. Ovo
stavljanje u red je realizirano sljanjem poruke preprodavaču. Na njegovoj strani, poruka
je primljena od aktivnosti primanja naredbi. Procesi se nastavljaju kao što je
specificirano. Budući da tok poruka koji se javlja izmeĎu višestrukih ktivnosti u oba
smjera, prikaz niva vrijednosnog lanca meĎudejstva poslovnih procesa - od kupca do
preprodavača - nije završena u smislu da ne drži sve moguće naredbe meĎudejstva.

Slika 3.21. MeĎudejstvo poslovnih procesa koje uključuje kupca i preprodavca

28
MeĎudejstvo instanci procesa može biti predstavljeno adekvatno dijagramima dogaĎaja.
Priroda meĎudejstva procesa je predstavljena uvoĎenjem horizontalne linije za svakog
učesnika, na kojoj se dogaĎaji učesnika pojavljuju u datom obliku. Učesnici
komuniciraju slanjem i primanjem poruka. U dijagramu dogaĎaja, meĎudejstvo
jednosmjerne poruke je predstavljeno dogaĎajem slanja, koji odgovara primljenom, i
strelice povezuju ta dva dogaĎaja. Učesnici mogu komunicirati samo slanjeim i
primanjem poruka.

U cilju da se ove komponente ilustriraju, slika 3.22 pokazuje dijagram dogaĎaja jednog
odreĎenog procesa meĎudejstva baziranog na interakciji procsa modela na slici 3.21.

Dijagram pokazuje vremenske linije kupca i preprodavača. Objedinjava i izdvaja

dogaĎaje u odnosu na započinjanje, odobravanje, početak i kraj aktivnosti. Umjesto
toga, koncentrira se na dogaĎaje poruka. Svaka poruka šalje dogaĎaj i obilježena je u
odnosu na aktivnosti instanci tokom kojih je poslata poruka, i svaka primljena poruka je
obilježena u odnosu na aktivnosti tokom koji je primljena. Ovaj proces će biti bolje
objašnjen u poglavlju 5, gdje su izražene i osobine ovakvih procesa.

Slika 3.22. Dijagram dogaĎaja meĎudejstva procesa prikazanih na slici 3.21

Očito je da je meĎudejstvo procesa vremenski ovisno.Poruka se šalje tek što je

prethodna instanca aktivnost završena. Prijem poruke aktivira, odnosno omogućava
novu aktivnost instance. Kao što je navedeno u tekstu, kupac(buyer) i
preprodavac(Reseller) predstavljeni su horizontalnim linijama na koje se smještaju
instance aktivnosti vezane za taj subjekt. Kada kod kupca postoji potreba za narudžbu,
to pokreće instancu aktivnosti i šalje se narudžba(Order).Po rijemu narudžbe(Recieve

29
Order), omogućava se instanca aktivnosti za slanje ponude(Send Invoice).Nakon
prijema ponude, kupac vrši uplatu prema ponudi(Payment),a nakon što prodavac primi
poruku da je uplata izvršena, salje proizvod(Send Products).

3.7 Modeliranje procesa podataka

Poslovni procesi počivaju na podacima. Tačno odreĎeni predstavljeni podaci, tipovi

podataka i podložnost podacima izmeĎu aktivnosti u poslovnom procesu stavljaju
sistem managementa u poziciju da kontroliše transfer bitnih podataka kao i izvedenih i
procesuiranih procesa.

3.7.1. Modeliranje podataka

Modeliranje podataka je u srži dizajna baze podataka. Naglašavanje smisla odnosa se

koristi da se klasificiraju i organiziraju podaci u datoj aplikaciji. Entity Relationship (
Entiteti-veze) modeliranja dostignuća pripada nivou metamodela, kao što j eprikazano
na slici 3.23, jer on obezbjeĎuje zahtjevani koncept za izražavanje modela podataka.
Modeliranje podataka će biti ilustrirano jednostavnom aplikacijom, imenovanom po
managementa naručivanja.

30
 Slika 3.23. Novoi MOF-a modeliranja podataka

U pokušaju modeliranja, najvažniji entiteti su definirani i klasificirani. Entiteti su stvari

odnosno koncepti stvarnog svijeta i jako su važne u modeliranju. To su recimo
narudžba,mušterija,proizvod,prodavac koji trebaju biti predstavljeni i u modelu
podataka.

Klasificirani su kao tipovi entiteta ukoliko imaju iste ili slične osobine. Recimo, narudžbe
su klasificirane odreĎenim tipom entiteta Orders (Narusžbe) .Budući da svaka narudžba
ima odreĎeni broj, datum, količinu i iznos, svi entiteti narudžbi mogu biti predstavljene
ovim tipom entiteta. Osobine entiteta su predstavljene karakteristikama odreĎenih
tipova.
Entiteti svrstani u odreĎene tipove trebaju imati sličnu, ali ne idnetičnu strukturu, jer neki
atribut može biti neobavezan. Ako odreĎena aplikacija dopušta, na primjer, da narudžba
ima ili nema neki popust, onda atribut iznos opcioni. Ovo znači da su dvije naredbe
stvrstane u isti tip i onda ako jedna ima neko obilježje a druga ne.

Tipovi entiteta u entitetima veze složenih modela trebaju biti predstavljeni odreĎenim
sistemima bilježenja, odnosno datim simbolima. Dok postoji više načina za
obilježavanje entiteta veza, tipovi entiteta su obilježeni pravougaonicima, i to imaju
oznaku - ime tipa entiteta . Slika 3.24 pokazuje entitet Narudžbe(Orders) u centru
dijagrama. Drugi tipovi u jednostavnoj aplikacijama, područjima su potrošači(customers)
ili proizvodi(products). Atributi su predstavljeni kao elipsoidi pridruženi tipovima entiteta.

31
Entiteti su jedni sa drugima povezani pomoću veza. Na primjer, potrošač "Miller"
zahtjeva narudžbu broj 42. Ovi tipovi linija izmeĎu entiteta se nazivaju
vezama(relationships). Baš kao što je previše potrošača i narudžbi entiteta, tako je i
previše odnosa potrošač-narudžba. Da bi se mogle predstaviti ove veze, tipovi veza
zahtijevaju da ih se razvrsta. U dijagramima eniteta veza, vezni tipovi su predstavljeni
rombovima, povezanim vrhovima za odreĎene tipove.

Slika 3.24. Dijagram entiteta i veza koji uključuje kupce, narudžbe i proizvode

Složena pririoda podataka u datoj aplikaciji je dobro predstavljena dijagramima entiteta

veze(ER dijagramima). Ovi dijgrami se mogu koristiti da kreiraju odreĎene tablice baza
podataka, koristeći pravila transformacije. Onda kada je odreĎena tablica baze
podataka kreirana u relacionoj bazi podataka, aplikacija može biti sačuvana dosljedno.
Podatak se može vratiti koristeći se deklarativni upitni jezik, npr. Structured Query
Language.

Dok se ova diskusija svodi na modeliranje podataka u kontekstu aplikacija baze

podataka, isti metod modeliranja se koristi da predstavlja strukture podataka u procesu
poslovnog managementa. Baziran na ovim strukturama, zavisnost podataka izmeĎu
aktivnosti u poslovnom procesu se može direktno predstaviti.

Modeliranje podataka je takoĎer baziran na ujedinjenju različitih podataka. U

preduzećima ujedinjeno je sve unaprijed rečeno, a jedna od osnovnih tema je
ujedinjenje različitih izvora podataka. Jednom kada su dostupni modeli za ove izvore
podataka, problem ujedinjenja je lociran. Postoje odreĎena ujedinjenja podataka,
tehnikama koje takoĎer uzimaju odreĎeni račun podataka na nivou pojedinačnih

32
slučajeva, ali tačno odreĎeni model podataka generalno je na adresiranje ujedinjenja
podataka.

Integracija podataka se može realizirati preslikavanjem tipova podataka. Na primjer,

postoje aplikacije na vrhu sistema baza podataka A i B, takvi da ovi sistemi imaju tablice
PotrošačA i PotrošačB. Npr., dok imeC je atribut potrošačaA, odnosi se na ime
potrošača,potrošačN može atribut u tablici PotrošačaB. S ciljem da se obje table uvežu,
atributi moraju biti preslikani. U ovom slučaju, potrošačA.Ime C je preslikano na
PotrošačaB.PotrošačaN.

U integraciji projekata, izbijaju problemi složenih integracija. Mogu postojati

karakteristike koje se ne mogu preslikati, ali takoĎer mogu postojati karakteristike koje
trebaju biti preslikane na različite tablice, često koristeći naša pravila transformacije.
Najveći problemi potiču od značenjskih različitosti. Postoje pretpostavke na podacima
koje nisu eksplicitne u modelu podataka ili u stvarnim podacima spremljenim u
baze.Ove značenjske razlike se mogu uzeti u obzir samo pri detaljnom istraživanju
značenja karakteristika, često tokom intervjua sa osobama umiješanim u modeliranje
podataka i dizajna baza podataka sistema koji se ujedinjuju.

Značenjska specifikacija podataka se može koristiti da riješi ove probleme integracije.

Kompletna značenjska specifikacija podataka obezbjeĎuje razumne resurse. Prema
tome, dalje istraživanje nareĎuje procjenu mogućnosti značenja baziranih na ujedinjenju
podataka.

U grafu koji opisuje modeliranje poslovnih procesa, zavisnost podataka je predstavljena

protokom podataka izmeĎu aktivnosti. Svakom procesu aktivnosti je dodijeljen set
ulaznih i izlaznih parametara. Ovi parametri se koriste da slijede aktivnosti u poslovnom
procesu.

Transfer, prenos podataka izmeĎu aktivnosti je poznat kao tok podataka. Pod
pretpostavkom da grafičke konstrukcije predstavljaju tok podataka izmeĎu aktivnosti,
perspektiva podataka može biti viĎena i korištena da ovjeri i poboljša poslovni proces.
Ovi aspekti su bolje opisani u dijelu 4.6, koji uvodi proces jezika baziranih na grafovima.

Dijagram entiteta i veza je osnova za kreiranje baza podataka, koje danas imaju široku
primjenu u svim oblastima života .Gotovo je nezamisliva bilo koja tvrtka koja nema svoju
bazu podataka. ER dijagram definiše entitete, koji su zapravo objekti iz stvarnog života,
koji su okarakterisani istim atributima, preko kojih su povezane grupe podataka koji
imaju istu strukturu,ali nisu potpuno isti, i veze koje predstavljaju način povezanosti tih
entiteta. Za atribute se često vežu ograničenja koja unaprijed odreĎuju vrijednost ili
skup vrijednosti koje taj atribut može poprimiti. Svaki entitet treba da ima kao
ograničenje Primarni ključ, koji predstavlja kombinaciju atributa koja čini taj
zapis/podatak jedinstvenim. Atributi koji ulaze u Primarni ključ ne smiju imati nultu

33
vrijednost, niti njihova kombinacija smije biti ista za bilo koja dva zapisa u tabeli. Postoji
i ograničeje-Strani ključ preko kojeg se tabela povezuje sa drugom tabelom u kojoj ona
predstavlja primarni ključ.

3.7.2 Djelovanje obrazaca podataka

Da bi se organizirale teme koje se odnose na podatke u managementu poslovnog

procesa, uvodi se djelovanje obrazaca. Oni sastavljaju karakteristike na način da
obraĎuju podatke u poslovnom procesu. Organizovani su prema dimenzijama uočljivosti
podataka, njihovim meĎudjelovanjima, prenosom i pripremama za rad.

Najvažnija djelovanja obrazaca podataka u odnosu na uočljivost su sljedeća:

- Zadatak podataka: Objekat podataka je nezavisan u odnosu na odreĎenu aktivnost;

nije vidljiv za druge aktivnosti istog ili drugih procesa

- Grupa podataka: Objetak podataka je uočljiv svim aktivnostima datog podprocesa.

- Djelovanje podataka: Objekt podataka je vidljiv svim aktivnostima datog poslovnog

procesa, ali pristup je ograničen od strane sistema mendžmenta poslovnog procesa,
kao što je definirano u modelu poslovnog procesa.

- Okruženje podataka: Objekt podataka je dio okruženja izvršavanja poslovnog

procesa, mogu mu pristupiti aktivnosti tokom procesa.

MeĎudejstvo obazaca podataka opisuje kako objekti mogu prolaziti izmeĎu aktivnosti i
procesa. Objekti podataka mogu komunicirati izmeĎu aktivnosti istog procesa, aktivnosti
podporocesa i aktivnosti različitih procesa. Podaci takoĎer mogu komunicirati izmeĎu
poslovnih procesa i sistema managementa.

Transfer podataka je naredno pitanje koje treba razmotriti. Može se izvršavati

prolaskom vrijednosti objekata podataka i prolaskom kratkih pregleda objekata. U
usmjerenim podacima oni mogu imati različite implikacije u procesima. U
najjednostavnijem slučaju, prisustvo objekta podataka može odobriti proces aktivnosti.
Ovi objekti mogu takoĎer biti korišteni da odrede uvjete u modelima poslovnog procesa,
npr. da odluče sa koje grane će uzeti razdvojeni čvor.

Djelovanja obrazaca su posebna značenja za organiziranje odnosa poslovnih procesa

koji se vežu za rukovanje podacima.

34
3.8 Uređenje modeliranja

Važan zadatak sistema managementa poslovnih procesa je suraĎivanje u poslu izmeĎu

osoblja u preduzeću. Da ispunimo ovo, sistem mora biti opremljen informacijama o
organizacionoj strukturi u kojoj će se poslovni proces izvršavati.

Nivoi abstrakcije u ureĎenju modeliranja su prikazani na slici 3.25. Kao u modeliranju

procesa i modeliranju podataka, složeni model obezbjeĎuje značenja istih modela u
slučaju organizacije. Elementi na ovom nivou su: pozicije, uloge, timovi i odnosi izmeĎu
pozicija poput nadzornog organa. Postoji nekoliko pravila o tome kako da se izraze
organizacione strukture kao i sistemi bilježenja.

Osnovni pojam nakon organizacije modeliranja jeste resurs / izvor, entitet koji može
ivesti rad za tvrtku. Osnovni koncept obuhvata ljudske i druge izvore, kao sto su
kamioni, skladišta i druga oprema koja je potrebna kompaniji a ispuni uslove.

Osobe su dijelom organizacije, tipične poslovne organizacije. Oni rade kako bi ispunili
poslovne ciljeve tvrtke. Svaka osoba ima neku poziciju i dužnosti i privilegije te osobe
dolaze sa pozicijom. Ovo dopušta popunjavanje pozicija u skladu sa cjelokupnim
planom organizacije. U skladu s tim, kompanija može izaći na kraj s promjenama u
osoblju. Organizacione zajednice su stalne grupe ljudi osnovane na njihovim
pozicijama. Timovi i njihovi projekti su posebne organizacije bez stalne prirode. Oni
počivaju na objektu prikazanom na slici 3.26.

Slika 3.25. Nivoi MOF-a sa aspekta organiziranja

35
Slika 3.27 pokazuje organizacionu kartu fiktivne tvrtke. S ciljem da se slika ne pretrpa,
sadrži samo pozicije na najvišim nivoima, glavni izvršni nivo i nivo odjela. Ovaj
posljednji je organizaciona zajednica sa više članova na pozicijama.

Slika 3.26. Organizacioni metamodel

Veza izmeĎu organizacione strukture tvrtke i poslovnih procesa je uspostavljena

pomoću radnih dijelova. Oni predstavljaju aktivnosti instanci koje se trebaju izvršiti i
pomažu im znanja i iskustva radnika kako bi se olakšala selekcija. Uglavnom, kada
sistem managementa u poslovnom procesu odredi koju će instancu aktivnosti staviti u
gotovi oblik, radni dio je ponuĎen da postavi iskusne radnike.

36
 Slika 3.27. Jednostavna orkanizaciona mapa

Svaki radni dio je povezan sa tačno jednom instancom aktivnosti. Selekcija procesa
učesnika je subjekt za raspodjelu resursa i mehanizama, o kojima će se govoriti ispod.
Kada radnik završi instancu aktivnosti, management je informiran tako da instanca
procesa može biti nastavljena bez problema.

S ciljem diskusije o raspodjeli resursa, razmatra se dijagram stanja prelaza radnih

dijelova, a veze aktivnosti instanci do odgovarajućih oblika tranzicije su obezbijeĎene.
Jedan takav dijgram je prikazan na slici 3.28.

Direktna alokacija

U direktnoj alokaciji, jedna osoba dobija odobrenje za sve aktivnosti instanci odreĎenog
modela aktivnosti. Ovaj obrazac je jako koristan u slučaju kada postoji jedna odreĎena
osoba koja je prikladna za izvoĎenje ovakvih radnji, kao recimo direktor tvrtke, koji će
na kraju odlučiti o velikim ulaganjima odreĎenih sredstava.

Direktna alokacija se uvijek može predstaviti alokacijom temeljenom na ulozi, o kojoj

37
ćemo sada govoriti, jednostavno usmjeravanjem uloge sa jednim članom, u našem
slučaju: vlasnikom kompanije. Ako ova će imovina organizacije ostati kao takva duži
period vremena, uvoĎenje odvojene uloge (vlasnik) nije potrebno, tako da se direktna
alokacija može koristiti. Granice direktne alokacije će biti spomenute u kontekstu
alokacije koja se temelji na funkciji.

Alokacija temeljena na ulozi

Ova alokacija je standardni put alociranja rada članovima organizacije. Temelji se na

razumijevajnu da su svi članova koji imaju odreĎenu funkciju na neki način ekvivalentni,
tako da svaki član može voditi odreĎenu radnu jedinicu.

Svakom modelu aktivnosti u modelu poslovnog procesa, uloga je dodijeljena, odreĎujući

sve članove sposobne za rad i izvoĎenje odreĎenih aktivnosti. Preslikavanje uloge
informacija na odreĎene obrazovane radnike se nazifa razrješenje funkcije. Trenutna
informacija dostupna radniku je korištena tokom uloge razrješenja.

Dva su načina realiziranja ove alokacije. Prvi je da kada instanca aktivnosti stupi u
gspreni oblik radni dio uspostavi komunikaciju s članovima grupe. Kada jedan član
grupe odabere radni dio, dijelovi koji su bili u kontaktu s drugim članovima grupe su
izbrisani. Drugi način je da je jedna osoba izabrana da izvede instancu aktivnosti, tako
da je kreiran smao jedan radni dio.

Ovo odobrenje snabdijeva više zanimljivih prednosti, s poštovanjem direktnoj alokaciji, a

sve se odnose na poboljšanje fleksibilnosti poslovnih procesa. Prvo, model poslovnog
procesa ne treba biti zamijenjen kada doĎe do promjena u osoblju, npr. kada su neki
zaposlenici otišli u penziju, a drugi, novi došli na njihovo mjesto. Kada se koristi direktna
alokacija, svaka promjena u osoblju, koja se odnosi na odreĎene osobe rezultira
promjenama u cijelom modelu poslovnog procesa.

Drugo, riješenjem funkcije u odreĎenom vremenskom periodu u poslovnom procesu,

jedino prisutne osobe su odabrane za izvršavanje aktivnosti. Ovakav pristup izbjegava
situacije u kojima osobr odabrane za izvoĎenje aktivnosti instanci koje trenutno nisu tu,
npr. zbog odsustva i sl. U direktnim alokacijama dolazi do obustavljanja poslovnog
procesa kada osoba nije tu.

OdgoĎena alokacija

U ovoj alokaciji, odluka o tome ko će izvesti odreĎenu aktivnost je donesena za vrijeme

trajanja poslovnog procesa. Do njegovog kraja, nema razlike izmeĎu odgoĎenih i

38
alokacija koje se temelje na ulogama. U svakom slučaju, odgoĎena alokacija je izvršena
kao eksplicitan korak u poslovnom procesu, i nije pod utjecajem informacije o ulogama.

Odobrenje

Odobrenje raspodjeljuje ljude na njihove pozicije za inastance aktivnost. Nabrojana je

lista pozicija koja odreĎuje ljude koji mogu izvršavati odreĎene aktivnosti. Ovo bi se
takoĎer moglo ostvariti dodavanjem nove uloge koja bi zahvatala odobrenje. Specifičan
tip odobrenja koji koristi sposobnosti i znanje radnika da izvodi alokaciju je takoĎer
moguć.

Razdvajanje dužnosti

Razdvajanje dužnosti u shemi alokacije se odnosi na različita odobrenja za vrijeme

jednog poslovnog procesa. Na primjer, potrebno je da se potpiše dokument od strane
dva uposlenika koji imaju istu funkciju. U alokaciji baziranoj na ulogama, ovo bi mogao
uraditi samo jedan uposlenik. Razdvajanje dužnosti dopušta odnos alokacija u smislu
da je ovo isljučeno, tako da je svaki dokument potpisan od strane dva različita
uposlenika.

Rukovanje stanjem

U ovoj shemi odreĎene aktivnosti u poslovnom procesu zahtijevaju razumijevanje

cijelog slučaja. U ovim okruženjima, korisno je da se jedan iskusan radnik suoči sa svim
aktivnostima jednog instanci procesa. Ovim se izbjegavau greške i reducira vrijeme
procesuiranja zato što je radnik već upoznat sa slučajem i on sam može bolje i brže
riješiti probleme nego više radnika koji ne poznaju slučaj. Ovo je ključni koncept u
rukovanju stanjem, koji je bolje opisan u dijelu 7.5.

Alokacija bazirana na historiji

Ideja ove alokacije je da odabir osobe koja radi na aktivnosti inastanci zavisi od toga šta
je osoba ranije radila, dakle na podacima o aktivnostima koje je izvršavala. Ovo uključje
i druge poslovne procese. Cilj je da se odaberu osobe u skladu sa njihovim ličnim
iskustvima. Ove informacije trebaju biti predstavljene managementu tako da on odlučuje

39
o ovom odabiru. Ovaj obrazac je koristan za realiziranje strategije "lice u lice", gdje za
svakog potrošača postoji jedna osoba odgovorna za sve vidove komunikacije.

Organizaciona alokacija

Ukoliko se koristi ova alokacija, nijedna uloga osim pozicije u okviru koje su korištene
alokacije za izvoĎenje aktivnosti. Npr., da bi se odobrili troškovi, menadžer
organizacione zajednice to mora odobriti. Zavisno od jezika koji se koristi da se izrazi
ovo odobrenje, pravila složenih alokcaija se moraju realizirati, od kojih svi u
organizacionoj strukturi kompanije od ove alokacije imaju korist.

3.9 Operacija modeliranja

Aktivnosti mogu biti razlikovane zavisno od nivoa podrške sistema. Ishodi sistema
radnih dijelova i ljudskih meĎudejstva su uvedene kao karakterizacija različitih aktova
poslovnih procesa.

Klasifikacija aktivnosti u poslovnom procesu je uvedena u slici 3.1 a sastoji se od

sistema aktivnosti, korisničkih aktivnosti i fizičkih aktivnosti. Da skratimo, sistem
aktivnosti se izvodi sotverskim sistemima bez korisničke aktivnosti, jer je ona potrebna
za angažiranje ljudi i fizičkih aktivnosti - ne miješa se korištenje u informacione sisteme.

Tokom akta ljudskih interakcija, iskusni radnici izvode aktivnosti instanci. Kada radnik
počne sa radom na odreĎenoj aktivnosti, odogvarajuća aplikacija u programu je
započela i ulazni podaci su odreĎeni u modelu procesa i kao takvi preneseni na
program aplikacije. Kada radnik završi sa radom, izlani podaci se nalaze u izlaznim
jedinicama. Ove vrijednosti parametara mogu biti sačuvane u programu aplikacija.
TakoĎer, mogu biti preneseni sistemom managementa poslovnih procesa na sljedeću
aktivnost. Primjer je aplikacija u sustavu nekog supermarketa, gdje se na osnovu koda
proizvoda, kao ulaznog podatka, na ekranu ispisuje cijena tog proizvoda, dakle izlazni
podatak.Nakon što se unesu svi proizvodi koje kupac ima u košarici, aktivnost se kroz
proces prenosi na novu aktivnost, a to je izračun i prikaz ukupnog iznosa računa
kupca(izlazni podatak), na osnovu cijene svakog pojedinog artikla(ulazni podatak). Dalje
se i ova aktivnos prenosi na naovu aktivnost, a to je printanje računa kao poslednjeg
izlaznog podatka, odnosno poslednje aktivnosti u poslovnom procesu.

Modeliranje poslovnih procesa insistira na preslikavanju visoko rangirane i odlike

specifičnih područja za aplikacije; tehnički detalji- glavna komponenta operativne

40
perspektive - spremljeni na iznos u konfiguracijskoj fazi za vrijeme trajanja poslovnog
procesa. Heterogena priroda informativnih sistema dovodi do toga da većina definicija
nije dosljedna. Zbog toga operacioni sistemi poslovnih procesa su predstavljeni
servisom, poboljšavajući informiranost.

Isti novoi abstrakcije se primjenjuju za operativne perspektive kao na modeliranje drugih

izgleda: na nivou složenih modela nalazi se spoj definicija jezika. Oni opisuju specifični
nivo izvršenja kategorizacije.

Ovo doprinosi modeliranju aktivnosti instanci (i procesu instanci) zbog toga što
aktivnosti instanci mogu biti realizirane izvršenjem programskog koda. TakoĎer
doprinosi organizacionim elementima u kojima ljudi rade na nivoima instanci. Oni su,
odgovorni za izvršavanje aktivnosti instanci.

S ciljem da se ova softverska aktivnost automatski definira, management poslovnih

procesa pristupa ovim sistemima. Operativni izgled modeliranja poslovnih procesa
opisuje informaciju koja govori o funkcionalnosti ovih sistema. Operativni izlged
uključuje okruženje programa, definicije ulaznih i izlaznih parametara i njihovo
preslikavanje na ulazne i izlazne parametre aktivnosti poslovnih procesa. Dakle, ovaj
postupak mora biti detaljan kako bi uspio poboljšati poslovne procese.

Ova perspektiva nije ograničena samo na funkcionalne potrebe, jer i one

nefunkcionalne moraju biti predstavljene.

Slika 3.29. MOF nivoi sa operatinog aspekta

41
Interfejs definicioni jezici (Interface definition languages) se koriste za odreĎivanje
koristi procedura i funkcija, razvijenih softverskim sistemom. TakoĎer su bitni za
spajanje programskih sistema koji su razvijeni nezavisno jedni od drugih. Kreiranje
servisnih omota koji hermetički zatvaraju postojeće informacije bitne za poslovne
funkcije se naziva servisno odobrenje. Dok je tu okruženje u kojem je jedan servis
realiziran od strane jednog informacionog sistema, tipičan je slučaj gdje je poslovni
proces realiziran uzajamnim djelovanjem višestrukih sistema aplikacija, praveći sistem
odobravanja kompleksnim i skupocjenim.

Omogućavanje servisa(usluga) (Service enabling) zatvara granicu izmeĎu aktivnosti

poslovnog procesa i tehničke infrastrukture koja ga realizira. Ova situacija j prikazana
na slici 3.30 gdje je aktivnost poslovnog procesa - analiziranje naredbe(Analyze Order),
realizirana sistemom koji se zove: servis analiziranja naredbe(Analyze Srvice Order)
koji kombinira tri podreĎena softverska sistema .

Slika 3.30. Omogućvanje servisa (Service enabling) zatvara granicu izmeĎu aktivnosti poslovnog procesa
i tehničke infrastrukture

42
Izračunavanje servisa je takoĎer olakšavajuća okolnost za odreĎen aktivnosti poslovnih
procesa. Ova situacija je predstavljena u konceptualnom modelu gdje postoje veze
izmeĎu aktivnosti i servisa. To znači da data aktivnost može biti realizirana složenim
servisima. Situacija je opisana i na slici 3.31 gdje je aplikacija ujedinjenja tvrtke
prikazana. Dva sistema pokazuju svoju funkcionalnost kroz tvrtku. Za svaki postoji
priključak koji krije različitost datih sistema od onih na višim nivoima. Na primjeru
prikazanom na slici3.31, komponenta programa narudžba_324 ne traži aplikaciju tvrtke.
Takav je slučaj kad sistem izlaže meĎuveze i prikladne dobro dokumentirane, kao što
su Web servisi meĎuveza.

Slika 3.31. Detaljan prikaz omogućavanja servisa, sa atomičnim servisima i kompozitnim

servisima(uslugama)

43
Kao primjer možemo navesti obavljanje odreĎenih zadataka/aktivnosti na Internetu,
gdje korisnik koristi web aplikcaiju koja opet pristupa različitim servisima da bi realizirala
korisnički zahtjev.

3.10. Prilagodljivost(fleksibilnost) poslovnih procesa

Pitanje prilagodljivosti je rangirano na organizacionom nivou, gdje se istražuju poslovni

procesi i na operacionom gdje su ljudska interakcija u toku rada i sistem toka rada
veoma bitni koncepti za realiziranje poslovnog procesa.

Prema Wikipediji, prilagodljivost(fleksibilnost) znači „mogućnost usvajanja različitih

okolnosti“.

Poslovni procesi se trebalu lakše prilagoditi promjenama. Budući da su proizvodi

kompanija uslovljeni poslovnim procesima, prilagodljivost je važan faktor u ekonomiji.

Kada se govori o fleksibilnosti, različiti aspketi moraju biti uzeti u obzir. Prije svega,
prilagodljivost je predstavljena poslovnim procesima, jer su prilagoĎavanja jasna,
grafičko predstavljane poslovnih procesa je veoma dobro rješenje.

U tipičnim okruženjima toka rada, kao što su sistem toka rad i sistem toka rada ljudskim
interakcijama, informacioni sistemi su jako neophodni za aktivnosti toka rada. U
dinamičnim programskim predjelima, gdje je funkcionalnost osigurana kroz
standardizirane veze, sposobnost da se promijeni spajanje odreĎenih softvera za radne
aktivnosti je jos jedna prednost prilagodljivosti.

Eksplicitna predstavljanja procesa

Sistemi managementa poslovnih procesa su kreirani da popune razlike izmeĎu

poslovnih ciljeva i njihove realizacije značenjem informativne tehnologije. Osnovni način
da se ova osobina izvrši, jeste predstavljanje poslovnih procesa na različitim nivoima.
Grafička bilježenja kao što su ona u poglavljima 4 i 5, su jako dobro opremljena da
podrže komunikaciju o ovim opercaijama biznisa i izvršenju veza koje ih čine. Tačni
procesi osiguravaju prilagodljivost, jer neke promjene mogu izazvati smetnje u datom
procesu. U ovom kontekstu prilagodljivost je nastala zbog promjena u modelu

44
poslovnog procesa koje su odmah prevedene na stvarne instance poslovnog procesa.
Jednostavni proces je pokazan na slici 3.32 gdje je uveden koncept ilustriranja. Ovaj
proces prolazi kroz sekvencu aktivnosti, gdje početni dogaĎaj uzrokuje prvu aktivnost
Pohrani Narudžbu(Store Order), zatim se provjerava stanje zaliha(Check Inventory),
potom šalje ponuda(SendInvoice),nakon toga slijedi prijem sredstava(Recieve funds), a
tek nakon što su sredstva primljena, priprema se isporuka(Prepare Shipment), te
isporučuje roba(Ship Goods), te arhivira narudžba. Ovakav proces može znatno usporiti
poslovni proces jer se čeka prijem sredstava i tek onda se počinje pripremati isporuka,
za razliku od procesa prikazanog na slici 3.33., gdje se istodobno šalje ponuda i sprema
isporuka, pa čak i isporučuje roba prije uplate sredstava od strane naručioca, što
doprinosi kvalitetu poslovnih procesa.

Slika 3.32. Jednostavan model poslovnog procesa

Diskusija o problemu poslovnih instanci može biti istražena bez procesa. Ako aktivnosti
mogu biti trenutno izvršene, njihova naredba je nebitna. Npr., priprema za fakturu može
početi prije nego što je dostava donesena. Nova i poboljšana verzija poslovnog procesa
je prikazana na slici 3.33. Iako su na ovom primjeru nedostaci poslovnih procesa očiti,
poboljšanje procesa pokazuje kako proces uvoĎenjem konkurencije pokazuje kako tačni
model procesa može brže odgovoriti na promjene.

PrevoĎenje poslovnih procesa u stvarna operatvina okruženja može biti realizirano na

više načina. Ukoliko je poslovni proces realiziran ljudskom interakcijom, onda preraĎeni
model poslovnog procesa treba biti ugraĎen u sistem managementa radnog toka.
Razmještaj uključuje model sa informacijama kako bi se proces mogao izvršavati.
Uglavnom, mora postojati prevod sa grafičkog modela do izvršnog formata koji bi bio na
odreĎenom jeziku ili u slučaju sistema radnih dijelova, u odreĎenom okruženju,
servisnom jeziku kompozicije. U bilo kojoj od ove dvije realizacije, eksplicitno
predstavljanje procesa predviĎa prilagoĎavanje da se promijeni proces i konačno doda
novi, izmijenjeni.

45
 Slika 3.33. Primjer modela poslovnog procesa, dokazana verzija sa konkurencijom

Nove instance procesa će sada slijediti nove, poboljšane modele poslovnog procesa.
Fleksibilnost koja rezultira od eksplicitnog modeliranja poslovnih procesa je izvorna za
aplikacije managementa. U dijelu 7.2 će se govoriti o mijenjanju strukture gotovih radnih
instanci i čak većem stepenu prilagodljivosti.

Organizaciono modeliranje

Ova vrsta modeliranja takoĎer podrazumijeva prilagodljivost u managementu poslovnih

procesa. U ovom dijelu, opisana je uloga u regulisanju tvrtke, u kojoj su istraživana
različita načela da bi se udružili iskustvo radnika i aktivnosti poslovnih procesa.

U slučaju ljudskog meĎudejstva, okruženje poslovnih procesa mora da uzme u obzir

organizacionu strukturu kompanije koja vodi poslovne procese. Fleksibilnost u
organizacionom modeliranju je postignuta dodjeljivanjem uloga aktivnostima procesa, a
ne odreĎenim individuama.

Udruživanjem uloga sa modelima aktivnosti u vrijeme dizajna i davanja uloga osoblju

koje je kompetentno, vješto i sposobno da izvede odreĎene aktivnosti u datom
vremenu, prilagodljivost je poboljšana jer promjene u strukturi organizacije osoblja ne
utječu na poslovne procese. Na primjer, odsutni radnici nisu povezani sa odreĎenim
instancama aktivnosti, kao što su osobe koje su trebutno dostupne.Taj donamički
aspekt u organiziranju može biti predstavljen na nivou modela. Dakle, promjene u
osoblju su skrivene od procesa, onoliko koliko to definiraju uloge u modelu.

46
 Slika 3.34. Jednostavan model poslovnog procesa sa infrmacijom uloge

Posmatrajmo poslovni proces sa setom aktivnosti koje trebaju biti izvršene sekventno.
Primjer takvog biznis procesa u bankarskom okruženju je prikazan na shemi 3.34. Te
aktivnosti uključuju zadavanje upita za kredit(Enter Credit Request), skupljanje
informacija o finansijskoj situaciji klijenta(Analyze Client), predlaganje odluke na upit za
kredit(Propose Decision) i na karaju provjeravanje i prenošenje odluke(Finalize
Decision). Podskup ovih aktivnosti je označen u istoj ulozi. U primjeru,
računovoĎa(Clerk) je odgovoran za prva tri koraka/aktivnosti, dok je njegov
nadreĎeni(Manager) odgovoran za konačnu odluku i njeno prenošenje do klijenta. Ova
situacija može biti predstavljean u modelu poslovnog procesa dodjeljivanjem uloge
RačunovoĎa i uloge Šef sa odreĎenim aktivnostima.

Za svaki instance procesa po analizi uloga, sistem nudi ove aktivnosti radnicima koji se
mogu nositi sa datom ulogom. Dok je ova analiza tačna sa formalne, obične tačke
gledišta, ova situacija je neželjena u većini slučajeva jer svaki zaposlenik mora
razumjeti kontekst slučaja, zbog čega ovaj proces traje duže i često dovodi do
pogrešnih odluka. Da bi se utrvrdila adekvatna podrška kroz analizu uloga, model
poslovnog procesa treba da sadrži informacije tako da svako ko rukovodi osnovnom
aktivnošću može rukovoditi i ostalim.

Slika 3.35. Jednostavna instanca poslovnog procesa sa stručnim osobljem povezanim sa aktivnostima

47
 Slika 3.36. Jednostavna instanca poslovnog procesa sa jednim stručnim radnikom povezanim sa
računovodstvenim aktivnostima

Slika prikazuje da na nivou instance poslovnog procesa, radici su povezani sa

instancama aktivnosti, dok na nivou modela poslovnog procesa, uloge su povezane sa
modelom aktivnosti.

Ova uloga analize je jako dobra ukoliko je isti radnik dostupan tokom cijelog procesa
instanci, ili barem tokom procesa kojim upravlja. Ali ima slučajeva kada osoba počne
raditi na procesu, uvoĎenjem prve aktivnosti, ali je onda odsutna. U ovom slučaju
odluka mora biti donesena: ili će se proces obustaviti dok se osoba ne vrati ili će se taj
zadatak prnijeti na drugog uposlenika. U tom slučaju, drugi zaposlenik mora razumjeti
cijeli kontekst slučaja prije nego što počne sa izvršavanjem aktivnosti.

Odabir poslovnih partnera

Modeliranje organizacionih aspekata poslovnih procesa može biti preneseno na

poslovne partnenre što je jako važno u kontkstu procesa business - business.

Smatrajući poslovne procese koreografijom sa poslovnim partnerima, svaka predstava

je odreĎena uloga u koreografiji.

Ako postoji uloga Shipper(dostavljač), specificirana zbog potreba dostavljanja robe, ona
može biti dodijeljena kao prednost nekoj tvrtci. Dodatna fleksibilnost je postignuta jer
učesnici u koreografiji oragniziranja nisu teško povezani, već predstavljeni na nivou
modela. U situacijama gdje su roba, pošiljaoc i primaoc odreĎeni samo za vrijeme
izvršenja procesa, dinamička selekcija Dostavljača je korisna.
48
 Slika 3.37. Poslovni partneri odabrani za vrijeme dogaĎanja, uz pomoć posrednika

Primjer miješanja potrošača, posrednika i više dobavljača je prikazano n slici 3.37. u

ovom primjeru, potrošač koristi posrednika da odabere dobavljača. Prije nego se ovaj
proces realizira, posrednik prikuplja informacije o dostupnosti dobavljača. Proces
počinje kreiranjem naredbe od strane potrošača. On tu poruku šalje posredniku, koji
traži najboljeg dobvljača i zatim šalje odgovor potrošaču. Kada potrošač primi podatke o
dobavljaču, on šalje svoje zahtjeve istom i kada ovaj primi zahtjeve, šalje robu
potrošaču i proces je završen ovim činom.

U ovom primjeru, odabir dobavljača je izvršen uvoĎenjem treće osobe, posrednika.

MeĎutim, isti proces je moguće izvesti bez miješanja treće osobe. U ovom slučaju,
uloga analize nije izvršena zahvaljujući sistemu managementa, nego znanju i iskustvu
radnika.

49
Standardizirani softverski interfejs

Standardizirani interfejsi postojećih softverskih sistema su drugo značenje fleksibilnosti

u managementu poslovnih procesa. U kontekstu menadžmeta poslovnih procesa,
standardizirani softverski interfejsi su jako važni u sistemu radnih tokova, te ljudskim
interakcijama toka rada. Fleksibilno udruživanje aktivnosti procesa nam dozvoljava da
promijenimo implementaciju odreĎenih aktivnosti procesa bez mijenjanja cijelog
poslovnog procesa. Primjer pomjena u izvršavanju aktivnosti u poslovnom procesu su
predstavljeni na slici 3.38. ERP sistem ima ulogu managementa narudĎbi.

Slika 3.38. Poslovni proces koristi funkcionalnost ERP sistema za realizaciju aktivnosti procesa, dok sam
poslovni proces ostaje nepromijenjen

Kao što vidimo na slici za obavljanje pojedinih aktivnosti u ovom slučaju se koristi
softverski interfejs. Porvjeru zaliha(Check Inventory) obavlja softverski interfejs i time
štedimo ljudske resurse, ali i vrijeme jer se nekoliko aktivnosti, poput pripreme ponude i
pripreme isporuke ili prijem novca i slanje robe, mogu obavljati istovremeno, što
doprinosi kvalitetu poslovnog procesa.

Standardiziranim programskim interfejsom, aktivnosti poslovnih procesa mogu korstiti

prednosti novih sistema bez mijenjanja poslovnih procesa, što doprinosi fleksibilnosti
implementacije poslovnih procesa, jer realizacija odreĎenih aktivnosti procesa može biti

50
promijenjena bez da se mijenja cijeli proces.

Ova diskusija opisuje idealna podešavanja u kojim realiziranja aktivnosti mogu biti lahko
izmijenjenja. MeĎutim, odreĎene osobine sistema prave definicije koje brišu sva
moguća meĎudejstva.

Uglavnom, neki sistemi lakše realiziraju kompleksne podprocese, nego jednostavne,

pojedinačne aktivnosti u poslovnom procesu. Ponekad procesi realizirani tradicionalnim
sistemima i procesi realizirani modernim se ne mogu odmah porediti. To se desi onda
kada se razviju meĎudejstva informacija oba sistema. Ovo su jako složeni problemi i
postoji više načina na koji se rješavaju. Jedan je razvijanje softvera koji će i podatke iz
starih programa učiniti dosutpnim i vidljivim.

3.11. Arhitektura okruženja za izvršenje procesa

Ovaj dio se bazira na predstavljanju managementa poslovnih procesa i činjenje istih

sposobnim da kontroliraju aktove poslovnih procesa baziranih na modelima procesa.

Slika 3.39. Model arhitekture sistema menagamenta poslovnih procesa

51
Slika 3.39 pokazuje model arhitekture managementa visoko rangiranih poslovni proces
koji se sastoji od komponenti i veza. Uloge komonenti modela argitekture ovog procesa
su:

- Modeliranje poslovnog procesa(Business Process Modeling): koristi se za kreiranje

modela poslovnih procesa, sadržava informacije o aktivnostima, operacijama i
strukturama poslovnog procesa. Ovaj podsistem arhitekture se može realizirati alatima
modeliranja poslovnih procesa.

- Okruženje poslovnih procesa(Business Process Environment): dešavanja instanci

procesa bazirana na modelima procesa.

- Skladište modela poslovnog procesa(Business Process Model Repository): tu su

smješteni i čuvani modeli kreirani uz pomoć modelirajućih komponenti poslovnih
procesa.

- Stroj(Proces Engine): zadužen je za kontroliranje i izvršavanje poslovnog procesa. On

ima ključnu ulogu u sistemu managementa poslovnih procesa i poziva ga Okruženje
poslovnih procesaKoristi modele procesa za kontroliranje djelovanja instanci procesa..
Da izvrši odreĎenu instancu aktivnosti, poziva enitete koji djeluju kao obezbjeĎivači
zahtjevane funkcionalnosti.

- Dobavljač/ObezbjeĎivač servisa(Servis Providers): dobavlja aplikacijske servise

pomoću kojih se aktivnosti poslovnih procesa realiziraju. Organizaciona i tehnička
informacija koju Stroj treba da bi riješio i pristupio Dobavljaču servisa, je takoĎer
pohranjena u Skladištu modela poslovnih procesa.

Ove komponente modela arhitekture kontroliraju dejstvo instanci procesa. Da bi se

zabilježila distributivna priroda izvršenja poslovnih procesa, komponente i
ObezbjeĎivači servisa su predstavljeni agentima koji komuniciraju slanjem i primanjem
poruka, kao što je prikazano na slici 3.39.

Ulazi/izlazi su tačke(čvorovi) u modelu procesa koji sačinjavaju i održavaju tok

procesa.Zato, svaki ovaj čvor u Stroju treba da izvši neku akciju. Ovo funkcioniše tako
da proizvod procesa Stroja je predstavljen instancom ulaza/izlaza, baš kao što je rad
definisan modelom aktivnosti predstavljen instancom aktivnosti. Svrha instanci
izlaza/ulaza je da ih Stroj izvrši, dok su instance aktivnosti izvršene od strane
Dobavljača servisa, što zahtjeva nelokalnu komunikaciju.

52
 Slika 3.40. Model procesa i dogaĎaji instance procesa

Slika 3.41. Dijagram dogaĎanja okoline izvršenja poslovnih procesa

Na slici 3. 40 su prikazani dogaĎaji koji se dešavaju unutar Stroja tokom djelovanja

instance procesa, a slika 3.41 predstavlja dijagram dogaĎanja istog procesa. Ovo je
složeniji oblik ranije objašnjenih slika, koji se tiču navedenih pojmova, a objašnjenja su
analogna primjerima koje smo ranije navodili, tako da ovdje neće biti diskutirana.

53
Bibliografske bilješke

Fondacija modeliranja poslovnog procesa se bazira na konceptualnom modeliranju

tehnika koje su bitne karakteristike komjuterskih nauka. Najveći broj dijagrama je iz
Unfied Modelling Language objavljen od strane Grady Booch (2005). Dijagrami
dogaĎaja i razlog distribuiranja sistema je uveo Lamport (1978)

Funkcionalna raspodjela poslovnih funkcija od visokorangiranih do operativnih

aktivnosti: Porter (1998). Dizajn programskih sistema: Jablonski (1997). Konceptualni
model eniteta u radnim dijelovima: Weske (2000), modeliranje podataka u sistemima
baza podataka Peter Chen in Chen (1976), zatim u sličnom kontekstu: ramakrishnan i
Gehrke (2002). O'Neil i O'Neil (2000)

Organizaiono modeliranje u kontekstu procesa managementa: Russel (2005).

MeĎuveze programskih sistema: Henning i Vinoski (1999) i na kraju, Reijers (2005) vodi
diskusiju o generalizaciji i specijalizaciji u alokacijama.

54