OPTIMIZACIJA POSLOVNIH PROCESOV Z UPORABO SIMULACIJ

Transcription

1 Gregor Drevenšek OPTIMIZACIJA POSLOVNIH PROCESOV Z UPORABO SIMULACIJ Diplomsko delo Maribor, december 2011

2 i Diplomsko delo visokošolskega strokovnega študijskega programa OPTIMIZACIJA POSLOVNIH PROCESOV Z UPORABO SIMULACIJ Študent: Gregor Drevenšek Študijski program: VS ŠP - Računalništvo in informatika Smer: Informatika Mentor: izr. prof. dr. Aleš Živkovič Maribor, december 2011

3 ii

4 iii ZAHVALA Iskreno se zahvaljujem mentorju, izr. prof. dr. Alešu Živkoviču, za potrpežljivost, strokovno pomoč, nasvete in vso podporo pri izdelavi diplomskega dela. Iskrena zahvala gre tudi dragima staršema, ki sta mi študij omogočila, me ves čas podpirala in mi stala ob strani. Zahvalil bi se tudi sestri za vse nasvete in njeno takojšnjo pomoč, kadar sem jo potreboval.

5 iv OPTIMIZACIJA POSLOVNIH PROCESOV Z UPORABO SIMULACIJ Ključne besede: optimizacija poslovnih procesov, Oracle BPA, BPMN UDK: :004.43(043.2) Povzetek: Diplomsko delo predstavlja, kako s pomočjo simulacij prenoviti (optimizirati) poslovne procese. Za modeliranje in optimiziranje poslovnih procesov je uporabljen program Oracle BPA. Modeliranje je prikazano z notacijo BPMN, katera je tudi opisana. Opisani so tudi poslovni procesi in orodje Oracle BPA. Optimiziranje je opisano, ter izvedeno s pomočjo simulatorja v orodju Oracle BPA.

6 v BUSINESS PROCESS OPTIMIZATION USING SIMULATIONS Key words: business processes optimization, Oracle BPA, BPMN UDK: :004.43(043.2) Abstract: Degree represents how with simulator optimize business process. For modelling and business processes is used program Oracle BPA. Modelling is demonstrated with notation BPMN, which is described. Described are also business processes in tools Oracle BPA. Renovate is described and also performed with the help of simulator in the tools Oracle BPA.

7 Kazalo 1 UVOD POSLOVNI PROCESI Modeliranje poslovnih procesov Simuliranje poslovnih procesov Implementacija poslovnih procesov Izvajanje poslovnih procesov Spremljanje poslovnih procesov Optimizacija poslovnih procesov NOTACIJA BPMN [3] Dogodki Aktivnosti Prehodi, odločitve Izdelki Pasovi, povezave OGRODJE ITIL ORODJE ORACLE BPA Primer modeliranja procesa Simuliranje procesa Izvajanje simulacij Optimiziranje procesa z vključitvijo dobrih praks ITIL Izvajanje simulacij ZAKLJUČEK LITERATURA... 47

8 Kazalo slik Slika 2.1: Življenjski cikel poslovnega procesa [5]... 3 Slika 3.1: Elementi ki sestavljajo notacijo BPMN... 8 Slika 3.2: Vrste dogodkov [povzeto po BPMN poster] Slika 3.3: Vrste tokov [povzeto po BPMN poster] Slika 3.4: Katere elemente lahko med seboj povežemo s tokom zaporedja [BPMN poster] Slika 3.5: Katere elemente lahko med seboj povežemo s tokom sporočil [BPMN poster] Slika 4.1: Lokalni storitveni center [povzeto po ITIL V3, Service Operation] Slika 4.2: Centralni storitveni center [povzeto po ITIL V3, Service Operation] Slika 4.3: Virtualni storitveni center [povzeto po ITIL V3, Service Operation] Slika 5.1: Osnovni pogled na Oracle BPA Slika 5.2: Proces: Prijava napake 1/ Slika 5.3: Proces: Prijava napake 2/ Slika 5.4: Znak za podrobnejši pogled aktivnosti Slika 5.5: Proces: Odprava napake Slika 5.6: Oracle BPA simulator Slika 5.7: Enakomerna porazdelitev Slika 5.8: Normalna porazdelitev Slika 5.9: Logaritemsko normalna porazdelitev Slika 5.10: Eksponentna porazdelitev Slika 5.11: Trikotna porazdelitev Slika 5.12: Porazdelitev gama Slika 5.13: Rezultati simulacije: Prijava napake 1/ Slika 5.14: Rezultati simulacije: Prijava napake 2/ Slika 5.15: Rezultati simulacije: Odprava napake Slika 5.16: Optimiziran proces: Prijava napake 1/ Slika 5.17: Optimiziran proces: Prijava napake 2/ Slika 5.18: Optimiziran proces: Odprava napake Slika 5.19: Rezultati simulacije optimiziranega procesa: Prijava napake 1/ Slika 5.20: Rezultati simulacije optimiziranega procesa: Prijava napake 2/ Slika 5.21: Rezultati simulacije optimiziranega procesa: Odprava napake Slika 5.22: Stolpčni diagram Slika 5.23: Linijski diagram Slika 5.24: Tortni diagram Slika 5.25: Podatki v XML obliki Slika 5.26: Podatki v CSV obliki Slika 5.27: Podatki v CSV obliki, uvoženi v program za njihovo obdelavo... 45

9 Stran 1 1 UVOD Podjetja želijo ustvariti čim večji dobiček s čim manjšimi stroški, zato se vedno bolj zavedajo pomembnosti načrtovanja in kasneje tudi prenove poslovnih procesov. Načrtovanje je pomembno, saj proces tako najlažje optimiziramo. Manjše procese bi lahko optimizirali tudi brez načrtovanja. Pri večjih procesih, v katerih sodeluje več organizacijskih enot, pa to ni mogoče. Eden izmed učinkovitih pristopov je modeliranje poslovnih procesov. Da bi prikazali delovanje v podjetjih, smo oblikovali proces. Le-tega smo nato simulirali, in na podlagi rezultatov simulacije smo proces kasneje optimizirali. Lotili smo se treh korakov v življenjskem ciklu poslovnega procesa. Ti so modeliranje, simuliranje in prenova. V naslednjih točkah so opisani poslovni procesi in njihov življenjski cikel. Predstavljena je notacija BPMN, s katero smo načrtovali poslovni proces, ki je uporabljen v praktičnem delu. Na kratko je predstavljeno orodje Oracle BPA. Opisana so priporočila ITIL, ki so povezana s procesom. Prikazan je proces, ki je modeliran in simuliran s tem orodjem. V nekaj korakih je prikazano, kako smo optimizirali proces z vključitvijo dobrih praks iz priporočil ITIL in s tem povečali njegovo učinkovitost.

10 Stran 2 2 POSLOVNI PROCESI Poslovne procese modeliramo z namenom: zaznavanja neučinkovitosti, lažjega uvajanja na novo zaposlenih, povečanja produktivnost in zmanjšanja stroškov. Vendar pa se v organizacijah soočajo s težavami, da model ne prikazuje dejanskega stanja v organizaciji, ampak je zastarel. Ponavadi ti modeli niso javno dostopni, ampak obležijo kje v pisarniških predalih. V teh primerih nam modeliranje nič ne pomaga, saj modelov kasneje nismo uporabljali in je bilo celotno modeliranje zgolj nepotreben strošek. Organizacije, ki pa modele s pridom uporabljajo, se kljub vsemu soočajo z določenimi težavami. Zaradi sprememb na trgu je potrebno poslovne procese pogosto spreminjati in prilagajati novim zahtevam. S širjenjem poslovanja organizacije, se poveča število procesov, kar pa je vzrok za slabše poznavanje le-teh. Zaradi kompleksnosti procesov se zgodi nepoznavanje procesov in manjša fleksibilnost. Do nepoznavanja poslovnih procesov ponavadi pride, ker organizacija nima izdelanih ustreznih poslovnih modelov, ali pa ti niso posodobljeni in ne predstavljajo trenutnega stanja v organizaciji. Posledica naštetih težav je neučinkovitost in predstavlja glavni problem pri obvladovanju procesov. [5] Da lahko obvladujemo poslovni proces, moramo poznati njegov življenjski cikel. Faze procesa so: modeliranje, simuliranje, implementacija, izvajanje, spremljanje in

