GORDAN TOPIĆ Ericsson Nikola Tesla d.d. gordan.topic@ericsson.com
MODELIRANJE POSLOVNIH PROCESA I OPTIMIZACIJA RESURSA TEHNOLOGIJOM OBOJENIH PETRIJEVIH MREŽA Sažetak Mnoge industrije imaju vrlo kompleksne i zahtjevne, poslovne i proizvodne procese. U svakom slučaju, i poslovni i proizvodni procesi zahtjevaju stvaranje optimalnog vremenskog plana za određene radne uvjete. Ovaj rad prikazuje kako pridobiti procesno znanje korisno za optimizaciju poslovnih aktivnosti i resursa. U tu svrhu, za modeliranje, simulaciju i optimizaciju procesa, korištene su obojene Petrijeve mreže (CPN), s ciljem predviđanja vremena i cijene, potrebnih za razvijanje softverskog proizvoda s određenim početnim uvjetima. U članku je objašnjen i optimiziran jednostavan model razvojnog procesa softvera. Ključne riječi: modeliranje i simulacija procesa, razvojni proces softvera, optimizacija resursa, obojene Petrijeve mreže 1.
UVOD
Visoki standardi osiguranja kvalitete zahtjevaju potpunu kontrolu poslovnih procesa jedne proizvodne organizacije. Prema svojoj prirodi ta metoda pripada najvišoj, 5. razini CMMI modela, budući da posjeduje mogućnost optimizacije, predviđanja, potpune analize i upravljivosti svakog elementa razvojnog procesa, dajući pri tom kao rezultat znanje o procesu, timovima, proizvodu i dinamici razvoja. U ovom radu objašnjena je metoda visokog osiguranja kvalitete proizvodno-poslovnih procesa na primjeru procesa prizvodnje softvera (SW) za kompleksne sustave kao što su automatske telefonske centrale. Telekomunikacijska industrija razvoja softvera je temeljena na velikim i kompleksnim poslovnim procesima, gdje je razvojni proces jedan od najkompliciranijih. Zadatak koji se pojavljuje u upravljanju takvim procesima je stvaranje optimalnog vremenskog plana razvoja za određene radne uvjete. U ovom radu prikazano je kako pridobiti procesno znanje korisno za optimizaciju poslovnih aktivnosti. U tu svrhu, za modeliranje i simulaciju procesnih struktura, korištene su obojene Petrijeve mreže s ciljem predviđanja vremena i cijene, potrebnih za razvijanje softverskog proizvoda u određenim uvjetima. Da bi se uopće pristupilo modeliranju i optimizaciji poslovnih procesa, kao početni uvijet mora biti zadovoljena bar minimalna razina osiguranja kvalitete navedena u ISO 9000/2000 normi. Matematički model i tehnologija obojenih Petrijevih mreža pružaju detaljni uvid i kontrolu u svaki dio i resurs procesa, s preduvjetom da je proces detaljno opisan elementima Petrijeve notacije do zadovoljavajuće razine dekompozicije. U ovom primjeru model poslovnog procesa razvoja softvera je opisan na tri razine, strategijskoj, taktičkoj i operativnoj. Strategijsko-projektna razina sadrži grubu sliku elemenata razvojnog procesa prikazanih kao faze razvoja, te dio za prikupljanje i analizu rezultata simulacije. Taktička razina sadrži opis podprocesa korištenih unutar faza razvoja, mjesta kontrole (miljokaze) i točke odluke. Svaki podproces, opisan je na operativnoj razini mrežom koja upravlja projektnim podacima, resursima, dokumentacijom tokovima razvoja.
6. HRVATSKA KONFERENCIJA O KVALITETI – OPATIJA, 18.-20. 05. 2005.
2.
IZRADA MODELA POSLOVNOG PROCESA
Model je približni prikaz sustava ili procesa koji služi za razumijevanje sustava, te za njegovo mijenjanje ili upravljanje njime. Modeli moraju biti što jednostavniji, a ipak ispravni za svrhu za koju su napravljeni. Modeli omogućuju opis kompleksnih fenomena, njihovo bolje razumijevanje, komunikaciju onih koji rješavaju problem i samo rješavanje problema. U inženjerstvu i ekonomiji modeli služe za oblikovanje novih rješenja, ispitivanje svojstava rješenja, te izbor najpovoljnijeg rješenja. Modeliranje zamjenjuje eksperimentiranje “u živo” koje obično zahtjeva dosta vremena, ima veliku cijenu, ponavljanje eksperimenata je skupo, te može biti opasno. Modeliranje je umijeće, a ne znanost; zahtjeva zdrav razum, moć apstrakcije, sistematičnost i iskustvo. Treba se paziti kod izbora granica sustava s okolinom, stoga model treba obuhvatiti samo fenomene od interesa. Pretjerano složene i detaljne modele teško je razumijeti i vrednovati, dok pojednostavljeni modeli gube bitne elemente za objašnjavanje uzroka ponašanja. Preporuka je razvijati model u jednostavnim modulima s dobro definiranim funkcijama, što olakšava izgradnju i provjeru modela. Modeliranje procesa također ima svoj proces, tj. način pristupa modeliranju. Započinje se definicijom cilja modeliranja. Tu se uglavnom radi o upoznavanju rada i optimizaciji procesa. Nakon toga nužno je osvrnuti se na izvore podataka koji su korišteni pri modeliranju procesnog sustava. Uglavnom se tu radi o vremenskim projektnim planovima, promatranju značajki procesa, dokumentaciji opisa procesa i uloga, te iskustvenoj metodi, tj. uključenosti u sam proces. Za izgradnju simulacijskog modela koristi se određena tehnologija, za koju se smatra da će dati najbolje rezultate pri određenom uloženom vremenu i trudu. U tu svrhu odabrane su obojene Petrijeve mreže, budući je njima moguće hijerarhijski opisati najzahtjevnije procese, dekomponirajući sustav procesa do željene razine. U izgradnju modela uključuju se sintaksna provjera, planiranje i izvođenje simulacijskih eksperimenata, te traženja optimalnog slučaja za pojedine početne vrijednosti procesnih parametara [2], [7]. Cilj modeliranja nekog poslovnog procesa i njegove simulacije, svodi se na upoznavanje rada sustava, poboljšanje performansi sustava i smanjenje troškova sustava. Međutim, primarni cilj ovog rada jest pristup zadatku modeliranja i simulacije složenih poslovnih procesa koji se koriste za razvoj softvera u velikim industrijama. Problemi koji se javljaju kod opisa nekog procesnog sustava u razvoju softvera su nemogućnost definiranja i mjerenja pojedinih faza, koje su uglavnom vezane uz ljudsku mentalnu kreativnost. Stoga je cilj predložiti način na koji se može opisati kreativni ljudski proces stvaranja softvera. Jedan od ciljeva je i optimizacija resursa utrošenih za razvoj softverskog proizvoda, tj. način na koji se iz opisanog modela mogu dobiti pokazatelji koji utiču na dinamiku procesa i potrošnju resursa. Mora se napomenuti da je ovdje akcent na pristupu i načinu optimizacije, a ne na dobivanju stvarnih rezultata. Problem je pridobiti informacije iz složenog procesnog sustava, poput opisanog, međutim vrlo je lako doći do bitnih rezultata ukoliko raspolažemo detaljnim informacijama o samom procesu. 2.1.
Izvori podataka korišteni u modeliranju
Vjerovatno najteži i najzahtjevniji dio stvaranja simulacijskog modela jest prikupljanje podataka potrebnih za simulaciju nekog sustava, u ovom slučaju procesa za razvoj softvera. Nema kvalitetne simulacije bez kvalitetnih podataka kojima se može dosljedno opisati proces. Podaci se mogu prikupiti iz različitih izvora: projektno-procesne dokumentacije, promatranja i mjerenja procesa, rezultata mjerenja kvalitete proizvoda, prikupljanju osobnih iskustava članova procesnog tima i sl. Svaka ozbiljna tvrtka mora sadržavati detaljne projektne planove za razvoj svojih proizvoda i usluga. Poslovanje bez te osnove je nezamislivo, stoga izrada simulacijskog modela procesa za takav način poslovanje nema svrhe. Drugim riječima, tvrtka bi morala imati razinu organizacije koja odgovara bar 3. razini CMMI modela. Na temelju dokumenta opisa procesa (engl. Process Description) definira se gruba struktura procesa i
6. HRVATSKA KONFERENCIJA O KVALITETI – OPATIJA, 18.-20. 05. 2005.
tokovi radnji koje moraju biti obavljene. Projektni plan sadrži podatak o gruboj dinamici tih tokova, stoga početna razina modela može biti definirana. Međutim, to još uvijek nije dovoljno za precizno modeliranje [5]. Proces, iako definiran, ima svoje značajke, bitno različite od teoretskog opisa. Te značajke često izlaze izvan mogućnosti mjerenja i zadiru u psihologiju tima i pojedinca. Drugim riječima, praksa primjene procesa je vrlo bitna u modeliranju. Ponekad nije moguće opisati neko radno mjesto skupom akcija, pa se značajka takvog radnog mjesta može izraziti statistički u odnosu na pojedinu fazu, bilo to u količini potrošenog vremena, ili postignutoj normi proizvodnje. U procesima kao što je razvoj softvera, nemoguće je izvršiti bilo kakva mjerenja količine posla, kao što bi to bio slučaj u ostaloj proizvodnji poput tekstilne, prehrambene ili na primjer metalne industrije. Posao u softverskoj industriji je striktno mentalne prirode i nemjerljiv je nekom pouzdanom metodom. Stoga se pribjegava promatranju i statistici gdje je ona god moguća. Dokumenti opisa procesa i procesnih uloga, ako postoje u tvrtci, nerazdvojivi su jedni od drugih. Pretpostavka je da se tvrtka, koja se bavi razvojem softvera, nalazi bar na toj razini organizacije da definira svoje procese i radne uloge, te ih uredno dokumentira, promatra i mjeri. Bez tih osnovnih stvari teško je ili čak nemoguće stvarati kvalitetan softver, pogotovo ako je riječ o višemjesečnom ili višegodišnjem razvoju. Prije bilo kakvog mjerenja na terenu preporuka je da se dobro prouče svi procesni i projektni dokumenti, zatim da se napravi skica modela i onda se ide u daljnju dekompoziciju aktivnosti, za koje će vjerovatno biti potrebno opsežnije mjerenje ili promatranje. Iskustvo i primjena u praksi definiranih procesa je od najveće važnosti za istinitost simulacije nekog modela kojeg se opisuje. Empirijska komponenta daje živost procesu, stoga iskusno procesno rukovodstvo posjeduje znanje o adaptaciji procesa u svakom času i tailorira procese prema potrebi u danom trenutku. To znanje, koje ne može biti izraženo formulom, obuhvaćeno mjerenjem, niti definirano riječima je upravo empirijsko znanje. Dakle, nemoguće je detaljno modelirati bilo koji proces, ako nisi uključen u njega svojom pažnjom ili radnom aktivnošću. To je temeljni teorem ispravnog modeliranja poslovnih procesa. Rezultati istraživanja pokazuju da eksperti za modeliranje: modele razvijaju tijekom dužeg vremena, intenzivno kontaktiraju s klijentima, koriste analogije i crteže, razvijaju više alternativnih modela, uvijek kreću od malog modela i proširuju ga, 15% vremena troše na razmišljanje o kontekstu problema i njegovo razumijevanje, 60% vremena troše na razvoj strukture modela i analizu podataka, 15% vremena troše na vrednovanje modela, procjenu korisnosti i prihvatljivosti za klijenta, a 10% vremena troše na procjenu parametara i računanje rezultata pomoću modela. 2.2.
Model poslovnog procesa razvoja softvera (MRPS)
Kompleksnost razvoja telekomunikacijskog softvera zahtjeva složenu projektnu organizaciju s akcentom na efikasne projektne procese i tokove dokumenata. Najkraća definicija svakog razvojnog procesa softvera, može se svesti na četiri faze: analizu, dizajn, testiranje i isporuku, Slika 1. Prva faza naziva se analiza i započinje zahtjevom kao ulaznim dokumentom, koji se sastoji od što točnije definiranih zahtjeva kupca za kojeg se SW proizvod razvija. Početak prve faze označen je mjestom kontrole MK0. Faza analize završava u točki odluke TO2 gdje se na temelju rezultata analize zahtjeva, proračuna troškova resursa i zaključaka sistemske studije, mora donijeti odluka da li se kreće u daljnji razvoj proizvoda ili se odustaje od istog. U slučaju da je odobren nastavak razvoja SW proizvoda, započinje faza SW dizajna u kojoj se vrše daljnje analize i dekomponiranja funkcionalnosti. Funkcionalnosti su podijeljene na programske jedinice koje se nazivaju blokovi ili moduli. Svaki modul tvori svojevrsnu zasebnu cjelinu koja je definirana podfunkcijama. Faza SW dizajna završava kodiranjem funkcionalnosti i jednostavnim, osnovnim testom. Nakon MK3, započinje faza funkcijskog testa u kojem se blokovi podvrgavaju ispitivanju u simuliranoj funkcijskoj okolini. Uz SW obično se razvija i hardver (HW), stoga je u tom slučaju potrebno izvršiti i zasebno testiranje
6. HRVATSKA KONFERENCIJA O KVALITETI – OPATIJA, 18.-20. 05. 2005.
hardvera. Nakon što su i SW i HW istestirani, priskače se sistemskom testu, gdje je testirana cjelina koju čini i HW i SW. Slika 1: Četiri osnovne faze MRPS-a i organizacijska struktura projektnog tima PR O JEK T PRAO M EN DJEK ŽE RT M E N AD ŽE R
Zatvaranje projekta: analize i raporti
S IS TE M IS IS T EM ANSAL T AN AL IS T
T E S T I R A NJ E
TO4
TO2
M EN A D ŽE R M ELITE N ADTŽE K VA ER K V ALITE T E
K O N F IG U R A KCOIJSK N FIGI U R A IJSK I M ENC AD Ž ER M EN AD Ž ER
Početak faze ISPORUKE
AR H IT EK T A R H IT EK T
T E ST TE ŽE ST R M E N AD M E N AD Ž ER
D IZ AJN ER I D IZ AJN E R I
IZVRŠNI TIMOVI
Početak faze TESTIRANJA
DIZAJN
T ES T ER I T E ST E R I
MK3
Donošenje odluke: Početak DIZAJNA
H AR D V ER AR D VRER INH ŽE N JE IN Ž EN JE R
PROJEKTNO RUKOVODSTVO
ISPORUKA
ANALIZA
Ulazni dokument: ZAHTJEV
TO5
UPRAVLJAČKA STRUKTURA
Proizvod MK0
Točka odluke TO4 nagovještava završetak faze testiranja u kojoj je sustav manje ili više istestiran. U fazi isporuke vrše se završne radnje poput pakiranja proizvoda, uputstava za upotrebu i raporti kvalitete istog, završno s TO5. Svaka faza u razvoju SW-a sastoji se od podprocesa, Slika 2, koji mogu slijediti jedan za drugim, tvoreći fazu kao cjelinu, ili mogu biti izvršavani paralelno u nekim dijelovima vremena [3].
MK3
MK2
ANALIZA Analiza zahtjeva
Sistem studija
DIZAJN
Sistem Analiza
Podjela zadatka
Modul dizajn
Kodiranje
T E S T I R A NJ E Podjela zadatka
Test
ISPORUKA
Ispravak grešaka
Instalacija i pakiranje proizvoda
Pisanje uputa i inspekcije
TO4
TO3
Osnovni test
TO2
TO1
TO0
Plan resursa
P R O I Z V O D
Pisanje raporta kvalitete
Sistem test
TO5
MK1
MK0
Slika 2: Procesne faze razvojnog procesa SW-a s pripadajućim podprocesima, točkama odluka (TO) imiljokazima, tj. mjestima kontrole (MK).
Svaki sustav zahtjeva određenu količinu energije uložene u njegovu organizaciju, kako bi mogao ispravno obavljati svoju funkciju. Stoga, ozbiljne kompanije ulažu velike napore u znanje ovladavanjem organizacijskim vještimana, među kojima je primarno rukovođenje timovima i definiranje optimalne organizacijske strukture. Projektni tim ima slojevitu organizacijsku strukturu. Takve strukture su nužne, kako bi se stvorio pouzdani proizvodni mehnizam potreban za realizaciju SW proizvoda iz početne ideje. Na Slici 1, također je prikazan jednostavni primjer organizacijske strukture, prikladan za opisani model razvojnog procesa softvera, koji se simulira. Gornji sloj je upravljačka struktura sačinjen od rukovoditelja koji se brinu za prirodni tok razvoja SW proizvoda i za održavanje procesnog mehanizma razvoja. Tim sadrži projektnog menadžera i menadžera kvalitete. Projektni menadžer stvara projektni tim, raspodjeljuje zadatake i planira dinamiku posla shodno dogovorenim rokovima. Drži se projektnog procesa i rukovoditi njegovim fazama. Menadžer
6. HRVATSKA KONFERENCIJA O KVALITETI – OPATIJA, 18.-20. 05. 2005.
kvalitete prati i predviđa kvalitetu proizvoda, održava i poboljšava proces razvoja. Slijedeću razinu čini tehničko projektno rukovodstvo koje se sastoji od ljudi odgovornih za tehničku realizaciju i razvoj SW-a. Njihova znanja, tehničke prirode, vezana su uz neku od specijaliziranih grana koje se pojavljuju u samom procesu razvoja, npr. dizajn, testiranje, hardver itd. Za razliku od upravljačke strukture, ne brinu oko samog toka projekta, već oko načina razvoja funkcionalnosti proizvoda. Sistem analist je osoba visokih tehničkih kompetencija i iskustava. Njegovo znanje mora biti onoliko široko koliko je to sam sustav koji se razvija. Njegov je zadatak analizirati zahtjeve kupca i na temelju njih predlagati rješenja budućeg informacijskog sustava, uključujući i HW i SW. Dokumenti za koje je sistem analist nadležan su HW i SW razada, uključujući i analizu zahtjeva. Tablica 1: Popis dokumenata, odgovornosti i pripadajućih procesa u različitim fazama MRPS-a (* koristi se samo kod procesne opcije velikog projekta)
DIZAJN
ANALIZA
FAZA
TEST ISPORUKA
Br 0 1 2 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
DOKUMENT
ODGOVORNOST
PODPROCES
Zahtjev Specifikacija Zahtjeva Sistamska Skica Softverska Razrada Hardverska Razrada Implementacija Softvera Implementacija Hardvera Test Analiza Projektni Plan Plan Kvalitete *Plan Rizika *Plan Mjerenja Konfiguracijski Plan Test Plan Hardverski Plan Funkcija Modula Opis Modula Test Lista Raport Pogrešaka Uputstvo Raport Kvalitete
naručitelj analizator sustava analizator sustava analizator sustava analizator sustava arhitekt hardver inženjer test menadžer projektni menadžer *menadžer kvalitete projektni menadžer menadžer kvalitete konfiguracijski mngr. test menadžer hardver inženjer dizajner dizajner tester tester dizajner *menadžer kvalitete
Analiza zahtjeva Analiza zahtjeva Analiza zahtjeva Sistemska studija Sistemska studija Sistemska analiza Sistemska analiza Sistemska analiza Planiranje resursa Planiranje resursa Planiranje resursa Planiranje resursa Planiranje resursa Podjela zadataka Podjela zadataka Modul dizajn Kodiranje Kodiranje Ispravak grešaka Pisanje uputa Raport kvalitete
Inspekcijom spomenutih dokumenata, daljnja analiza nastavlja se po granama, tj. arhitekt stvara implementacijsku skicu budućeg softvera, kao što HW inženjer isto čini s hardverskom komponentom. Dokumenti koji nastaju nazivaju se SW i HW implementacija i ustvari su prijedlog funkcionalnosti. Konfiguracijski menadžer priprema konfiguracijski plan, a test menadžer plan prema kojem će se odvijati testiranje. Teoretski, tad se može smatrati da je sustav dobro definiran i da može otpočeti faza dizajna. U fazi dizajna dizajnerski timovi preuzimaju dokumentaciju i na temelju nje analiziraju skupove funkcija i njihove zadaće. Paralelno s dizajnerskim timovima, test tim priprema test slučajeve kojima ispituje buduće funkcionalnosti. U svakom podprocesu nastaju određeni dokumenti za koje su odgovorne pojedine osobe razvojnog tima. Dokumentacija služi kao transfer znanja do otjelovljenja željenog SW proizvoda. Opisani razvojni proces koristi 22 različita projektna dokumenta, Tablica 1. U pojedinim slučajevima može se koristiti manji broj dokumenata, što je slučaj kod odabira opcije razvoja malih projekata. Također, mali projekti ne zahtjevaju neke od projektnih uloga, gdje izostavljanje pojedinih uloga prati i izostavljanje pridružene 6. HRVATSKA KONFERENCIJA O KVALITETI – OPATIJA, 18.-20. 05. 2005.
dokumentacije. Takve promjene procesa ili prilagođavanja su česta pojava u kvalitetnim organizacijama, jer se na taj način vrši ušteda vremena i resursa, bez pada kvalitete proizvoda.
MK3
MK2
MK1
MK0
Slika 3: Raspodjela projektne dokumentacije prema fazama i pripadnosti: SW, HW, test i projektna dokumentacija Kao što se vidi iz Tablice 1 i Slike 3, opisani MRPS koristi 22 različita dokumenta. U pojedinim slučajevima može se koristiti i HARDVERSKA DOKUMENTACIJA manji broj dokumenata, na primjer kod malih projekata, neke dokumente nije potrebno pisati. TEST DOKUMENTACIJA Mali projekti ne zahtjevaju neke od projektnih uloga, kao što je u ovom slučaju menadžer kvalitete. U tom slučaju, posao menadžera kvalitete PROJEKTNA DOKUMENTACIJA može preuzeti projektni menadžer, dok dokumenti kao što su plan mjerenja i plan rizika nastoje se obraditi dodatnim poglavljima u projektnom planu. Takve promjene procesa ili prilagođavanja (engl. process tailoring) su česta pojava u kvalitetnim organizacijama, jer se na taj način vrši ušteda vremena i resursa bez pada kvalitete proizvoda. Dokumenti se pišu prema točno utvrđenim pravilima pisanja, koja su definirana u procesnim dokumentima zaduženim za njihovu definiciju (engl. document instruction). Osim tih procesnih dokumenata postoje i dokumenti koji definiraju procese (engl. process description) i dokumenti kojima se pridaju zadaci pojedinoj projektnoj ili procesnoj ulozi (engl. role description, work instruction). Da bi se zadržala jednostavnost opisanog modela procesa kojeg treba simulirati, takvi dokumenti neće biti dijelovi njegove strukture, već se smatra da su oni definirani prema nekoj od normi, na primjer skupini normi ISO 9000. Specifik. Zahtjeva
Softverska Razrada
Implement acija Softvera
Funkcija Modula
Sistemska skica
Hardver. Razrada
Implement acija Hardvera
Hardevrski Plan
Test Analiza
Test Plan
3.
*Plan Kvalitete
Plan Kvalitete
Konfigur. Plan
Uputstvo (startanje)
Test Lista
Raport Pogrešaka
Uputstvo (kraj)
Raport Kvalitete
TO5
*Plan Rizika
Opis Modula
TO4
Projektni plan
TO2
* samo kod opcije: VELIKI PROJEKT
*Plan Mjerenja
TO1
TO0
Zahtjev
DOKUMENTACIJA
TO3
SOFTVERSKA
SIMULACIJA I OPTIMIZACIJA OBOJENIM PETRIJEVIM MREŽAMA
Petrijeve mreže su grafičko i matematičko pomagalo za modeliranje primjenjivo na različite vrste sustava. To je formalni jezik prikladan za modeliranje konkurentnih sustava i sustava s dijeljenjem resursa (engl. resource sharing), model s kojim se uspješno predočuje statičko, dinamičko i intervalno vremensko znanje. Petrijevu mrežu čini struktura mjesta i prijelaza. Mjesta imaju značenje uvjeta, a prijelazi imaju značenje događaja. Prijelazi su definirani kao sustav uvjeta i događaja, gdje uvjet treba biti zadovoljen kako bi se izveo neki događaj. Treći element mreže čine oznake (engl. token). Oznake postavljene u nekom mjestu označuju ispunjenje uvjeta kojeg to mjesto označava. Grane (engl. arc), kojima su mjesta i prijelazi povezani, sačinjavaju četvrti element mreže. Grane imaju svoj smjer i svoju težinu ili propusnost. O težini grane ovisi koliko oznaka istodobno može propustiti oznaka. Obojene Petrijeve mreže su grafički orijentiran jezik pogodan za specifikaciju, simulaciju i verifikaciju sustava. Naročito su prikladne za sustave koji se sastoje od brojnih paralelnih procesa koji međusobno komuniciraju. Tipičan primjer primjene su područja komunikacijskih protokola, distribuiranih sustava, automatiziranih proizvodnih sustava, analize tokova poslovanja i tehnologije razvoja čipova. Obojene Petrijeve mreže (engl. CPNs) je jezik za modeliranje razvijen za sustave u kojima komunikacija, konkurentnost i dijeljenje resursa igraju važnu ulogu. CPN kombiniraju snagu običnih Petrijevih mreža sa snagom programabilnih jezika 6. HRVATSKA KONFERENCIJA O KVALITETI – OPATIJA, 18.-20. 05. 2005.
visoke razine. Petrijeve mreže omogućavaju opisivanje procesnog međudjelovanja, dok programski jezik omogućava definiranje tipova podataka i rukovanje njihovim vrijednostima. Obojene Pertijeve mreže razvijene su kao skup softverskih pomagala nazvanih CPN pomagala (engl. CPN Tools), danas korištene1 u najzahtjevnijim paralelnim sustavima za modeliranje i simulaciju, u vojne, medicinske i poslovne svrhe [6], [7]. Slika 4: Prikaz nekoliko mreža iz CPN modela: mreža 1. razine (PROCES), mreža 2. razine(DIZAJN), dvije mreže 3. razine iz podprocesa analize(PR) i dizajna (KD)
Zadatak simulacijskih mjerenja bio je pronaći optimum ljudskih resursa za obavljanje poslova na razvoju proizvoda unutar određenog vremena u određenim financijskim okvirima. Uz promnalaženje glavnog optimuma poslovanja, dodatna zadaća je iznalaženje alternativnih optimuma poslovanja, npr. kao što je razvoj SW-a u najkraćem mogućem vremenskom roku uz dopušteno odstupanje u troškovima ili s najmanjim mogućim troškovima uz dopušteno odstupanje u vremenu razvoja. Model je razvijen hijerarhijski i sastoji se od 19 mreža poredanih u tri razine: procesna razina kao najviša, podprocesna međurazina i operativna razina kao najniža, Slika 4. Svaki niži sloj je skup podmreža sloja iznad. Simulacijska mjerenja sastojala su se od istovrsnih simulacija s različitim početnim uvjetima naznačenim preko deklarativnog sektora modela, a očituju se u razlici broja članova projektnog tima. 1
CPN pomagalo koriste brojni sustavi: US Air Force, Missile Australian Simulator & Operational Planning, Nuclear Waste Management Programme (US), Naval Command and Control System in Canada, European Train Control System, Model Train System at University of Kiel, Flowmeter System at Danfoss, Traffic Signals in Brazil, Chemical Production in Germany, Peugeot-Citroën, Nokia, Hewlett-Packard, Bang & Olufsen, Deutsche Telekom, Telstra Research Laboratories, Allocation Policies in the Fieldbus Protocol in Japan, Network Management System at RC International, Hungarian Academy of Science, Document Storage System at Bull, Electronic Funds Transfer (US), Security and Access Control Systems at Dalcotech, Computer Simulation of Biochemical Processes, Bank Courier Network at Shawmut National Coop, VLSI Chip in the US i mnogi drugi.
6. HRVATSKA KONFERENCIJA O KVALITETI – OPATIJA, 18.-20. 05. 2005.
Izabran je projektni zadatak definiran preko vrijednosti koje su pridružene deklaracijama ulaznih varijabli. Ulazne varijable sustava su: varijable projektne specifikacije, vremenske varijable za pojedinu procesnu fazu, varijable ljudskih resursa, varijable projektne dokumentacije i pomoćne varijable modela. Izlazne varijable sadrže vrijednosti vremena koje je potrošeno za pisanje dokumenata, izvršenje određene faze ili radnu opterećenost svake pojedine procesne uloge. Projektni zadatak sadržavao je slijedeće zadaće: vrijeme potrebno za razvoj gotovog SW-a ne smije prijeći 2000 h (sati), što je ekvivalent vremenskom razdoblju od godine dana (nužni uvjet); cijena ne smije prijeći vrijednost od 40000 mh, tj. utrošenih radnih sati (dovoljni uvjet); potrebno je odabrati izabrati optimalni slučaj s obzirom na što što manju količinu ljudskog resursa, te cijenu i vrijeme trajanja razvoja. Slika 5: Vrijeme potrebno za razvoj SW proizvoda, ovisno o broju dizajnera i broju testera kao parametru prikazano parametriziranim krivuljama i plohom 3-D grafa 5000 4500
vrijeme
4000 4000
3500 3000 2500 2000
2000
1500
1
dizajneri
1000 3
4
5
6
7
8
9
10
11
4
12
7
2000-4000 0 0-2000
10
Poduzeto je 100 različitih simulacijskih mjerenja u kojima su mijenjane vrijednosti ulaznih varijabli izvršnih timova, tj. broj dizajnera i testera. Zbroju testera i dizajnera dodan je broj ostatka članova razvojnog tima, da bi se dobio ukupan broj ljudi koji rade na razvoju SW proizvoda. Mjerenja su grupirana u 10 različitih podskupina od 10 mjerenja, što je definirano brojem članova tima za testiranje kao parametrom grupe. Svaka krivulja je pridružena određenom broju testera, počevši odozgo s brojem od 2 testera. Nakon završetka svake pojedine simulacije, u slijedećem redu zabilježen je broj radnih sati, tj. efektivni vremenski interval koji je protekao do završetka razvoja. Slika 6: Prikaz troškova razvoja SW proizvoda u dvije i tri dimenzije 2 TES 3 TES 4 TES 5 TES 6 TES 7 TES 8 TES 9 TES 10 TES
75000 70000
60000 55000 50000 45000
40000
40000
1
0 5
3
dizajneri 3 4 5 6 7 8 9 10 11 12
7
35000
9
radni sati
65000
80000
40000-80000 0-40000
6. HRVATSKA KONFERENCIJA O KVALITETI – OPATIJA, 18.-20. 05. 2005.
Taj iznos je efektivno vrijeme potrebno za razvoj, pomnoženo s brojem članova razvojnog tima, daje cijena troška razvoja proizvoda u radnim satima. Kao što je vidljivo iz Slike 5 samo pojedine krivulje u određenim dijelovima grafa zadovoljavaju vremenski uvjet vremena razvoja, koje ne smije prijeći vrijednost od 2000 sati. Ta područja zadovoljavaju nužan uvjet proizvodnje, ali ne i dovoljan. Dovoljan uvjet je taj da utrošena sredstva ne smiju premašiti dogovorenu vrijednost od 40000 radnih sati, Slika 6. Mali odsječci pojedinih funkcija zadovoljavaju dovoljni uvjet proizvodnje, tj. da troškovi ne prelaze 40000 radnih sati, što je lakše dočarati 3-D grafom prikazanim na Slici 6. Razmatranjem rezultata simulacije, zapaženi su minimumi koji bi mogli zadovoljavati uvjet optimuma: najkraće razvojno vrijeme iznosi 1323 h, s cijenom koštanja 39690 mh i timom od 30 ljudi; najmanja cijena je 37775 mh gdje tim od 25 ljudi razvije proizvod za 1511 h; povoljni rezultat je i 26 ljudi, 1453 h, 37778 mh. Nakon pronalaženja optimalnog slučaja, dobivenog simulacijom razvojnog procesa, moguće je iz daljnje analize Petrijevog modela dobiti podatke o opterećenosti ljudskih resursa, tj. procijeniti koliko će pojedina projektna uloga imati vremenskog učešća u razvoju proizvoda, kao i graf dinamike potrošnje vremenskog resursa, prikazano na Slici 7. Slika 7: Radno opterećenje po članu projektnig tima u optimalnom slučaju razvoja proizvoda i dinamika potrošnje vremenskog resursa od projektne točke do točke 600,4
DIZ
1600 1400 1200 1000 800 600 400 200 0
691,7 83 126
200
300
400 500 radni sati
600
700
vo
d
5 TO
4
800
o iz
100
Pr
0
TO
M
K1
333
K3
SAN
3
281
M
PRM
2
105
TO
ARH
TO
319
K2
103
TSM
1
HRI
v rije m e [h ]
MKV
M
KNF
TO
TES
Također, dobiva se i podatak opterećenja projektnog tima ukoliko se radi o više uzastopnih ili paralelnih razvojnih projekata, gdje postoji mogućnost da se ljudski resursi raspodjeljuju prema potrebi u druge projekte za vrijeme dužih perioda stagnacije pojedinih članova tima. Time se, ukupno u konačnici, drastično smanjuje cijena po projektu, upravo zato što ljudski resurs biva potpuno iskorišten unutar njegovog 40-satnog radnog tjedna. 4. ZAKLJUČAK Bilo koji poslovni proces može biti simuliran ovim načinom, bez obzira na granu industrije u kojoj se koristi. Više procesa neke složene organizacije može biti opisano na taj način i spojeno u jedan kompleksni i cjeloviti simulacijski model, koji može predstavljati cijelu organizaciju i ciklus proizvodnje, uključujući i ljudsko ponašanje u različitim okolnostima [1]. Matematička simulacija poslovnog procesa može uveliko odstupati od realnih rezultata koji bi se pojavili u praksi, jer je teško predvidjeti ljudsko ponašanje. Ono sastoji od brojnih komponenti, fizičke, mentalne i duševne prirode, koje je nemoguće ili teško ukomponirati u simulacijske modele. Svaki pojedinac je individua za sebe, drugačije reagira na različite uvjete. Sve te različite individualne volje sačinjavaju jedinstven tim kojemu je zajednička jedino grupna dinamika, koja predstavlja rezultantu tih pojedinačnih stremljenja i aktivnosti. Upravo akcent proučavanja i mjerenja trebala bi biti ta grupna dinamika, koja se mora
6. HRVATSKA KONFERENCIJA O KVALITETI – OPATIJA, 18.-20. 05. 2005.
promatrati i pratiti iz projekta u projekt, po mogućnosti bez fluktuacije ljudskih resursa unutar timova, kako bi timovi nakon nekog vremena postali uigraniji, a time i otkrili svoje kauzalnosti djelovanja i stvaranja. Potrebno je koristiti sva moguća znanja, kako iz matematike i statistike, tako i iz ostalih područja poput psihologije, medicine, biologije i sl. Na taj način lakše će se moći dekomponirati i modelirati one najniže operativne razine simulacijskih modela, kako bi isti poprimili predikcijske karakteristike. Opisivanje i predviđanje grupne dinamike razvojnih timova bit će i u budućim vremenima velik izazov, koji će zahtjevati puno više i jače kompetencije zbog kompleksnosti ljudskog bića i njegovog kreativnog rada. Timovi stručnjaka s područja osiguranja kvalitete i koordinacije procesa, za svaki projekt će izvoditi temeljite procjene proizvoda i procesa koji ga moraju stvoriti. Proces će stvarati proizvod, a u stvaranju proizvoda nastajati će proces u rekurzivnom nastojanju da se postigne što veća kvaliteta. Diktat budućnosti i tehnologije stvarat će sve veće i složenije poslovno-proizvodne sustave, u kojima će ljudski faktor odlučivanja igrat presudnu ulogu. Složenost tih sustava zahtjevat će pomoćne tehnologije kojima je moguće donositi pravovremene odluke s ciljem održavanja kvalitete i poboljšanja sustava. Dakle, budućnost će zahtijevati da analize proizvodnih sustava obuhvaćaju i psiho-sociološke parametre timova i pojedinca, stvarajući tako sistemski pristup upravljanja, putem simulacije velikih proizvodnih sistema. Smjernice daljnjeg napretka, kako proizvodnje tako i društva u cjelini, treba tražiti u održivom razvoju, tj. skrbi pojedinaca, institucija i firmi u održivim rješenjima koja pokušavaju održati krhku ravnotežu između ekonomije, društva i ekologije [4]. Filozofija profita nije rješenje budućeg ljudskog napretka. Oni koji prvi shvate cjelovitost znanja i nužnost sistemskog pristupa, shvatit će da daljnji napredak nauke i društva može ovisiti o pomagalima koji će ljudima davati bolji uvid u statička i dinamička svojstva proizvodnih procesa, ali stavljanjem čovjeka u prvi plan ispred profita kroz održivi razvoj. Ne treba robovati standardima, već se koncentrirati na poslovnu efikasnost, okoliš i napredak ljudske zajednice. Omogućiti protok informacija kroz sve slojeve uprave i poduzeća i iskoristiti to u sistemskom pristupu koji podržava takav trend. Time bi moglo doći i do promjene u društveno proizvodnim odnosima tržišta koje bi imalo neke druge smjernice možda humanije za čovjeka i njegov um kao osnovno oruđe proizvodnje. Konkurentnost treba tražiti u promjeni ljudskih vrijednosti, zakona i normi u smjeru ljudskog napretka, očuvanja okoliša i cjelokupnog zadovoljstva, gdje je postepeno uništenje potrošačkig mentaliteta i profitne utrke, budućnost koja će osigurati kvalitetniji suživot s prirodom kroz kvalitetne i sigurne proizvode koji prate ljudski razvoj na svim razinama. LITERATURA [1]
[2] [3] [4]
[5] [6] [7]
G. Topić and D. Jevtić, Process Measuring and Monitoring in Multi-Process Industry Using Petri Nets Technology In Accordance with ISO 9000:2000, Proceedings of the 10th International Conference on Software, Telecommunications and Computer Networks - SoftCOM 2002, pp. 35-39, Split, Venice, Ancona, Dubrovnik, Croatia, 2002. V. Čerić, Međunarodni poslijediplomski studij poslovnog upravljanja (MBA), kolegij: Upravljanje proizvodnjom i uslugama, ljetni semestar 2002/2003, http://oliver.efzg.hr/~vlceric/mba-upu/mba-upu.html A. Carić, Istraživanje i razvoj u informacijskoj komunikacijskoj tehnologiji, 1. izdanje, Element, Zagreb 2003. Hrvatski poslovni savjet za održivi razvoj – HRPSOR, Poslovni svijet u održivom razvoju: Ususret Svjetskom skupu u Johannesburgu 2002 i nakon toga, World Business Council for Suitable Development, ISBN 953-98964-0-1 CPN Tools for Coloured Petri Nets - Help, CPN Group, University of Aarhus, Denmark, http://wiki.daimi.au.dk:8000/cpntools-help CP Net Fundamentals – Design/CPN Tutorial for the Macintosh, CPN Group, University of Aarhus, Denmark, http://wiki.daimi.au.dk:8000/cpntools-help V. Čerić, Dodiplomski studij ekonomije, kolegij: Modeliranje primjenom računala u poslovnoj ekonomiji, ljetni semestar, 2003/2004, http://oliver.efzg.hr/~vlceric/mprpe/mprpe.html
6. HRVATSKA KONFERENCIJA O KVALITETI – OPATIJA, 18.-20. 05. 2005.
BUSINESS PROCESS MODELING AND RESOURCE OPTIMISATION BY TECHNOLOGY OF COLOURED PETRI NETS
Summary Many industries have very complex and demanding, business and production processes. In any case, either business and production processes demand creation of optimal time plan in specific starting condition. This article shows how to get process knowledge usable for optimization business activities and recourses. For that case, Coloured Petri Nets (CPN) are used for modeling, simulating and optimization of the resources, for the sake of time and costs predicting, needful for developing of software product in specific starting condition. In the article is explained and optimized basic software development process. Key words: process modeling and simulation, software development process, resource optimization, coloured Petri nets
6. HRVATSKA KONFERENCIJA O KVALITETI – OPATIJA, 18.-20. 05. 2005.