1

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

2

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.

3

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.

4

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

5

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

6

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.

7

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

8

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

9

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.

10

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.

11

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.

12

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

13

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

14

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

15

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.

16

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

17

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:

18

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.

19

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.

20

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

21

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

22

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

23

(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

24

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.

25

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

26

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.

27

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.

28

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

29

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

30

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.

31

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.

32

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

33

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

34

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.

35

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

36

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.

37

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

38

ć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

39

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

40

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

41

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

42

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

43

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)

44

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

45

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.

46

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.

47

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

48

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.

49

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.

50

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

51

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

52

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.

53

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.

54

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.