11 Stran 3 optimiziranje. Začne se z modeliranjem, vendar ko zaključimo z optimiziranjem, se cikel ne konča, ampak se ponovno nadaljuje od začetka. Ker so v poslovnih procesih vedno neke spremembe, težko rečemo, da se model procesa zaključi in se ne bo nikoli več spreminjal. Slika 2.1: Življenjski cikel poslovnega procesa [5] 2.1 Modeliranje poslovnih procesov Glavni namen modeliranja je prenos trenutnih poslovnih zahtev v model poslovnega procesa. Preden začnemo modelirati, moramo izbrati skupino, ki bo modelirala procese in notacijo, po kateri bomo modelirali. Pri modeliranju je potrebno paziti, da modeliramo samo trenutno stanje. Trenutno je zelo razširjen standard BPMN, saj je pregleden, razumljiv nestrokovnjakom, podpira ga večina orodij za modeliranje in ker nekatera orodja že omogočajo avtomatsko pretvorbo modela BPMN v izvršljivo obliko. Procese, ki so kompleksnejši, je potrebno razbiti na pod-procese, da so razumljivejši. Z modeliranjem veliko pridobimo, saj se natančneje določijo odgovornosti, ugotovi se obremenjenost virov, ter lažje odkrivanje in odpravljanje ozkih grl.[5]

12 Stran Simuliranje poslovnih procesov Ko končamo z modeliranjem, se lotimo naslednjega koraka skladno z življenjskim ciklom prenove poslovnih procesov, in to je simuliranje procesa. Simulacije se uporabljajo za preizkušanje in boljše razumevanje kompleksnih procesov. Z njimi ugotavljamo odvečne aktivnosti v procesih in merimo učinkovitost izvajanja procesa glede na različna merila. Le-ta nam omogočajo boljše razumevanje izvajanja procesov in nudijo priložnost za izboljšave. Pripraviti si moramo scenarije za simuliranje. Simulacije izvaja oseba, ki dobro pozna poslovni proces. V pomoč so tudi orodja za simuliranje procesov, saj zelo pospešijo celoten korak.[4] Simuliramo nekaj tisoč ponovitev procesa, da ugotovimo: povprečen čas izvedbe instanc procesa, predvidene stroške za izvedbo aktivnosti, kritične poti, ozka grla in obremenjenost virov. Če se pri razvoju osredotočimo na vse ugotovitve, lahko prihranimo sredstva, ljudi in čas. 2.3 Implementacija poslovnih procesov Cilj implementacije je polna informacijska podpora poslovnemu procesu in vpogled v izvajanje poslovnih procesov. Implementacija je lahko preprosta, če smo poslovne procese modelirali z notacijo BPMN, saj večina orodij omogoča avtomatsko preslikavo iz notacije BPMN v izvedljiv jezik BPEL. S takšno preslikavo omogočimo: polno podporo poslovnim procesom, večjo fleksibilnost, lažji razvoj, kasnejše vzdrževanje in ponovno uporabo.

13 Ker je jezik BPEL namenjen zaporednemu izvajanju aktivnosti, je Stran 5 potrebno pri modeliranju upoštevati, da vseh modelov ni možno direktno pretvoriti v izvršljivo obliko in moramo paziti kako bomo modelirali. Lahko pa tudi uporabimo klasični pristop implementacije. V tem primeru sledimo klasičnemu ciklu razvoja programske opreme. Pri takšnem pristopu ni polne podpore poslovnim procesom, ter je velik razkorak med programsko opremo in poslovnim procesom. Nefleksibilnost programske opreme je odvisna od zasnove in kakovosti izvedbe.[5] 2.4 Izvajanje poslovnih procesov Za izvajanje poslovnega procesa implementiranega v jeziku BPEL, potrebujemo BPEL strežnik, na katerem teče spletni servis procesa. Vsak strežnik mora imeti vmesnik, s katerim lahko spremljamo izvajanje procesa. To pomeni, da lahko za vsak korak vidimo, kaj je bilo poslano na vhod, in kaj spletna storitev vrne kot rezultat. Tako tudi lažje iščemo napake. Strežnik pa mora imeti tudi podporo za vključevanje ljudi v poslovne procese.[5] 2.5 Spremljanje poslovnih procesov Spremljanju poslovnih procesov so namenjena orodja BAM (Business Activity Monitoring). Namen je zagotoviti nadzor nad izvajanjem poslovnih procesov s poudarkom na spremljanju učinkovitosti poslovnih procesov. Ker želimo spremljati izvajanje s čim manjšim zamikom, je čas pri orodjih BAM ključnega pomena. To nam omogoča, da pravočasno reagiramo v kritičnih situacijah. Nadzorna plošča orodja mora biti čim bolj enostavna in pregledna. Orodja, poleg grafičnega in tabelaričnega prikaza podatkov, omogočajo tudi programirane akcije.[4] Le-te lahko v primeru kritičnih situacij samodejno posredujejo podatke odgovornim osebam (e-pošta, SMS), ali pa se sprožijo samodejni mehanizmi za popravljanje procesa.[5] Učinkovitost se meri s pomočjo kazalnikov uspešnosti (KPI Key performance indicator). Kazalniki uspešnosti so: obremenjenost virov, povprečni čas izvedbe procesa,

14 Stran 6 stroški izvedbe procesa, produktivnost, razpoložljivost procesa, stroški napak, število zastojev procesa, itd. 2.6 Optimizacija poslovnih procesov Optimizacija poslovnih procesov je poznana tudi kot prenova poslovnih procesov. Je zadnji korak v življenjskem ciklu poslovnega procesa. Z optimiziranjem poslovnega procesa želimo: izboljšati konkurenčnost, znižati stroške, povečati prodajo in izboljšati obvladovanje napak. Za nekatere specifične primere poslovnih procesov obstajajo primeri dobrih praks. Tovrstna ogrodja so priporočljiva, saj na ta način standardiziramo poslovni proces, olajšamo morebitno povezavo z drugimi organizacijami znotraj panoge, ter poenostavimo merjenje učinkovitosti. Potrebno je upoštevati dejstvo, da se organizacije med seboj razlikujejo, če tudi so znotraj iste panoge. Iz tega razloga je potrebno splošne dobre prakse prilagoditi posamezni organizaciji. Pri optimizaciji poslovnih procesov pa lahko naletimo tudi na težave. Ni se dobro omejiti samo na odpravo ozkih grl, ampak je priporočljivo, da uporabimo bolj inovativne pristope poslovanja in vključimo izboljšave. Posnemanje drugih organizacij ni priporočljivo. Čeprav je priporočljivo, da jih proučimo, pa ni nujno, da je tisto, kar je dobro za druge organizacije, dobro tudi za naše podjetje. Ne smemo imeti prevelikih pričakovanj, da bo informacijska tehnologija rešila vse probleme. Če smo se odločili za napačne kazalce uspešnost, ne moremo realno oceniti učinkovitosti.[5]

15 Stran 7 3 NOTACIJA BPMN [3] BPMN (Business Process Modelling Notation) je grafična notacija za modeliranje poslovnih procesov. Nastala je pod okriljem organizacije BPMI (Business Process Management Initiative), od leta 2005 pa za njo skrbi skupina OMG (Object Management Group). Trenutno je zadnja verzija 2.0, ki je v uporabi že od januarja Osnova BPMN je diagram BPD (Business Process Diagram). Diagram je enostaven za uporabo in razumevanje. Uporabljamo ga lahko za hitro in enostavno modeliranje procesov, hkrati pa ga lahko uporabljamo tudi za načrtovanje kompleksnih poslovnih procesov. Razumevanje diagrama je preprosto, ker je notacija grafična so procesi ter delovni tokovi grafično prikazani. Diagrame lahko razumejo tudi poslovni uporabniki. BPD temelji na tehniki diagrama poteka, le da je prilagojen izdelavi grafičnih modelov poslovnih procesov. Za risanje BPD uporabljamo grafične elemente. Ti elementi omogočajo enostavno izdelavo preprostih diagramov in so bili narejeni tako, da se med seboj zlahka razlikujejo in da uporabljajo oblike, ki jih načrtovalci poznajo že od prej in iz drugih diagramskih tehnik. Pri razvoju notacije BPMN je bil glavni namen izdelati preprost mehanizem, ki bi podpiral kompleksnost poslovnih procesov. Da so zagotovili preprostost razumevanja diagrama BPD, so grafični elementi organizirani v posamezne kategorije. Ker pa je potreba po kompleksnosti diagramov zaradi kompleksnosti poslovnih procesov, so znotraj posamezne kategorije elementov dodane še različne variacije in informacije, kar pa občutno ne spremeni osnovnega videza in pomena diagrama. Elemente delimo na pet osnovnih kategorij: dogodki (events), aktivnosti (activities), prehodi, odločitve (gateways), izdelki (artefacts), pasovi, povezave.

16 Stran 8 Slika 3.1: Elementi ki sestavljajo notacijo BPMN 3.1 Dogodki Dogodek je nekaj, kar se zgodi med izvajanjem poslovnega procesa, in vpliva na tok izvajanja. Prikazujemo jih s krogom. Po robu kroga ločimo dogodke na začetne, vmesene ali končne. Znotraj kroga pa se lahko nahajajo različni tipi prožilcev ali rezultatov. Z začetnim dogodkom pokažemo na mesto začetka izvajanja procesa. Procesni model ima lahko samo en začetni dogodek. Tudi v pod-procesih moramo označiti začetek izvajanja z začetnim dogodkom. Vsi dogodki, ki se nahajajo med začetnim in končnim dogodkom, so vmesni dogodki. S končnim dogodkom nakažemo zaključek izvajanja procesa. Za modeliranje zapletenih procesnih tokov je treba uporabiti kompleksnejše tipe poslovnih dogodkov.

17 Stran 9 Ti tipi dogodkov so: sporočilo, časovnik, napaka oz. izjema, prekinitev, kompenzacija, pravilo, povezava, sestavljen dogodek, odpoved. Začetno sporočilo pride do udeleženca in sproži začetek procesa. V primeru vmesnega sporočila, sprejme ali pošlje sporočilo in nadaljuje z izvajanjem procesa. Končno sporočilo pa proces konča in sproži izdelavo sporočila. Za sprožitev procesa lahko nastavimo določen čas ali cikel (npr. vsak dan ob 8:00), lahko pa ga nadaljuje če je časovnik vmesni dogodek. Končni dogodek izjeme sporoči pogonu procesa, da mora biti ustvarjena napaka. To napako bo ulovil vmesni dogodek izjeme. Prekinitev pomeni, da je prišlo do nekega izjemnega dogodka, in da se morajo vse aktivnosti v procesu takoj ustavit. Kompenzacija sporoči pogonu procesa, da je potrebno proces vrniti v enega izmed prejšnjih stanj. Pravilo se sproži ko so izpolnjeni določeni pogoji. Povezava je mehanizem za povezavo končnega dogodka enega procesnega toka z začetnim dogodkom drugega toka. Sestavljen dogodek ima možnih več različnih prožilcev za začetek ali nadaljevanje procesa, vendar se zahteva samo eden. Kateri tipi bodo uporabljeni je podano v atributih. Za sestavljen končni dogodek je možnih več različnih posledic.

18 Stran 10 Odpoved je vrsta končnega dogodka, ki nam pove, da se morajo vse dejavnosti v procesu takoj zaključiti. Slika 3.2: Vrste dogodkov [povzeto po BPMN poster] 3.2 Aktivnosti Aktivnosti so razdeljene na: procese,

19 Stran 11 pod-procese in opravila. Vse prikažemo na podoben način, in sicer s pravokotnikom, ki ima zaobljene robove. Podproces je proces, ki ga lahko še podrobneje razgradimo. To pomeni, da lahko gremo še en nivo nižje in proces še natančneje opišemo. Proces, ki ga ne moremo več razgraditi na podproces in smo prišli na najnižji nivo razčlenitve procesa, imenujemo opravilo. Tako je lahko proces sestavljen iz pod-procesov in opravil. Pod-proces in opravilo se ločita po tem, da ima pod-proces v spodnjem delu pravokotnika znak "+". Ta znak pomeni, da lahko proces razširimo, in vidimo njegovo vsebino. Poznamo več specialnih vrst opravil in pod-procesov: ad-hoc aktivnost, več primerkov neke aktivnosti, ponavljajoča se aktivnost in kompenzacija. Ponavljajoča aktivnost dogodki v tej aktivnosti se ponavljajo, torej ko pridejo dogodki do konca, se pričnejo zopet izvajati na začetku. To se izvaja tako dolgo, dokler se z nekim dogodkom izvajanje ne zaključi. Ad-hoc aktivnost vrstni red izvajanja aktivnosti v času načrtovanja še ni določen. Več primerkov aktivnosti pomeni, da neka aktivnost obstaja večkrat. Kompenzacija aktivnosti je aktivnost, ki se izvede, kadar želimo s kompenzacijskim dogodkom povrniti izvajanje v prvotno stanje, torej želimo izničiti vse spremembe.

20 Stran Prehodi, odločitve Prehodi oz. odločitve so prikazani z znakom romba. Uporabljamo jih za razdelitev in združitev procesnega toka. Obstaja več vrst prehodov. Podatkovna ekskluzivna ALI vejitev iz prehoda gre ven samo en izhodni tok. Na izhodu imamo več možnosti, vendar se izbere samo en proces, ki se bo nadaljeval. Dogodkovna ekskluzivna ALI vejitev je enaka podatkovni ekskluzivni ALI vejitvi, le da je vsaj na enem izhodnem toku namesto procesa dogodek. ALI vejitev kot izhod se izvede eden ali več izhodnih tokov. Da zagotovimo izvedbo vsaj enega toku, moramo določiti privzeti tok. IN vejitev ali tudi vzporedni prehod. Iz vejitve se izvedejo vsi izhodni tokovi vzporedno. Kompleksna vejitev potrebno je določiti kompleksne pogoje za tok. Ti pogoji se sklicujejo na ime izhodnega toka. Izraz določi, kateri odhodni tok bo vzet. 3.4 Izdelki Izdelki se uporabljajo za zagotavljanje dodatnih informacij o procesu. S tem se načrtovalcem in orodjem za modeliranje dovoli določena mera fleksibilnosti. Tako se omogoči, da se osnovna notacija razširi in daje možnost označevanja v specifičnih situacijah. Poznamo tri tipe izdelkov: podatkovni objekt, skupina, označba.

21 Stran 13 Podatkovni objekt zagotavlja informacije o tem, katere aktivnosti se sprožajo in kaj proizvajajo. Kot izdelki se obravnavajo, ker nimajo nobenega neposrednega učinka na zaporedni tok ali tok sporočila v procesu. Skupina se uporablja za namene dokumentiranja ali v namene analize. Združevanje v skupine ne vpliva na procesni tok. Prikažemo jo kot pravokotnik s prekinjeno črto. Označba je mehanizem načrtovalcev, za zagotavljanje dodatnih informacij bralcem diagrama. 3.5 Pasovi, povezave BPMN uporablja pasove za vizualno ločevanje kategorij. Poznamo dve vrsti pasov: bazen, steza. Bazen je sestavljen iz ene ali več stez. Značilno je, da bazen predstavlja neko združbo, steza pa oddelek v tej združbi. S tem določimo: kdo kaj v procesu stori, kje se dogodki storijo, za prehode, kdo sprejme kakšno odločitev in kje se ta odločitev zgodi. Ker se aktivnosti znotraj posameznih bazenov smatrajo kot posamezni proces, ne more zaporedni tok prečkati meje bazena. Zato lahko med bazeni komuniciramo s tokom sporočila. Ti dve vrsti tokov spadata med povezave. Poznamo pa še tri vrste povezav: asociacija, pogojni tok, privzeti tok. Povezave se uporabljajo za prikaz vrstnega reda izvajanja toka.

22 Stran 14 Slika 3.3: Vrste tokov [povzeto po BPMN poster] S tokom zaporedja prikažemo smer izvajanja toka v procesu. Nariše se s polno ravno črto in polno puščico. Slika 3.4: Katere elemente lahko med seboj povežemo s tokom zaporedja [BPMN poster]

23 Stran 15 Tok sporočila se uporablja za prikaz potovanja sporočila med dvema udeležencema v procesu (med dvema bazenoma). Nariše se s pretrgano črto in prazno puščico, na drugi strani pa s krožcem. Slika 3.5: Katere elemente lahko med seboj povežemo s tokom sporočil [BPMN poster] Asociacija se uporablja za povezovanje podatkov, besedil in ostalih izdelkov z objekti toka. Nariše se s pikčasto črto in puščico (usmerjen asociacijski tok), ali pa samo s pikčasto črto (neusmerjen asociacijski tok). Z njo se prikažejo vhodne in izhodne aktivnosti. Pogojni tok se lahko uporabi namesto podatkovne ekskluzivne ALI vejitve. Namesto da uporabimo znak za vejitev, lahko iz aktivnosti narišemo dva ali več pogojnih tokov, in s tem določimo, po katerem toku se bo proces nadaljeval. Nariše se z rombom na eni strani, polno ravno črto in puščico. Za ekskluzivne podatkovne ALI vejitve ali za navadne ALI vejitve se uporablja privzeti tok. Izvajanje se bo nadaljevalo po tem toku le v primeru, če pogoji v vseh drugih izhodnih tokovih ne bodo pravilni. Nariše se enako kot tok zaporedja, le da ima pri izhodu prečrtano črto.

24 Stran 16 4 OGRODJE ITIL ITIL (Information Technology Infrastructure Library) je zbirka knjig z opisi in napotki za uvajanje in upravljanje storitev. Priporočila ITIL vsebujejo ''dobre prakse'' s področja IT storitev. Razvil ga je OGC, to je Urad za trgovino britanske vlade. Namenjen je bil potrebam britanske vlade, ker pa se je izkazala njegova univerzalnost, se je hitro razširil med organizacijami po svetu.[9] V sklopu priporočil izvajanja storitev (''Service Operation'') je tudi center za podporo storitvam (''Service Desk''). Storitveni center je pomemben del IT oddelka. Učinkovit center je lahko nadomestilo za pomanjkljivosti drugod v IT oddelku, slab pa lahko daje slab vtis na celoten IT oddelek, ki je sicer lahko zelo učinkovit. Vrsta, velikost in lokacija storitvenega centra je odvisna od vrste poslovanja, števila uporabnikov, težavnosti klicev, obsega storitev in drugih dejavnikov. Pomembno je, da vzpostavimo samo enotno kontaktno točko za uporabnike. Ne glede na strukturo centra, naj bo za uporabnike navzven vidna samo ena telefonska številka, en poštni naslov in en spletni vmesnik, saj uporabniki ne smejo biti v dvomih kam se obrniti, ko potrebujejo pomoč. V ta namen naj bi bili ti podatki objavljeni nekje, kjer so uporabnikom na dosegu roke, da lahko pridejo do njih v trenutku, ko jih potrebujejo. Glavni cilj je podpora dogovorjeni IT storitvi z zagotavljanjem dostopnosti in razpoložljivosti organizacije, z izvajanjem različnih podpornih dejavnosti. S tem se želi vzpostaviti normalno izvajanje storitve v najkrajšem možnem času. Naloge, ki so v to vključene: natančno beleženje zahtevkov, razvrščanje in določanje prednosti, zagotavljanje prvega nivoja raziskovanja in diagnosticiranja napak, reševanje incidentov, katere so zmožni rešiti, obveščanje uporabnikov o napredku reševanja napake, spremembah ali dogovorjenih izpadih, zapiranje vseh rešenih napak, zahtev in drugih klicev,

25 Stran 17 opravljanje raziskav o zadovoljstvu uporabnikov s storitvenim centrom. Priporočila ITIL podajajo štiri osnovne koncepte organizacije centra, vendar je zapisano tudi, da obstaja več načinov za strukturiranje centra. Pravilna rešitev se razlikuje med organizacijami in mora biti oblikovana tako, da v celoti zadostuje poslovnim potrebam. Strukture storitvenega centra, ki jih loči ITIL so : lokalni, centralni, virtualni in sistem sledenja soncu. Lokalni storitveni servisi se nahajajo znotraj ali fizično blizu uporabnikom. To je pogosto v pomoč pri komunikaciji in omogoča fizično prisotnost pri reševanju incidentov, kar je nekaterim uporabnikom všeč, vendar je lahko pogosto neučinkovito in drago. Razlogi zakaj vpeljati lokalni center so jezikovne in kulturne razlike, različni časovni pasovi, specializirane skupine uporabnikov. S centralnimi storitvenimi centri je možno zmanjšati njihovo število z njihovim združevanjem v eno samo centralno lokacijo. S tem lahko dosežemo večjo učinkovitost in znižamo stroške, kar omogoča, da se manjše število osebja ukvarja z večjo količino zahtevkov. To lahko privede do višje ravni znanja in spretnosti s seznanjanjem pogostejših pojavov dogodkov. Virtualni oz. navidezni storitveni centri so nastali z uporabo tehnologije predvsem interneta. S tem in z orodji za podporo podjetja dajejo vtis enega centralnega storitvenega centra, v resnici pa se nahaja na več geografsko različnih lokacijah. To omogoča možnost dela od doma, selitve in outsorcinga. Storitveni center po sistemu sledenja soncu, je primeren za mednarodne organizacije, ki bi želele združiti dve ali več svojih geografsko razpršenih storitvenih centrov, da bi zagotovili 24-urno podporo uporabnikom. V primeru, da imamo storitvene servise v Aziji, Evropi in Ameriki, lahko organiziramo, da vsak sprejema klice samo v uradnih urah, saj ko se eden center zapre, se odpre drugi na drugem kontinentu. S tem zagotovimo 24 urno pokritost po nizki ceni, saj nobeden izmed centrov ne dela nadur, ampak vsi delajo samo v eni izmeni.

26 Stran 18 Potrebno pa je poskrbeti, da so skupni procesi, orodje in baze podatkov, saj le tako res deluje kot en storitveni center.[14] Slika 4.1: Lokalni storitveni center [povzeto po ITIL V3, Service Operation]

27 Slika 4.2: Centralni storitveni center [povzeto po ITIL V3, Service Operation] Slika 4.3: Virtualni storitveni center [povzeto po ITIL V3, Service Operation] Stran 19

28 Stran 20 ITIL v storitvenem centru definira štiri vloge: analitika storitvenega centra, vodjo storitvenega centra, nadzornika storitvenega centra in super uporabnika. Analitik storitvenega centra predstavlja prvi nivo podpore s sprejemanjem klicev in z obvladovanjem posledic izrednih dogodkov, z uporabo poročil o dogodkih in procesih izpolnjevanja zahtevkov. V vlogi nadzornika lahko v zelo majhnih storitvenih centrih deluje tudi izkušenejši analitik, vendar pa v večjih storitvenih centrih to verjetno ne bo mogoče in bo potrebna posebej za to namenska vloga. Nadzornikov je lahko več, če je center večji oz. če je organiziran kot virtualni ali po sistemu sledenja soncu. Z upravljanjem urnikov zaposlenih mora zagotoviti zadostno število zaposlenih in stopnjo usposobljenosti skozi ves obratovalni čas. Kadar imamo opravka s težkimi ali spornimi klici deluje kot razširitvena stopnja analitikov, ter jim pomaga kadar so delovne obremenitve visoke ali kadar so potrebne dodatne izkušnje. Vloga vodje storitvenega centra se pojavi v velikih centrih, kjer imamo več nadzornikov. V teh primerih so nadzorniki dolžni poročati vodji. Vodja prevzame upravljanje in odgovornost celotnega centra, ter je dolžan poročati višjemu vodstvu. Vloga super uporabnika je sestavljena iz poslovnega uporabnika, ki nastopa kot povezava med IT oddelkom in posamezniki storitvenega centra. Super uporabniki lahko sodelujejo pri usposabljanju uporabnikov na njihovem področju, zagotavljanju podpore manjšim incidentom, izpolnjevanju preprostih zahtev in pri izgradnji in odobritvi novih informacijskih rešitev. Ne zagotavljajo podpore za celotni IT sistem, ampak samo za določene aplikacije, module ali določena poslovna področja.[15] Pomembno je, da je vso osebje, preden prične z delom v storitvenem centru, ustrezno usposobljeno. Vsak zaposleni mora zaključiti določen program usposabljanja, ki pa se razlikuje glede na obstoječo raven znanja in izkušenj. Ko konča z usposabljanjem, najprej samo sedi z izkušenejšim zaposlenim, s časom pa dela vedno bolj samostojno, dokler ni pripravljen za popolnoma samostojno delo. Dobro je tudi, da gre mentor skozi določena

29 Stran 21 usposabljanja za mentorje, saj lahko tako lažje prenaša znanje, spretnosti, deli izkušnje ter poučuje novega zaposlenega. Učenje pa ni pomembno samo za novo zaposlene, temveč morajo biti vsi zaposleni seznanjeni z novimi tehnologijami in jih obvladovati. V nasprotnem primeru storitveni center ne zagotavlja zadostne podpore. Da lahko ocenimo zrelost, učinkovitost, uspešnost in vsako možnost za izboljšanje storitvenega centra, moramo določit, kaj bomo merili in s katerimi meritvami bomo to ocenili. Meritve morajo biti realne in skrbno izbrane. Nekateri pokazatelji se nam morda zdijo primerni, a so lahko zavajajoči in nam prikažejo, da je center uspešen čeprav morda ni. Kot primarno merilo se pogosto uporablja odstotek klicev, rešenih na prvem nivoju podpore, brez da bi ti bili posredovani dalje. Če je potreba po večji natančnosti, lahko to merilo razdelimo še natančneje in merimo odstotek klicev rešenih ob prvem stiku s storitvenim centrom. To pomeni, da medtem, ko je uporabnik še na telefonski liniji, merimo odstotek klicev, ki jih rešijo, ne da bi iskali pomoč drugih skupin. Merimo še povprečni čas reševanja incidenta, povprečne stroške ravnanja z incidentom, povprečen čas za pregled in zaključevanje rečenega klica, ter število klicev, ki jih časovno razčlenimo, da lahko določimo število zaposlenih in njihovo razporeditev. Za merjenje uspešnosti je potrebno izvajati tudi raziskave o zadovoljstvu uporabnikov s storitvenim centrom. V priporočilih ITIL je opisano tudi orodje in tehnologija, ki je ustrezna za uporabo v storitvenem centru. Telefonija mora biti zagotovljena z dobro moderno telefonsko storitvijo, ker je veliko število zahtev prijavljenih preko telefona. Vključevati bi morala avtomatsko razdelitev klicev sistem ki omogoča eno telefonsko število, nato pa lahko razdeli klice glede na izbiro vnosa preko tipkovnice. Dobra je tudi uporaba programske opreme, ki omogoča prepoznavanje uporabnika. Priporočena je IP telefonija, ki lahko bistveno zmanjša stroške, če imamo opravka z oddaljenimi in mednarodnimi uporabniki. Za merjenje zgoraj opisanih meritev, nam bo v veliko pomoč tudi programska oprema za statistiko, ki lahko beleži število vseh klicev, čas odgovora, število klicev po posameznih analitikih in povprečni čas trajanja klica. Seveda pa so še druga orodja za podporo storitvenemu centru. Eno izmed takšnih je baza znanih napak. Baza shranjuje podrobnosti prejšnjih dogodkov in njihove rešitve, saj lahko tako hitreje določimo in odpravimo napako. V pomoč so tudi diagnostične skripta, ki so razvite zato, da lahko osebje v storitvenem centru natančno določi vzrok napake. Vključujejo podrobnosti o najverjetnejših odpovedih, ključna vprašanja za podrobno opredelitev težave in navodila za

30 Stran 22 reševanje napake. Podatke za izdelavo teh skript posredujejo strokovnjaki za podporo in dobavitelji. Stroškovno učinkovita in osnovna pomoč za manjše težave je lahko tudi spletni vmesnik za samopomoč. Takšen spletni vmesnik ne sme biti preveč zahteven za povprečnega uporabnika. Priporočljivo je, da vsebuje pogosto zastavljena vprašanja in rešitve, neke vrste glasilo vsebuje podatke o odprtih težavah skupaj s pričakovanim časom odprave, možnost prenosa popravkov programov, ki jih še nima nameščenih, napredno obveščanje o vseh načrtovanih izpadih. Zelo pomembno vlogo v storitvenem centru igra orodje za oddaljeno upravljanje, saj lahko le tako analitiki natančno vidijo kakšna je težava in jo z vodenjem uporabnika po korakih tudi odpravijo.[14]

31 Stran 23 5 ORODJE ORACLE BPA Orodje Oracle BPA temelji na orodju ARIS Architect. Orodje še vključuje orodja za simulacijo izvajanja poslovnih procesov in za vpogled v procesni model. Oracle Business Process Architect je orodje za risanje različnih diagramov v različnih diagramskih tehnikah.[7] Uporabili smo ga za modeliranje procesa, ki nam je služil kot primer za spoznavanje orodja. Narisali smo ga v diagramu BPD po notaciji BPMN. Slika 5.1: Osnovni pogled na Oracle BPA Orodje Oracle BPA je sestavljeno iz več delov. V levem delu zaslona je del, v katerem izbiramo med različnimi moduli. Za risanje se uporablja modul "Designer", s katerim rišemo poslovne procese v različnih diagramskih tehnikah. Z modulom "Explorer" si lahko ogledamo elemente različnih projektov. Imamo še modul za: administracijo, skripte in simulacije. Podrobneje bomo predstavili modul "Designer", saj z njim modeliramo poslovne procese. Zraven kolone z moduli se nahaja navigacijsko okno, v katerem se pomikamo med projekti

32 Stran 24 in izbiramo med različnimi diagrami, ki smo jih narisali. Izberemo lahko tudi predogled procesa, če je proces res obširen, se s predogledom lažje orientiramo. Na voljo imamo tudi izbiro, da se nam prikaže seznam elementov, ki so v posameznem diagramu. Pod tem je okno z lastnostmi kjer se prikažejo lastnosti atributov določenega elementa, ki smo ga izbrali v oknu za risanje. Ogledamo si lahko vse povezave tega elementa in tip povezave, ter ostale podatke. V oknu za risanje modeliramo procese in ostale diagrame. To je glavno okno v modulu "Designer". Modeliramo različne diagrame, elemente pa uporabljamo iz kolone s simboli. V tej koloni je nabor vseh simbolov izbrane diagramske tehnike. 5.1 Primer modeliranja procesa Kot primer smo narisali proces prijave in reševanje napake na računalniški opremi. Namen procesa je prikazati in preizkusiti značilnosti orodja Oracle BPA. Proces se začne, ko uporabnik prijavi napako. Napako lahko prijavi preko telefona službi za pomoč uporabnikom ali pa preko spletne aplikacije za prijavo napak. V procesu nastopajo štiri vloge: služba za pomoč uporabnikom, skrbniki delovnih postaj; pregledovalec zahtevkov, uporabnik. V primeru da uporabnik prijavi napako preko telefona, služba za pomoč uporabnikom ugotovi ali je napaka strojna ali programska. Kadar je napaka programska, jo poskusi odpraviti na daljavo. V primeru da jo odpravi na daljavo, se proces prijave in odprave napake konča. Če je ne more odpraviti na daljavo ali kadar je napaka strojna, jo preko elektronske pošte posredujejo skrbnikom delovnih postaj. Skrbniki delovnih postaj odpravijo napako. Če je le-ta strojna, morajo s seboj vzeti še rezervno strojno opremo, da jo lahko zamenjajo. Ko je napaka odpravljena, skrbniki javijo službi za pomoč uporabnikom, da je zadeva urejena. S tem se proces konča.

33 Stran 25 Kadar pa uporabnik prijavi napako, oz. poda zahtevo preko spletne aplikacije, mora najprej izpolniti podatke v aplikaciji. Aplikacija nato zahtevek posreduje do odgovornega v oddelku za pomoč uporabnikom, ki odloči kdo je odgovoren za odpravo te napake. Odgovorna oseba (skrbniki delovnih postaj) je obveščena o napaki preko elektronske pošte. Ti odpravijo napako in v spletni aplikaciji zaključijo zahtevek. Zahtevek se posreduje osebi, ki je odgovorna za zahtevke, ki zahtevek dokončno zapre. Tako se proces zaključi. Zgoraj opisani proces smo pretvorili v grafično obliko. Modelirali smo ga v orodju Oracle BPA z notacijo BPMN. Slika 5.2: Proces: Prijava napake 1/2

34 Stran 26 Slika 5.3: Proces: Prijava napake 2/2 Proces se prične s podatkovno ALI vejitvijo, kjer se izbere kako je bila podana prijava napake. V 93% se poda preko telefona, zato moramo urediti, da orodje kasneje pri simulacijah to tudi upošteva. "Telefonska prijava napake" je aktivnost tipa obvestilo, s katero prejmemo napako po glasovnem kanalu. Ko ustvarimo aktivnost, moramo nastaviti po katerem kanalu bo potovalo obvestilo ter kdo je sprejemnik. Ta dva atributa sta obvezna, lahko pa še dodamo točno sporočilo, ki se prenaša, zadevo sporočila, ter priponko. Ti atributi so opcijski in jih ni potrebno nastaviti. Nato je funkcija "Odprava napake na daljavo". "Odprava napake na daljavo" je v 75% uspešna, zato smo morali nastaviti tudi pri vejitvi, da se tok v katerem je uspešna, odprava napake izvede v 75%. V ostalih 25% napaka, ki je prijavljena telefonsko, ni bila uspešno odpravljena na daljavo, zato jo je potrebno odpraviti pri uporabniku. Ostalih 7% vseh napak je prijavljenih preko spleta s spletno aplikacijo. Pri spletni prijavi in tudi pri prijavi preko telefona,se pojavi pod-proces Odprava napake. V njem sodelujejo samo skrbniki delovnih postaj.

35 Stran 27 Slika 5.4: Znak za podrobnejši pogled aktivnosti Znak na sliki 5.4, ki ga uporablja orodje Oracle BPA, pomeni, da je aktivnost pod-proces, oziroma da je aktivnost mogoče razširiti in jo še podrobneje razdelati. S klikom na znak se nam prikažejo podrobnosti pod-procesa in vsi njegovi elementi. Slika 5.5: Proces: Odprava napake Najprej preverimo za kakšno vrsto napake gre. V 80% gre za programsko napako, ki jo poskusimo odpraviti na daljavo. Reševanje na daljavo je uspešno v 80%, v ostalih 20% je potreben obisk pri uporabniku, kjer se to težavo odpravi. Kadar je napaka strojna, to je v 20%, je potrebno pripraviti drugo strojno opremo ter jo pri uporabniku zamenjati. S tem je pod-proces zaključen. Ko je končan, je pri spletni prijavi potrebno še zaključiti zahtevek s strani skrbnikov delovnih postaj, ter osebe odgovorne za pregledovanje zahtevkov. Ko se to izvede se celotni proces konča.

36 Stran 28 Kot smo lahko videli pri procesu "Prijava napake", se znak za pod-proces ne pojavi samo pri procesu "Odprava napake", ampak tudi pri nekaterih drugih aktivnostih. Te aktivnosti niso pod-proces, ampak so opravila. Ti diagrami se avtomatsko generirajo na podlagi podatkov, ki smo jih vnesli v čarovnik, ko smo ustvarili opravilo. 5.2 Simuliranje procesa Z modulom za simuliranje v Oracle BPA simuliramo izvajanje procesa. Simulacija izpostavi pomanjkljivosti pri procesih in podpira izvajanje stroškovno učinkovitejših procesov. Orodje zagotavlja različne statistične podatke, ki jih lahko shranimo ali izvozimo v druge programe za nadaljnjo obdelavo. Podatke lahko prikažemo tudi v simulatorju v obliki grafikonov, skozi simulacijo pa lahko spremljamo spreminjanje grafikonov in podatkov. Med simulacijo so animirani tudi sestavni elementi procesa in njegovi atributi. Tako lahko natančno spremljamo kaj se v procesu dogaja. Simulacije praviloma izvajajo osebe, ki poznajo proces, saj le-te: opazijo kje se proces ustavi, kaj se da izboljšati in kako odpravit pomanjkljivosti. Orodje omogoča, da za simuliranje enega procesa, lahko pripravimo več različnih scenarijev. To pomeni, da lahko spreminjamo število oseb, ki delajo na procesu, ceno posameznega opravila, čas izvajanja opravila ter še veliko drugih atributov. Tako ugotovimo, katera različica procesa nam najbolj ustreza in je optimalna za podjetje.

37 Stran 29 Slika 5.6: Oracle BPA simulator V simulatorju imamo del okna namenjen spremljanju procesa in dogajanja v njem. Proces je animiran kjer lahko sproti spremljamo katera aktivnost se tisti trenutek izvaja. Sproti se spreminjajo tudi atributi v simulaciji. V delu pod pregledom izvajanja procesa lahko nastavljamo, kako se naj animirajo objekti in atributi, čas izvajanja simulacije in spremljamo status izvajanja simulacije. V desnem delu okna imamo območje s statistiko, iz katere lahko izrišemo različne grafe. Izrisujemo lahko različne atribute različnih elementov. Podatke lahko izrišemo v: stolpčnem diagramu, linijskem diagramu ali tortnem diagramu. Preden se lotimo izvajanja simulacij je potrebno vnesti realne podatke v model procesa. Podatke lahko vnesemo za vse elemente v diagramu, torej za: aktivnosti, prehode,

38 Stran 30 dogodke in povezave. Aktivnosti: Pri aktivnostih vnesemo koliko ljudi dela na posamezni aktivnosti in katere so tiste vloge, ki delajo na posamezni aktivnosti. Vnesemo pa tudi stroške in frekvenco izvajanja (koliko krat dnevno, tedensko, mesečno ali letno se bo aktivnost ponovila). Za vsako aktivnost posebej nastavimo koliko časa se bo izvajala. Nastavimo lahko točno koliko časa se izvaja, ali pa nastavimo različne porazdelitve, po katerih simulator določi trenutni čas izvajanja aktivnosti. Na voljo imamo: enakomerno porazdelitev, normalno porazdelitev, logaritemsko normalno porazdelitev, eksponentno porazdelitev, Erlangovo porazdelitev, trikotna porazdelitev in porazdelitev gama. Ko izberemo porazdelitev, moramo vnesti tudi zahtevane podatke, po katerih simulator izračuna s formulo izbrane porazdelitve ter trenutni čas izvajanja aktivnosti. Pri konstantnem izvajanju, se za vsako ponovitev procesa aktivnost izvaja enako dolgo. Pri porazdelitvah pa se, glede na podane vrednosti, za vsako ponovitev procesa čas izvajanja aktivnosti spremeni. Sprememba časa izvajanja pa je odvisna od vrste porazdelitve. Vsaka porazdelitev ima drugačno formulo po kateri se računa čas. Spodnji grafi prikazujejo funkcije gostote verjetnosti posameznih porazdelitev. Ta funkcija nam pove kakšna je verjetnost določene vrednosti pri porazdelitvi.

39 Stran 31 Slika 5.7: Enakomerna porazdelitev Pri enakomerni porazdelitvi je verjetnost, da se izbere katera vrednost med a in b (to sta vrednosti, ki smo ju vnesli) popolnoma enaka. Slika 5.8: Normalna porazdelitev Največja verjetnost pri normalni porazdelitvi je okoli središčne točke, seveda pa je, kakor se vidi na sliki 5.8, širina intervala odvisna od vrednosti, ki jih vnesemo. Na spodnjih slikah vidimo grafe ostalih porazdelitev. Tudi pri teh je verjetnost izbrane točke odvisna od vrednosti, ki jih vnesemo. Vsaka porazdelitev ima drugačno funkcijo. Pri eksponentni vnesemo samo eno vrednost, pri trikotni pa tri. Vse ostale porazdelitve zahtevajo dve vrednosti.

40 Slika 5.9: Logaritemsko normalna porazdelitev Slika 5.10: Eksponentna porazdelitev Slika 5.11: Trikotna porazdelitev Stran 32

41 Stran 33 Slika 5.12: Porazdelitev gama Prehodi: Tukaj posebnih nastavitev za simulacije ni. Nastavimo samo tip prehoda. Dogodki: Pri dogodkih ne vnašamo posebnih nastavitev, ampak vnesemo frekvenco izvajanja (koliko krat se dogodek ponovi v nekem obdobju). Povezave: Tistim, ki gredo iz prehodov, moramo nastaviti parameter verjetnost. Če gresta iz prehoda dve povezavi, moramo samo eni nastaviti verjetnost. Verjetnost se nastavi med 0 in 1 (to pomeni med 0% in 100%). Če smo eni nastavili 0,7 to avtomatično pomeni, da je verjetnost druge povezave 0,3. Povezavam se lahko nastavi tudi čas prenosa Izvajanje simulacij Pred izvedbo simulacije, smo elementom v diagramu vnesli podatke, ki smo jih opisali pri načrtovanju procesa. Nastavili smo, da se začetni dogodek v glavnem procesu izvede dnevno 90 krat, kar pomeni, da se celotni proces zažene dnevno 90 krat. Nastavili smo tudi

42 Stran 34 čase izvajanja za vse aktivnosti. Za čase izvajanja smo uporabili enakomerno porazdelitev, saj so časi naključni na intervalu, ki smo ga vnesli. Pri prehodih je bilo potrebno nastaviti tudi verjetnost posameznega zaporednega toka. Pri povezavah smo nastavili takšno verjetnost, kot je bilo opisano pri procesu. Torej, če se je določen del izvedel v 70%, smo mu nastavili atribut verjetnost na 0,7. Najprej smo nastavili, da se celoten proces izvede samo 1 krat. Tako lahko preverimo, če se proces sploh izvede. Ko smo proces zagnali, se je ta brez težav zaključil. Ker pa je v procesu več vejitev, se niso izvedle vse aktivnosti, ampak samo tiste po katerih je tekel zaporedni tok trenutne instance procesa. Zato smo spremenili, da se celoten proces izvaja 100 dni, ker se vsaki dan začne 90 krat pomeni, da se bo čez celotno simulacijo začel 9000 krat. Sedaj se pokaže, če se proces kje ustavi, ali se morda konča samo v polovici primerov. Ko so atributi nastavljeni, poženemo simulacijo. Med simulacijo lahko opazujemo kako se spreminjajo in povečujejo določeni podatki, lahko pa to preskočimo in si ogledamo kakšni so podatki, ko se simulacija konča. Končno statistiko lahko shranimo in kasneje primerjamo rezultate med različnimi nastavitvami atributov ali pa iz nje naredimo različna poročila in grafe. Slika 5.13: Rezultati simulacije: Prijava napake 1/2 Na sliki 5.13 vidimo, da se je celotni proces začel 9001 krat. Telefonska prijava se izvede v 8367 primerih, kar pomeni da se izvede v približno 93%, v ostalih 7% je spletna prijava napake. Pri reševanju napake na daljavo se vidi, da je bilo neuspešno in da se javi naprej v

43 Stran primerih od Iz tega je razvidno, da se v približno 25% proces nadaljuje, v ostalih 75% pa se uspešno zaključi. Slika 5.14: Rezultati simulacije: Prijava napake 2/2 Na sliki 5.14 opazimo, da se pod-proces ''Odprava napake'' izvede 2731 krat. Na enem zaporednem toku se aktivnost pred njim izvede 2103 krat, na drugem pa 632 krat. Ker gre za isti pod-proces, se število izvedb pod-procesa sešteje, zato je številka višja od števila izvedb aktivnosti pred in za njim. Opazimo tudi, da se ob koncu izvajanja simulacij štiri instance pod-procesa še vedno izvajajo in niso zaključene. Celoten proces se ni zaključil devet krat. Po ena instanca so obstale pri ''Telefonska prijava napake'', '' Odprava napake na daljavo'' in ''Odobritev zahtevka'', dve pri ''Zapiranje zahtevka'', štiri pa pri že prej omenjenem pod-procesu, ki si ga bomo natančneje ogledali spodaj.

44 Stran 36 Slika 5.15: Rezultati simulacije: Odprava napake Pod-proces ''Odprava napake'' se v simulaciji začne 2735 krat, konča pa 2731 krat. Torej so se štiri instance ob zaključku še vedno izvajale. Te so obstale v aktivnostih ''Prihod do uporabnika'', ''Menjava strojne opreme'' in dve pri ''Reševanje napake''. Zaporedni tok, kjer je napaka programska, se izvede 2235 krat, to je približno 81% vseh napak. Preostalih 19% je strojnih napak. V 414 primerih (približno 18%) napaka ni uspešno rešena na daljavo, zato je potreben obisk pri uporabniku. V 82% pa je napaka uspešno odpravljena, takrat pa se proces uspešno zaključi. Vidimo lahko, da v procesu in pod-procesu ni nobenih zastojev. Če bi se proces na primer pričel 9001 krat, končal pa samo 4000 krat, takrat bi morali poiskati pri kateri aktivnosti se proces zaustavi, ter ji morda dodati večje število oseb, ki delajo na določeni aktivnosti. S tem bi povečali hitrost izvedbe le-te. Nikjer v procesu ni kakšnega neobičajnega obnašanja, zato ni potrebe po spreminjanju procesa. Lahko pa še kljub temu povečamo čas izvajanja simulacije. Tako bomo nastavili, da se simulacija izvaja 1000 dni in ne 100 tako kot v prejšnjem primeru. Seveda tako kot v prejšnjem primeru ne pride do zastojev, ampak dobimo samo natančnejše podatke za statistiko. Vse aktivnosti se izvedejo približno 10 krat več kot prej. Res je, da se odstotki izvajanja določenih zaporednih tokov pri vejitvah nekoliko razlikujejo od prej, vendar to ni nič problematičnega, saj so odstopanja minimalna. Zgodilo se je celo to, da so med izvajanjem obstale samo 4 instance, kar je celo manj kot v prvem primeru.

45 Stran Optimiziranje procesa z vključitvijo dobrih praks ITIL Zgoraj opisan proces bomo prenovili tako, da bomo vključili dobre prakse iz priporočil ITIL. Dodali bomo tretji nivo podpore, to so zunanji izvajalci, ki bodo reševali težave s strojno opremo. Reševali bodo težave, ki so specifične oz. katere so v skladu z garancijo. Za predajo naloge zunanjim izvajalcem se odločijo skrbniki delovnih postaj takrat ko dobijo zahtevek za odpravo napake. Skrbniki delovnih postaj predstavljajo drugi nivo podpore. Če ne predajo zahteve zunanjemu izvajalcu, vse poteka enako kot je prej. V primeru, da predajo zahtevo zunanjemu izvajalcu, morajo o tem obvestiti tudi uporabnika. Z obvestilom se proces tudi zaključi. Zunanji izvajalci imajo samo eno aktivnost, ki je namenjena reševanju napak. Ker gre za zunanjega izvajalca, ne poznamo njegovega procesa odprave napake ampak vidimo navzven kot eno aktivnost. Primernejše je, če se vloga ''Pregledovalec zahtevkov'' preimenuje v ''Vodja storitvenega centra'', ker pa je storitveni center v tem primeru manjšega obsega, bomo vlogo nadzornika in vodje združili v eno vlogo. Njegova funkcija v tem procesu ni nič drugačna, ampak je samo imenovana v skladu s priporočili ITIL. Doda se tudi aktivnost, v kateri bomo beležili podatke o telefonskem klicu ter aktivnost, v kateri bomo zabeležili stanje napake. Torej ali smo napako uspešno rešili in kako smo jo rešili, ali smo napako predali na drugi nivo podpore in komu smo jo predali.

46 Slika 5.16: Optimiziran proces: Prijava napake 1/2 Stran 38

47 Slika 5.17: Optimiziran proces: Prijava napake 2/2 Slika 5.18: Optimiziran proces: Odprava napake Stran 39

48 Stran 40 Prenovljen proces po priporočilih ITLI prikazujejo slike 5.16, 5.17 in Procesu so dodane aktivnosti, ki smo jih opisali zgoraj. Namen optimizacije je, da s čim manjšimi stroški ustvarimo čim večji dobiček. Naslednja stvar, ki jo moramo storiti je simuliranje procesa in odprava morebitnih nepravilnosti. S simuliranjem ugotovimo, če smo kaj narisali narobe saj nam v tem primeru orodje samo javi napako ali pa ugotovimo, da se proces kje ustavi ter se ne nadaljuje Izvajanje simulacij Vedno moramo po vseh spremembah, ki smo jih storili proces še simulirati, saj lahko ima proces napake, ki smo jih spregledali. Slika 5.19: Rezultati simulacije optimiziranega procesa: Prijava napake 1/2

49 Stran 41 Slika 5.20: Rezultati simulacije optimiziranega procesa: Prijava napake 2/2 Na zgornjih dveh slikah 5.19 in 5.20, vidimo, da se proces normalno izvaja. V primerjavi s prejšnjo različico procesa opazimo, da se pod-proces ''Odprava napake'' izvede manjkrat. To je posledica tega, da nekatere težave predamo tretjemu nivoju podpore, ter jih ne rešujemo več sami. Celoten proces se ne zaključi tri krat, kar je celo manj kot pred prenovo. Eden se ustavi pri ''Telefonska prijava napake'', dva pa pri ''Odprava napake na daljavo''. V procesu ''Prijava napake'' ni zaznati nobenih težav, zato si oglejmo še pod-proces ''Odprava napake''.

50 Stran 42 Slika 5.21: Rezultati simulacije optimiziranega procesa: Odprava napake V primerjavi s pod-procesom ''Odprava napake'' pred prenovo se tudi ta ne razlikuje od njega. Celoten pod-proces se izvede manjkrat, ker se nekatere naloge predajo zunanjim izvajalcem. Razmerje med strojno in programsko je še vedno približno enako. Razlika je v tem, da se pod-proces izvede toliko krat kot se je začel, kar pomeni da ni obstala nobena instanca pod-procesa. Rezultate simulacije si bomo ogledali še z grafi in s statističnimi podatki, ki jih lahko izvozimo. Z grafi bomo prikazali število izvedenih aktivnosti. Slika 5.22: Stolpčni diagram

51 Slika 5.23: Linijski diagram Slika 5.24: Tortni diagram Stran 43

52 Stran 44 Vsi grafi prikazujejo iste podatke, razlika je le v tipu grafa. Rezultate simulacije lahko izvozimo v obliki XML ali pa v obliki CSV. Te podatke lahko nato uvozimo v različne programe, kjer jih lahko obdelamo in prikažemo različna poročila ali pa izvedemo določene analize. Slika 5.25: Podatki v XML obliki Slika 5.25 prikazuje podatke, ki so shranjeni v XML obliki in prikazani v urejevalniku besedila. Naprednejši urejevalniki nam omogočajo barven prikaz zapisa XML datoteke, zato lahko te podatke lepo vidimo tudi v osnovni obliki, brez uporabe razčlenjevalnika kode.

53 Stran 45 Slika 5.26: Podatki v CSV obliki Slika 5.27: Podatki v CSV obliki, uvoženi v program za njihovo obdelavo Podatki v CSV obliki ki jih vidimo na sliki 5.26, so v navadni obliki prikazani v urejevalniku besedila. Na sliki 5.27 pa vidimo CSV podatke, uvožene v program za preglednice. Program je vključen v večino pisarniških orodij. V tem programu pa lahko podatke tudi analiziramo, obdelujemo in si jih pripravimo v obliki, ki nam najbolj ustreza.