NADZOR POSLOVNIH AKTIVNOSTI V INFORMACIJSKIH SISTEMIH · Z upoštevanjem poslovne logike ne potrebujemo dodatnega analitika za odkrivanje napak, saj npr. velika čakalna vrsta v za

Aleš Gjerkeš

NADZOR POSLOVNIH AKTIVNOSTI V

INFORMACIJSKIH SISTEMIH

Diplomsko delo

Maribor, september 2009

II

Diplomsko delo visokošolskega študijskega programa

NADZOR POSLOVNIH AKTIVNOSTI V INFORMACIJSKIH SISTEMIH

Študent: Aleš Gjerkeš Študijski program: VS ŠP Računalništvo in informatika Smer: Informatika Mentor: izr. prof. dr. Matjaž B. Jurič Somentor: doc. dr. Boštjan Brumen

Maribor, september 2009

II

III

ZAHVALA

Zahvaljujem se mentorju dr. Matjažu B. Juriču za

pomoč in vodenje pri opravljanju diplomske

naloge.

Posebna zahvala velja staršem, ki so mi omogočili

študij in drugim bližnjim, ki so mi stali ob strani v

času študija.

IV

NADZOR POSLOVNIH AKTIVNOSTI V INFORMACIJSKIH

SISTEMIH

Ključne besede: nadzor poslovnih aktivnosti, SOA, BAM, ključni kazalniki poslovanja UDK: 004.777(043.2) Povzetek

Na poslovno uspešnost v podjetju vpliva mnogo različnih dogodkov. Za tiste, ki v glavnem

vplivajo na poslovno uspešnost ponavadi vemo. Velikokrat pa vplivajo ravno tisti dogodki,

za katere tega nismo predvidevali. V pomoč pri analiziranju poslovnih procesov in

izboljševanju poslovne uspešnosti so rešitve za nadzor poslovnih aktivnosti (BAM).

Diplomsko delo predstavlja delovanje in uporabo BAM rešitev. Opisali smo delovanje

nadzornega modela in možnih meritev, ki jih lahko z njim merimo. BAM rešitve

pridobivajo podatke s pomočjo spletnih storitev. Zato smo na kratko opisali storitveno

usmerjeno arhitekturo SOA, vlogo BAM v SOA in življenjski cikel razvoja nadzornega

modela. Pregledali smo pomembnejše BAM rešitve na tržišču. Eno od teh smo tudi

uporabili za izdelavo praktičnega primera in sicer IBM Business Monitor. Izdelali smo

nadzorni model, za katerega smo definirali metrike, ključne kazalnike uspešnosti (KPI) in

ostale meritve. Temu sledi pošiljanje testnih dogodkov, zagon ter testiranje nadzornega

modela. Diplomsko delo se zaključi s prikazom delovanja in pregledom rezultatov

nadzornega modela na pregledni plošči. V sklepu smo podali ugotovitve nadzora poslovnih

aktivnosti glede na nadzorni model.

V

BUSINESS ACTIVITY MONITORING IN INFORMATION SYSTEMS

Key words: business activity monitoring, SOA, BAM, key performance indicator UDK: 004.777(043.2) Abstract Business performance of a company is affected by many different events. Those events

which mainly affect business performance are usually known. However, it often happens

that those events have affect for which we did not predict that. Business processes can be

analyzed and business performance can be emproved by means of Business Avtivity

Monitoring (BAM) solutions. The present diploma thesis presents the usage of business

activity monitoring and its working. We described how monitoring model works and

possible measurements we can perform by using it. BAM solutins collect data by the help

of Web services. For this reason we shortly described Service Oriented Arhitecture (SOA),

the role of BAM in SOA and the development life cycle of monitoring model. We made a

review of important BAM solutins on the market. One of them we used to make a practical

example, i.e. IBM Business Monitor. We made a monitoring model, for which we defined

metrics, key performance indicators (KPI) and other measurements. This is followed by

sending of test events, running and testing of the monitoring model. The diploma thesis

ends by a review of monitoring model results on dashboard. Results of business activity

monitoring are given on the example of monitoring model.

VI

VSEBINA

1 UVOD ........................................................................................................................... 1

2 BAM.............................................................................................................................. 2

2.1 Definicija BAM..................................................................................................... 2

2.2 Meritve .................................................................................................................. 3

2.2.1 Količine ............................................................................................................... 4

2.2.2 Časovno odvisne količine.................................................................................... 5

2.2.3 Napake................................................................................................................. 6

2.2.4 Posebni pogoji ..................................................................................................... 7

2.3 Zaznavanje kompleksnih vzorcev ......................................................................... 7

2.4 Skupne lastnosti in razlika med BAM in BI.......................................................... 8

3 VLOGA BAM V SOA................................................................................................. 9

3.1 Arhitektura SOA ................................................................................................... 9

3.2 Povezava med BAM in SOA .............................................................................. 11

3.3 Najpomembnejše BAM rešitve v okolju SOA.................................................... 13

4 IBM BAM REŠITVE IN DELOVANJE NADZORNEGA MODELA ................ 15

4.1 IBM WebSphere.................................................................................................. 15

4.1.1 IBM WebSphere Business Modeler Advanced V6.2 ........................................ 17

4.1.2 IBM WebSphere Integration Developer V6.2 ................................................... 18

4.1.3 IBM WebSphere Business Monitor Development Toolkit V6.2 ...................... 20

4.2 Nadzorni model ................................................................................................... 20

4.2.1 Delovanje nadzorovanja poslovnih procesov...................................................... 21

5 PRAKTIČNI PRIMER............................................................................................. 25

5.1 Opis ..................................................................................................................... 25

VII

5.2 Izdelava nadzornega modela................................................................................ 27

5.2.1 Definicija dogodkov .......................................................................................... 27

5.2.2 Naročanje na dogodke ....................................................................................... 29

5.2.3 Definiranje metrik.............................................................................................. 33

5.2.4 Definiranje KPI.................................................................................................. 41

5.2.5 Definiranje dimenzijskega modela .................................................................... 48

5.3 Zagon in testiranje nadzornega modela ............................................................... 50

5.3.1 Generiranje in zagon nadzornega J2EE projekta............................................... 50

5.3.2 IBM Business Space .......................................................................................... 52

5.3.3 Pošiljanje testnih dogodkov............................................................................... 52

5.4 Pregledna plošča .................................................................................................. 56

5.4.1 Seznam instanc .................................................................................................. 57

5.4.2 Prikazovalnik KPI-jev ....................................................................................... 61

5.4.3 Opozorila ........................................................................................................... 63

5.4.4 Poročila.............................................................................................................. 64

5.4.5 Dimenzije .......................................................................................................... 66

5.4.6 Pregled zgodovine in napovedi.......................................................................... 68

5.4.7 Ostale komponente ............................................................................................ 69

6 SKLEP ........................................................................................................................ 71

7 VIRI, LITERATURA................................................................................................ 72

8 PRILOGE................................................................................................................... 75

8.1 Seznam slik.......................................................................................................... 75

8.2 Seznam tabel........................................................................................................ 76

8.3 Seznam programske kode.................................................................................... 76

8.4 Izvorna koda nadzornega modela in testnih podatkov ........................................ 76

VIII

8.5 Naslov študenta ................................................................................................... 77

8.6 Kratek življenjepis............................................................................................... 77

IX

UPORABLJENE KRATICE

FERI Fakulteta za elektrotehniko, računalništvo in informatiko BAM Business Activity Monitoring BI Business Intelligence BPM Business Process Management EAI Enterprise Application Integration ESB Enterprise Service Bus KPI Key Performance Indicator IT Information Technology SOA Service Oriented Architecture SOAP Simple Object Access Protocol WSDL Web Services Description Language XML Extensible Markup Language UDDI Universal Description Discovery and Integration SCA Service Component Architecture XSD XML Schema Definition SVG Scalable Vector Graphics CBE Common Base Event format J2EE Java 2 Platform, Enterprise Edition JMS Java Message Service EJB Enterprise JavaBean ID Identifier WEF Web Event Format EDI Electronic Data Interchange

Nadzor poslovnih aktivnosti v informacijskih sistemih 1

1 UVOD

V današnjem hitro spreminjajočem se poslovnem svetu je za podjetja in organizacije hitro

ukrepanje bistvenega pomena. Pri tem so BAM (angl. Business Activity Monitoring)

orodja nepogrešljiva, saj omogočajo pregled nad poslovnim dogajanjem v realnem času.

Naloga BAM rešitev je namreč prikaz trenutnih informacij o poslovanju, ki vsebuje stanja

in rezultate različnih operacij, procesov in transakcij. S pomočjo teh informacij je možno

prikazati ključne kazalnike poslovanja KPI-je (Key Performance Indicator), iz katerih je

razvidna zanesljivost in učinkovitost aktivnosti. Ti podatki so pomembni tako za

izvrševalce kot za vodstvo, saj z njimi lahko lažje analizirajo in celo predvidevajo

nepričakovane spremembe ter tako lažje ukrepajo. Pomagajo pa jim tudi pri izboljševanju

poslovnih procesov, saj tako lahko odstranijo ozka grla v svojem poslovanju.

Glavna naloga BAM orodij je torej prikaz t.i. strani s preglednimi ploščami (angl.

Dashboard), ki vsebujejo aktualne informacije o aktivnostih podjetja. Obveščajo določene

skupine uporabnikov ali posameznike o predvidenih, vnaprej določenih ali s pomočjo

BAM logike ugotovljenih odstopanj.

V diplomski nalogi bomo najprej pregledali teorijo in delovanje nadzorovanja poslovnih

aktivnosti. Predstavili bomo relacijo med BAM in SOA (angl. Service-oriented

architecture) in primerjavo z BI (Business Intelligence) rešitvami. Pregledali smo

najpomembnejše BAM rešitve, med katerimi smo za izdelavo praktičnega primera izbrali

rešitve podjetja IBM. V četrtem poglavju smo te rešitve podrobneje opisali skupaj s

kratkim opisom WebSphere arhitekture. Zajeto je tudi delovanje samega nadzornega

modela.

Peto poglavje zajema praktični del, v katerem smo izdelali nadzorni model preprostega

primera podjetja. Najprej definiramo vse potrebno za delovanje nadzornega modela. Le-

tega smo zagnali v testnem okolju, mu poslali testne dogodke in pregledali rezultate na

pregledni plošči. Na koncu diplomske naloge je podan sklep glede na dobljene rezultate.

2 Nadzor poslovnih aktivnosti v informacijskih sistemih

2 BAM

2.1 Definicija BAM

Dejansko ni natančne definicije BAM, jo je pa opisal David McCoy iz podjetja za

raziskovanje Gartner leta 2002 v svojem članku Business Activity Monitoring: Calm Before

the Storm. V njem pravi, da je BAM izraz, ki definira, kako lahko poskrbimo dostop do

ključnih kazalnikov poslovanja (angl. Key Performance Indicator, v nad. KPI) v realnem

času za izboljšanje efektivnosti in hitrosti izvajanja poslovnih aktivnosti. [3]

BAM omogoča organizacijam, da usmerijo analitiko k pridobivanju pregleda nad dnevnimi

poslovnimi aktivnostmi v realnem času. Ta analitski pogled omogoča poslovnim

uporabnikom hitro odkrivanje poslovnih neučinkovitosti in predvidevanje potencialnih

poslovnih problemov. BAM združuje poslovno inteligenco (angl. Business Intelligence) in

obdelavo poslovnih transakcij. Aplikacije za obdelavo poslovnih transakcij poganjajo

poslovne aktivnosti, BI pa te aktivnosti analizirajo. Združuje tudi prodajalce in IT

strokovnjake, ki so doslej delovali v ločenih domenah. [1]

Iz poslovne perspektive je nepomembno ali uporabljamo BAM ali ne. BAM igra vlogo,

kjer tehnologija povečuje poslovne prednosti. Pogosto je obravnavan bolj kot tehnološka

infrastruktura in ne kot poslovna potreba. Iz tega razloga nekateri prodajalci BAM rešitev

raje uporabljajo izraz gradnik operativnih preglednih plošč za opis njihovih produktov.

Poslovnemu managerju namreč izraz pregledna plošča pomeni več kot akronim BAM.

Na splošno BAM orodja zbirajo podatke iz čim več področij poslovanja oziroma vseh

poslovnih aktivnostih. Čim več podatkov dobimo, več poročil lahko izdamo, pošljemo

opozorila ter predvidimo spremembe, ki so lahko bistvenega pomena za poslovanje. Pri

tem pa vendarle moramo biti pozorni, saj preveč informacij lahko tudi odvrne pozornost od

bistvenih poslovnih ciljev. BAM orodja lahko na podlagi aktualnih podatkov in dogodkov

prikazujejo pregledne plošče, iz katerih je razvidno trenutno stanje celotnega poslovanja ali

le določenega poslovnega procesa. V realnosti pa BAM orodja redkokdaj zares delujejo v


realnem času. Običajno generirajo poročila ob določenem času ali glede na določen

dogodek. To pa še vedno daje dovolj sveže informacije za vodstvo, da lahko ustrezno

ukrepa. S pomočjo aktualnih informacij o stanju in rezultatih poslovnih procesov, operacij

in transakcij lahko prikazujemo KPI, iz katerih je razvidna zanesljivost in učinkovitost

poslovnih aktivnosti. [4] KPI je merilo uspešnosti, ki se pogosto uporablja v pomoč

organizacijam, da ovrednotijo svoj uspeh. Ponavadi se ta uspeh gleda kot napredek pri

realizaciji dolgoročno zastavljenih ciljev. Ovrednotijo tudi drugače težko merljive

vrednosti aktivnosti kot so vodenje, dolžnosti, storitve in zadovoljstvo. Tako lahko npr. s

pregledom nad KPI vidimo, kateri poslovni proces predstavlja ozko grlo, in se lahko takoj

posvetimo izboljševanju le-tega. [34]

BAM pa ni omejen le z zbiranjem in prikazovanjem informacij, ki so ključne za

poslovanje. Upošteva lahko tudi sámo poslovno logiko in ukrepa že na podlagi določenih

poslovnih procesov. S pomočjo zgodovine podatkov pa BAM lahko prepozna tudi vzorce

poslovanja. Z upoštevanjem poslovne logike ne potrebujemo dodatnega analitika za

odkrivanje napak, saj npr. velika čakalna vrsta v začetku meseca dopoldan predstavlja

problem, medtem ko je to lahko nekaj povsem normalnega ob zadnjih popoldnevih v

mesecu. Današnja BAM orodja ponujajo že vnaprej pripravljene predloge za določen tip

poslovanja kot so recimo banke, podjetja za logistiko, proizvodna industrija,

telekomunikacije itd. Tako lahko BAM prilagodimo stroki, kjer ga hočemo uporabiti in ga

usmerimo k specifičnim poslovnim problemom. Že to lahko podjetjem poveča donosnost

in povrnitev stroškov v investicijo BAM sistema. Na tisoče svetovnih podjetij je namreč

investicijo v uporabo BAM orodij povrnila v doglednem času. [22, 24, 28, 32]

2.2 Meritve

Za uspešen in učinkovit nadzor poslovanja je izbira meritev, ki jih bomo spremljali,

bistvenega pomena. Meritve predstavljajo podatke različnih tipov, pridobljene iz

poslovnega procesa. BAM pa ni omejen le na zbiranje in prikazovanje podatkov, saj je

tesno povezan tudi s poslovnimi procesi in poslovno logiko. Poslovni proces opisuje

korake, ki so potrebni za izpolnjevanje specifičnih poslovnih akcij, poslovne transakcije pa


so dejanske instance izvajanja procesov. Dogodki procesa se nanašajo na dogodke znotraj

transakcije kot npr. korak, ki zaključuje transakcijo ali pojavitev napake. BAM je

osredotočen na takšne transakcije in dogodke, predvsem na štiri ključne atribute [31]:

• Količine

• Časovno odvisne količine

• Napake

• Posebni pogoji

2.2.1 Količine

Količine, ki jih BAM med izvajanjem procesa spremlja so količinske vrednosti iz različnih

pogledov samega procesa. Te količine se nanašajo na poslovne dogodke in ne tehnične, ki

bi jih lahko merili z IT nadzornimi sistemi.

Primeri količin, ki jih BAM lahko meri so naslednji:

• Cene

• Stroški

• Marža

• Število korakov v procesu

• Število transakcij

• Dohodek od same transakcije

• Dohodek procesa

• Načrtovan poslovni dohodek

• Število sprememb v zapisu

• Število klicev

• Število končnih izdelkov


• Število napak

• Število dni do izdaje blaga

• Količina nabavljenega materiala

• Količina porabljenega materiala

Na teh osnovnih meritvah temelji prvi primer uporabe BAM orodij. Podjetja ponavadi

definirajo dogodke, ki so povezani s temi točkami kot npr. vnaprej definirana meja, ki je

lahko presežena ali odstopanje od statistike. V takem primeru BAM orodje prikaže

opozorilo ali celo ukrepa. Neposredno lahko ukrepa tako, da pošlje nalog za človeško

opravilo (angl. Human task) ustrezni osebi ali pa pošlje opozorilo. S temi merjenimi

količinami lahko prikazujemo obnašanje ene ali več količin v realnem času ali obnašanje

skozi določeno časovno območje. To nam nudi uporabne informacije, ki so uporabne za

vodstvo in prodajalce, saj s pomočjo grafičnih prikazov ponazarjajo tok transakcij skozi

poslovanje in njihove trende. [31]

2.2.2 Časovno odvisne količine

Poleg merjenih količin je za učinkovito poslovanje pomemben tudi čas trajanja samih

poslovnih dogodkov. Čas trajanja nam namreč lahko pove hitrost delovanja ali pa zamudo

določenega dogodka. Dogodkom lahko nastavimo npr. sprejemljiv čas izvajanja. Ko se ta

dogodek pojavi s preseženim časom izvajanja, lahko BAM pošlje opozorilo ali pa

samodejno sproži določene akcije.

Primeri časovno odvisnih količin:

• Čas izvajanja procesa

• Čas izvajanja posameznega koraka v procesu

• Čakalni čas med dogodki

• Preostali čas do zaključka


• Pretok procesov

• Trajanje veljavnosti cen

Pri nakupu BAM rešitev je za končne uporabnike pomembna podpora merjenju količinskih

in časovno odvisnih meritev, saj jih v menedžmentu in marketingu BAM rešitev najbolj

pogosto poudarjajo. Z njimi lahko namreč pridobijo vse potrebne podatke o tem, kako

uspešno je njihovo poslovanje.

S pomočjo teh časovno odvisnih meritev lahko pridobimo več kot le dobro metodo za

pregled uspešnosti poslovanja. Ko je enkrat vključen faktor časa, lahko poleg prikaza

trenutnega stanja predvidimo tudi, kaj se bo zgodilo v prihodnosti. Analitični del BAM

orodij s trenutnimi podatki in podatki iz preteklosti zazna odstopanja v poslovanju. Ko se

pojavi odstopanje od nastavljenih norm, lahko BAM zazna znan vzorec, ki bi lahko vodil

do napak v poslovanju. V takih primerih nas BAM lahko opozori ali pa kar sam posreduje

in s tem poskrbi, da je situacija zaznana še preden vpliva na poslovno učinkovitost. S

časovnim vidikom je lažje identificirati in rešiti ozka grla, saj tako lahko procese

neprestano izboljšujemo. [31]

2.2.3 Napake

Tudi pri najboljših sistemih pride do problemov, ki so lahko posledica napak v procesu,

napak strojne ali programske opreme, seveda so pa možne tudi človeške napake. BAM

sledi tudi tem napakam. Možno jih je locirati, kje so se pojavile, tako da jih je mogoče čim

prej popraviti. S pomočjo statistike in frekvence napak je le-te enostavneje analizirati in s

tem lažje razumeti. BAM pa napake ne le šteje, saj dejansko »razume« poslovne procese in

njihove transakcije ter s tem tudi njihove napake. Napake zajemajo dogodke, kot so:

izvajanje transakcije izven določenega zaporedja, dvojniki transakcij, zastoji korakov ali

celotnega procesa. Te informacije niso koristne le za izboljšanje procesov in poslovanja,

ampak so pomembne tudi pri ugotavljanju skladnosti celote. Eden od načinov preverjanja

skladnosti je ta, da mora določena transakcija pripadati določenemu procesu, proceduri in


kontroli, pri čemer mora biti sama transakcija brez napak. BAM zagotavlja, da so vse

nepravilnosti teh zahtev sporočene in zapisane v dnevnik napak, tako da jih lahko

pregledamo in izvedemo ustrezne ukrepe za odpravljanje le-teh.

Tako kot napake procesov so pomembne tudi poslovne napake. Na primer, ko ima produkt

podano napačno ceno, poteka poslovni proces po načrtu, vendar je končni rezultat še vedno

težava za poslovanje. Tudi za take situacije, ko ne najdemo očitnega vzroka za napake,

poskrbi BAM, saj v povezavi s poslovno logiko »razume« poslovne aktivnosti v smislu

procesa in vsebine. Na ta način zazna tako situacijo, jo sporoči in označi za razrešitev. [31]

2.2.4 Posebni pogoji

Posebni pogoji so pogoji, določeni s strani uporabnika. Predstavljajo dogodke, ki so

relevantni iz uporabnikove perspektive do izvajanja poslovnih transakcij. Uporabljajo se

npr. ko podjetje želi biti obveščeno o vseh naročilih, ki presegajo določeno količino ali

nestandardnih navodilih za dostavo. Ti posebni pogoji predstavljajo ključ do meritev KPI,

ki omogočajo kombiniranje meritev količin, časovno odvisnih količin in napak s

specifičnim poslovnim znanjem in razumevanjem. Lastniki ključnih procesov se lahko

odločajo, kateri dogodki jih posebej zanimajo, in ali jih je potrebno spremljati za doseganje

maksimalnega poslovnega učinka. V dejanskih BAM rešitvah je uporaba posebnih pogojev

povečala izboljšanje produktivnosti tudi do 40%, saj le-ta omogoča vodstvu podjetja

razvijanje aktivnosti kot so pregled trendov, pregled KPI indikatorjev in ustvarjanje

profilov za transakcije. [31]

2.3 Zaznavanje kompleksnih vzorcev

Nekateri poslovni procesi so lahko kompleksni, zato obstajajo trenutki, ko določene

okoliščine lahko vplivajo na poslovanje. Kljub definiranim KPI-jem lahko do nekaterih

težav pride zaradi sprememb v določenem obsegu meritev. Nekateri procesi se lahko

upočasnijo, nekatere vrednosti lahko poskočijo ali se naglo spustijo. Taki kompleksni


vzorci so ponavadi izven dosega posameznega procesa ali transakcije, zato BAM deluje po

tem principu, da naredi trenutni posnetek (angl. Snapshot) nad celotnim dogajanjem, ki ga

sproži ob določenem pogoju oz. odstopanju.

Če se v podjetju pojavi npr. večje število dohodnih klicev v center za pomoč uporabnikom,

kot je to ponavadi, lahko to pomeni težave v nekem delu poslovnih operacij, ali pa je npr.

konkurenca z nenadno potezo spremenila razmere na tržišču. Tako lahko uporabnik

definira, da se v takih primerih naredi trenutni posnetek nad celotnimi operacijami ali

specifično izvedbo procesa. Nato si BAM te trenutne posnetke zbira in jih uporablja za

identifikacijo določenih okoliščin. Po zajemu več trenutnih posnetkov je s pomočjo le-teh

BAM sposoben nadaljnje opazovati podobne kombinacije meritev v celotnem obsegu

poslovnih operacij in uporabnika ustrezno obvestiti. Tako sistem med nabiranjem

»izkušenj« in inteligence postaja vse bolj sposoben predvidevanj vnaprej in pošiljanja

ustreznih opozoril. [31]

2.4 Skupne lastnosti in razlika med BAM in BI Rešitve poslovne inteligence (angl. Business Intelligence, v nad. BI) se nanašajo na to,

kako IT lahko podatke poslovnih procesov združijo v pomembne informacije o stanju

poslovanja v nekem trenutku. Pomagajo analizirati veliko količino zgodovinskih podatkov,

zaznati vzorce in razumeti trende, ki lahko vplivajo na poslovanje. S pomočjo BI tako

lahko analiziramo stanje šele potem, ko damo podatke, ki so nam na voljo v obdelavo, tako

da moramo ta postopek vedno ponavljati. S tem imamo pregled nad zgodovinskimi

podatki. To težavo oz. pomanjkljivost je odpravil BAM, ki pridobiva in analizira podatke v

realnem času iz dogodkov in tako omogoča neprestan pogled v trenutno stanje poslovnih

procesov in samega poslovanja. BAM je torej s tako »majhnim« faktorjem, kot je trenutni

čas, naredil velik napredek napram BI. S pomočjo zaznavanja vzorcev tako omogoča tudi

predvidevanja v prihodnosti. BAM in BI skupaj nudita nadzorovanje poslovanja v realnem

času in analitično orodje. S pogledom nad veliko količino zgodovinskih podatkov lahko

odkrijemo »skrite« pasti z možnostjo pošiljanja opozoril v realnem času. [5]


3 VLOGA BAM V SOA

3.1 Arhitektura SOA

V realnem svetu žal ne obstaja le ena aplikacija, ki bi zadostovala vsem našim potrebam,

podatki pa so ključnega pomena za poslovni proces kot celoto. Ker pa ti podatki prihajajo

iz različnih aplikacij, ki so napisani v različnih programskih jezikih in tečejo na različnih

platformah, je le-te potrebno za dobro IT rešitev združiti, kjer svoje delo opravi storitveno

usmerjena arhitektura (angl. Service-oriented architecture, v nad. SOA) (Slika 3.1).

Slika 3.1: Prikaz interakcije v SOA [29]

SOA je torej arhitektura, ki omogoča fleksibilno in standardizirano povezavo med

različnimi aplikacijami in napravami ter izmenjavo njihovih podatkov. Združuje poslovne

procese s strukturiranjem velikih aplikacij kot majhne zbirke, ki jih imenujemo storitve,

katere komunicirajo med seboj.

SOA temelji na mreži programskih storitev. Storitve obsegajo nezdružljive, šibko

sklopljene (angl. Loosley coupled) funkcionalne enote, ki ne vsebujejo medsebojnih klicev.

Vsaka storitev opravlja določen korak v procesu, kot je npr. rezervacija vozovnice preko

spletne strani. Za medsebojno komunikacijo storitve uporabljajo definirane protokole, ki

opisujejo, kako storitve podajo in obdelajo sporočila z uporabo opisnih meta podatkov. Na

ta način ni potrebno vstavljati njihovih medsebojnih klicev v izvorni kodi. Strokovnjak


poslovnih procesov in razvijalec določita samodejno razvrstitev, upravljanje in

koordinacijo t.i. orkestracije (angl. orchestration) storitev za povezovanje in zaporedje le-

teh, da ustrezajo poslovnim zahtevam. Orkestracija poslovnih procesov je namreč postala

ena najpomembnejših aktivnosti za realizacijo storitvenih arhitektur SOA. Za razumevanje

samih storitev pa so obvezni metapodatki, ki opisujejo karakteristike storitev in njihove

podatke. Običajno so podatki opisani s pomočjo razširljivega označevalnega jezika XML,

storitve pa so opisane z opisnim jezikom spletnih storitev WSDL (Web Services

Description Language) in komunicirajo preko preprostega protokola za dostop do objektov

SOAP (Simple Object Access Protocol). Kakorkoli so metapodatki definirani, morajo

ustrezati naslednjima kriterijema: [35]

• Metapodatek mora biti v obliki, katero lahko programski sistemi uporabijo, da se

oblikujejo dinamično z odkrivanjem in združitvijo definiranih storitev ter ohraniti

skladnost in popolnost.

• Metapodatek mora biti v obliki, ki jo sistemski načrtovalci razumejo in urejajo s

sprejemljivimi stroški in učinkovitostjo.

S pomočjo interneta in SOA lahko povežemo aplikacije, ki fizično tečejo na drugi lokaciji

kot npr. na drugi poslovni enoti podjetja ali celo v drugem podjetju, ki se lahko nahaja tudi

na drugem koncu sveta. Za ta namen se uporabljajo spletne povezovalne tehnologije (angl.

Web services), ki omogočajo pristop gradnje t.i. blokov in so dostopni preko standardnih

internetnih protokolov. Spletne storitve so lahko na novo narejene aplikacije ali pa le ovite

okrog obstoječega sistema, da ga omrežimo. Vsak SOA blok ima lahko eno ali obe od

vlog: [35]

• Ponudnik storitev, ki ustvari internetno storitev in s pomočjo UDDI (Universal

Description, Discovery and Integration) specifikacije definira način objave in vse

potrebne informacije o tej storitvi

• Povpraševalec oz. odjemalec storitev najde vnose za katere lahko potem zaprosi in

jih uporabi.


3.2 Povezava med BAM in SOA Pravilno vzpostavljena arhitektura SOA je pomembna oz. kar predpogoj za učinkovito

delovanje BAM rešitve. Preko SOA se namreč pretakajo vsi potrebni podatki, ki jih potem

BAM ustrezno obdeluje. Ravno zaradi tesne povezanosti med BAM in SOA je za podjetja,

ki uvajajo SOA in hkrati ali v bližnji prihodnosti načrtujejo implementacijo BAM,

priporočljivo združiti enega ali več delov BAM kar s SOA implementacijo. Najprej pa je

seveda potrebno določiti cilje, ki jih želimo z vpeljavo SOA in BAM doseči. Z

definiranjem ključnih meritev, ki jih bomo v poslovanju opravljali s pomočjo BAM, bomo

videli ali se te ključne meritve sčasoma izboljšujejo, kar nam bo dalo tudi boljše

razumevanje tega, kaj je najbolj pomembno za poslovanje. Če bi implementirali SOA kar

brez predhodnega upoštevanja poslovnih zahtev in brez reševanja potencialnih poslovnih

problemov, bi lahko spregledali najpomembnejše dejavnike, ki omogočajo

najučinkovitejšo implementacijo SOA. Nekateri ponudniki BAM rešitev predhodno

analizirajo zmožnosti podjetja, da implementirajo SOA, pri čemer so pomembna področja

poslovanja, IT in usklajevanje teh dveh področij.

Ne glede na izbrano BAM rešitev je postopek implementacije podoben, saj temelji na SOA

ciklu: modeliranje, implementacija, izvajanje in nadzorovanje. Slika 3.2 prikazuje splošen

SOA življenjski cikel. [23]

Slika 3.2 Splošen cikel modeliranja z IBM orodji [23]


Za izdelavo praktičnega primera bomo uporabili rešitve podjetja IBM, ki jih bomo

podrobneje opisali kasneje. Slika 3.3 prikazuje IBM-ove produkte s SOA podporo za

izdelavo nadzornega modela.

Slika 3.3: Koraki SOA cikla z ustreznimi IBM produkti [23]


3.3 Najpomembnejše BAM rešitve v okolju SOA Na tržišču je že veliko BAM rešitev, ki v osnovi opravljajo enako funkcijo, do razlik pa

pride v razširljivosti in dodatnih funkcionalnostih. Glede funkcionalnosti David Luckham v

svojem članku The Beginnings of IT Insight: Business Activity Monitoring namreč pravi:

»Predvidevam, da če kupite osnovno BAM orodje in ga spravite v delovanje, ne bo trajalo

dolgo, preden se boste vprašali kaj vse še to orodje zmore.« [2] Nekatere BAM rešitve

lahko delujejo in so tudi razvite kot samostojne, vendar so take rešitve bolj izjema. Tak

primer predstavljajo rešitve podjetja Systar, ki se ukvarja le z BAM rešitvami. V praksi pa

so BAM rešitve najpogosteje bile dodane že obstoječi programski arhitekturi velikih

programskih hiš. Tako je npr. IBM dodal BAM rešitev v WebSphere, Oracle je BAM dodal

kot razširitev ponudbe svojega Application Server strežnika, Microsoft pa je BAM

funkcionalnosti vključil v svoj BizTalk strežnik. Na kratko bomo predstavili te

najpomembnejše BAM rešitve. Rešitev podjetja IBM bomo uporabili za izdelavo

praktičnega primera in ga tako tudi podrobneje opisali kasneje.

Oracle BAM 11g je glavna komponenta Oraclovega Fusion Middleware Suite, dogodkovne

arhitekture in SOA platform. Oracle BAM aplikacije omogočajo poslovnim uporabnikom

izdelavo poljubnih preglednih plošč brez potrebe po znanju programiranja. Čarovnik jih

korak po koraku vodi pri izdelavi KPI-jev in vseh ostalih meritev iz več izvorov hkrati.

Pregledne plošče dajejo pregled nad vsemi fazami procesov in podsistemi, kar omogoča

vizualni pregled nad nepravilnostmi v procesih. Ukrepanje je možno s pošiljanjem opozoril

ali samodejno dinamično spremembo v poslovnem procesu s pomočjo Oracle BPEL.

Oracle BAM je J2EE aplikacija izdelana na dogodkovni arhitekturi, ki temelji na sporočilih

in je naseljena v pomnilniku (angl. Memory-resident). Oracle v svoji brošuri navaja, da je

njegova rešitev prva in edina, ki omogoča vpogled v poslovne operacije v realnem času s

celovitim pogledom na poslovno situacijo z zgodnjim in pozornost zbujajočim

opozarjanjem. Uporabljene so zadnje tehnologije sporočanja, podatkovne integracije,

napredno shranjevanje v predpomnilnik, analitike, predvidevanj, opozarjanja in poročanja

za prikaz poslovnih informacij v trenutku ko se pojavi dogodek. Izvorne podatke lahko

črpa iz podatkovnih baz, sporočilnih sistemov, ki temeljijo na JMS (Java Message

Service), Oracle AQ in MQ, Oracle Data Integrator in iz spletnih storitev. Oracle BAM


lahko teče na operacijskih sistemih Windows, Linux in Unix. Podatke pa shranjuje v

podatkovni bazi Oracle Database 10g ali 11g. [28]

BAM rešitev podjetja Microsoft je vključena v njihov BizTalk strežnik. BizTalk je rešitev

za integracijo in povezovanje, kar organizacijam omogoča lažjo povezavo razpršenih

sistemov. Vključuje več kot 25 Adapterje za različne platforme in robustno sporočilno

infrastrukturo. Ti Adapterje olajšajo povezavo z glavnimi sistemi znotraj in izven

organizacije. Omogočajo enostavno povezavo s poslovnimi rešitvami drugih podjetij (kot

so npr. SAP, Oracle, IBM), podatkovnimi bazami (Microsoft SQL, Oracle Database, IBM

DB2). Podpora spletnim storitvam v BizTalk verzije 2009 vključuje tudi Microsoftov ESB

2.0 in UDDI v3. [27] BAM komponenta iz BizTalk strežnika pridobiva podatke za nadzor

poslovnih aktivnosti. Pred tem pa poslovni analitik mora pripraviti nadzorni model s

pomočjo BAM dodatka za Excel, razvijalec pa nadzorni model mapira z dejansko

implementacijo vseh rešitev, ki so zajete. Po prenosu in zagonu nadzornega modela na

strežniku, imajo poslovni uporabniki že na voljo pregledne plošče. Dostop do preglednih

plošč je mogoč preko: BAM Portal, Microsoft Excel, PerformancePoint Server, Microsoft

SQL Server Reporting Services storitev za poročila ali preko poljubnih, v ta namen razvitih

aplikacij. [25] Namestitev BizTalk strežnika je možna le na operacijski sistem Microsoft

Windows, uporablja pa podatkovno bazo Microsoft SQL Server. [26]

Med pomembnejše BAM rešitve spada tudi BusinessFactor podjetja TIBCO. TIBCO

Designer omogoča hiter razvoj nadzornih modelov. Deklarativna agregacija zmanjšuje

potrebo po pisanju SQL kode, grafični način in orodja za hitro vrednotenje pa zelo olajšajo

razvijanje. Business Factor Event Finder je dinamično okolje za iskanje dogodkov, ki

uporabnikom omogoča pregled in primerjavo podatkov na katerem koli nivoju, lokaciji ali

časovnem intervalu. Celotna rešitev podpira tehnologije kot so npr.: JMS, SOAP,

Microsoft Active Directory, Novell eDirectory in SUN ONE Directory. BusinessFactor je

lahko nameščen na operacijskih sistemih HP-UX, Solaris ali Windows. Teče na

aplikacijskem strežniku Tomcat ali WebLogic in uporablja podatkovno bazo Oracle ali

Microsoft SQL Server. [30]


4 IBM BAM REŠITVE IN DELOVANJE NADZORNEGA MODELA

4.1 IBM WebSphere

IBM WebSphere Business Monitor (v nad. Business Monitor) spada v IBM-ovo

WebSphere integrirano programsko platformo. Ta vsebuje vso potrebno vmesno

infrastrukturo, ki vključuje strežnike, storitve in orodja, ki omogočajo neprestano delovanje

poslovnih rešitev različnih področij. Osnova za poslovne aplikacije med katere spada tudi

Business Monitor je IBM WebSphere Application Server (v nad. Application Server), na

katerem tečejo ustrezni strežniki in aplikacije skupine WebSphere. Tak primer je IBM

WebSphere Process Server (v nad. Process Server), ki skupaj s storitvenim vodilom

WebSphere Enterprise Service Bus (ESB, v nad. WebSphere ESB) nudi temelj SOA

modularnim aplikacijam. Slika 4.1 prikazuje arhitekturo WebSphere platforme skupaj z

ustreznimi produkti.

Slika 4.1: Arhitektura IBM WebSphere platforme [7]

Business Monitor lahko nadzoruje poslovne dogodke iz katerekoli aplikacije. Dogodki iz

želene aplikacije so lahko posredovani v CBE dogodke s pomočjo uporabe produktov kot

so WebSphere Business Events, Web Services Notification, WebSphere Enterprise Service

Bus ali WebSphere Message Broker. CBE (Common Base Event) je IBM-ova


implementacija formata spletnih dogodkov (angl. Web Event Format, v nad. WEF). CBE je

del Common Event Infrastructure (v nad. CEI), ki nudi ogrodje za zajemanje dogodkov in

njihovo distribucijo različnim dogodkovnim prejemnikom. CEI je enoten skupek

programskih vmesnikov (Application programming language, kraj. API) in infrastruktura

za ustvarjanje, prenos, trajnost in distribucijo velikega razpona poslovnih, sistemskih in

spletnih dogodkov CBE formata. CBE definira standardno sporočilo, ki vsebuje

informacije o poslovnem dogodku, učinkovitosti in informacije za razreševanje napak. CEI

in CBE sta tako jedrni komponenti WebSphere produktov, ki nudita okolje za spremljanje

dogodkov. [8, 18, 19]

Aplikacije, katerih procesi bodo nadzorovani s pomočjo Business Monitor, lahko

nadgradimo tako, da bodo pošiljale ustrezne CBE dogodke, če tega še ne podpirajo.

Najboljša praksa pa je, da za obstoječe aplikacije, ki ne podpirajo CBE dogodkov,

pripravimo vmesne aplikacije, ki jih med seboj integrirajo. Gre za t.i. integracijske

aplikacije, ki poskrbijo za to, da lahko na koncu Business Monitor od njih pridobiva

podatke za delovanje nadzornega modela. Na ta način lahko nadzorujemo poslovanje ne le

na poslovnem ampak tudi procesnem vidiku. Za izdelavo nadzornega modela z IBM-ovimi

produkti potrebujemo IBM WebSphere Business Modeler (v nad. Business Modeler) in

IBM WebSphere Integration Developer (v nad. Integration Developer) z dodatkom IBM

WebSphere Business Monitor Toolkit. Nadzorni model nato lahko zaženemo in testiramo

v že pripravljenem testnem okolju, ki vsebuje poslovni spletni uporabniški vmesnik IBM

WebSphere Business Space. Po testiranju v testnem okolju lahko to poslovno aplikacijo

prenesemo na strežnik Process Server, kjer deluje skupaj s WebSphere Enterprise Service

Bus. Na kratko bomo vsak produkt posebej predstavili v nadaljevanju. Slika 4.2 prikazuje

cikel in posamezne faze razvoja poslovnih aplikacij in ustrezna WebSphere orodja.


Slika 4.2: Družina IBM WebSphere orodij razdeljena na posamezne faze razvoja nadzornega modela z medsebojnimi povezavami in tokovi [18]

4.1.1 IBM WebSphere Business Modeler Advanced V6.2

IBM WebSphere Business Modeler (v nad. Business Modeler) omogoča modeliranje,

analiziranje in simuliranje poslovnih procesov, kar pripomore k optimiziranju le-teh. S

pomočjo simulacije in z uporabo dejanskih podatkov lahko preučimo delovanje poslovnega

procesa v različnih scenarijih. Vizualizacija poslovnega procesa pa pomaga pri odkrivanju

ozkih grl in neučinkovitosti procesa. To orodje je torej namenjeno predvsem poslovnim

analitikom.

Uvozimo lahko že obstoječe modele poslovnih procesov ali podatkov, kot so na primer:

• Microsoft Excel preglednice (datoteke XLS)


• Microsoft Visio modeli (datoteke VDX)

• WebSphere Business Modeler XML datoteke

• WebSphere Business Modeler projekt (datoteke MAR)

• Poslovne storitve (datoteke WSDL) in objekti poslovnih storitev (datoteke XSD)

Na voljo je več načinov modeliranja, med katerimi lahko izbiramo. Osnovni način

omogoča prikaz poslovnih procesov na visokem nivoju za ustvarjanje in prikaz diagramov

zaporedja. Napredni način je namenjen določanju in pregledu dodatnih podrobnosti

procesov in podatkovnih modelov kot so poslovna pravila in logika modela. Ti dodatni

podatki so potem uporabljeni kot osnova pri implementaciji dejanskih programskih

aplikacij. Za nas pomemben je tudi WebSphere Process Server način modeliranja, saj je

namenjen izvozu modela kot SCA (Service Component Architecture) komponente in kot

BPEL (Business Process Execution Language), WSDL ali XSD (XML Schema Definition)

datoteke, ki jih potem lahko uvozimo v orodje Integration Developer, kjer jih lahko

uporabimo za izdelavo integracijskih aplikacij, ki jih potem lahko namestimo na Process

Server. BPEL je namreč dandanes postal standard za kompozicijo poslovnih procesov po

SOA načelih.

Modeliramo lahko naslednje dele poslovnih procesov: človeška opravila, definicije

poslovnih pravil, poslovne objekte (vse kar je v poslovnem procesu bilo ustvarjeno,

sestavljeno, testirano, spremenjeno, vse s čimer se je delalo), vire (sredstva), organizacijske

in strukturne modele. Prav tako pa že v tej fazi lahko definiramo poslovne meritve, ki jih

bomo spremljali s pomočjo Business Monitor. [10]

4.1.2 IBM WebSphere Integration Developer V6.2

Orodje IBM WebSphere Integration Developer temelji na Java razvojnem orodju Eclipse

(tako kot WebSphere Business Modeler). Namenjeno je razvoju BPM (Business Process

Management) rešitev, ki temeljijo na SOA ter integracijskih rešitev. Obstoječe IT rešitve

lahko uporabimo kot komponente in jih tako ponovno uporabimo, kar poveča uveljavitev


SOA v podjetju. Tako lahko poslovne procese modelirane z orodjem IBM WebSphere

BusinessMonitor, ki smo ga opisali prej, uporabimo tukaj kot poslovni model, ki mu

dodamo implementacijo in avtomatizacijo. Orodje razvijalcem omogoča sestavo

kompleksnih poslovnih rešitev z uporabo pripravljenih komponent in vizualnih

urejevalnikov. Ob tem pa so uporabljeni vmesniki in sheme predstavljene s WSDL in

XSD, ki sta W3C (World Wide Web Consortium – mednarodna organizacija za spletne

standarde) standarda in veljata tudi za industrijski standard.

Pri razvoju je mogoče uporabiti:

• Adapterje, ki poskrbijo za povezavo na druge sisteme kot so podatkovne baze in

sistemi za načrtovanje virov v podjetju.

• Mediacijske tokove, ki transformirajo in usmerjajo sporočila.

• WebSphere Service Registry & Repository servisni register in repozitorij nudita

orodju Integration Developer storitve, ki so potrebne za izdelavo integracijske

aplikacije. Prav tako pa skrbita, da so storitve dostopne vsem poslovnim rešitvam v

podjetju.

• Vizualna orodja pripomorejo k temu, da razvijalci integracijskih aplikacij

potrebujejo le minimalno znanje o sistemu, za katerega delajo integracijsko

aplikacijo, saj lahko komponente s principom potegni in spusti (angl. Drag and

drop) hitro ustvarijo tokove zaporedja in poslovnih procesov. S pomočjo vizualnih

orodij se prav tako zmanjša pisanje Java kode, saj jih lahko uporabimo tudi za

človeška opravila, poslovne stroje, poslovna pravila, podatkovne povezave in

ostale komponente.

Integracijske aplikacije narejene v WebSphere Integration Developer lahko namestimo na

dva strežnika in sicer na WebSphere Process Server, ki je glavni strežnik za te aplikacije.

Na njem se izvajajo skupaj z aplikacijami, ki vsebujejo poslovne procese in adapterje.

Medtem pa strežnik WebSphere Enterprise Service Bus skrbi za komponente mediacijskih

tokov, kjer so prav tako na voljo Adapterje, ki olajšajo medsebojno povezovanje. Ta


strežnik deluje na nivoju infrastrukture, ki uporablja mediacijske tokove za pretvorbo,

usmerjanje in povečevanje sporočil med neodvisnimi SCA komponentami. [18]

4.1.3 IBM WebSphere Business Monitor Development Toolkit V6.2

IBM WebSphere Business Monitor Development Toolkit je dodatek k prej opisanemu

orodju WebSphere Integration Developer, ki omogoča vizualno ustvarjanje nadzornih

modelov s pomočjo priloženih knjižic, čarovnikov in testnega okolja. Nadzorni model

lahko naredimo s pomočjo definicije dogodkov ali pa uporabimo že narejen BPEL model

in mu dodamo nadzorna merila, katerih podrobnosti so predstavljene kot XML dokument,

ki ga je možno urejati tudi v vizualnem načinu. Uporabimo lahko vsa podrobna nadzorna

merila kot so KPI, podatkovna skladišča, vizualne in dogodkovne modele s pomočjo

katerih lahko potem generiramo izvedljivo aplikacijo in jo preizkusimo v testnem okolju.

Prednost testnega okolja je v tem, da lahko takoj preizkusimo delovanje našega nadzornega

modela na delujočem poslovnem procesu, za kar ne potrebujemo namestitve strežnikov in

orodij Process Server, Business Space, podatkovne baze in Business Monitor Server, kot je

to zahtevano za končno delovanje te celote v podjetju. Več o samem nadzornem modelu

bomo napisali v nadaljevanju. [15, 21]

4.2 Nadzorni model

Nadzorni model vsebuje nadzorne kontekste, ki določajo, kako bomo nadzorovali poslovne

aktivnosti. Definira tipe informacij, ki jih bomo pridobili iz poslovnih aktivnosti in kako

jih bomo obdelali, da nam bodo pokazale učinkovitost poslovanja.

Za učinkovito merjenje poslovne uspešnosti je pomembna izbira nekaj najpomembnejših

dejavnikov, ki so ključni za poslovanje podjetja. Najprej je potrebno določiti poslovne cilje

in poslovne meritve, s katerimi lahko ugotavljamo trenutno uspešnost. Primeri takih

poslovnih meritev so finančni podatki, časovno odvisni podatki, meritve pretoka ali


indikatorji uspešnosti. Nato je potrebno ugotoviti, kateri poslovni dogodki vsebujejo

potrebne podatke za izračun teh poslovnih meritev. Takšni dogodki v praksi ponavadi

vsebujejo npr. obvestila o prispetju, obvestila o dostavi in obvestila o stanju v skladišču. Ti

podatki lahko pridejo iz samega izvajanja poslovnih procesov, poslovnih aplikacij in

drugih sistemov. Te pridobljene podatke uporabimo za preračunavanje poslovnih meritev s

pomočjo katerih izdelamo nadzorni model. Postopek izdelave nadzornega modela bomo

opisali kasneje skupaj z izdelavo praktičnega primera nadzornega modela. [13, 21]

4.2.1 Delovanje nadzorovanja poslovnih procesov

Vsa komunikacija znotraj nadzornega konteksta je obravnavana z dogodki. Za vsak

nadzorovan objekt v realnosti se ustvari programski objekt imenovan nadzorni kontekst

(angl. monitoring context). Programski objekt pridobi podatke o spremembah stanja

realnega objekta. Le-ti vsebujejo parametre za poslovne meritve, ki opisujejo učinkovitost

poslovanja, katerega nadzorujemo v realnem času. Poslovne meritve pa imajo v praksi

ponavadi več entitet, ki se nanašajo na instance realnega procesa in jim je zato potrebno

dodeliti unikaten indeks. Ponavadi je določen z vrednostjo, ki se nanaša na posamezno

instanco, kot je npr. čas in kraj prihoda taksija v primeru prevozov s taksijem ali pa

številka naročila. Nadzorni kontekst grupira vse poslovne meritve v eno skupino, ki opisuje

stanje objekta v realnosti, kot je npr. določeno naročilo ali prevoz s taksijem, ki ga

nadzorujemo z več poslovnimi meritvami hkrati. Nadzorni kontekst je ustvarjen in obstaja

tako dolgo, dokler traja dogodek, ki ga nadzorujemo. V našem primeru bi kontekst obstajal

od začetka naročila za prevoz s taksijem, kar je označeno z dogodkom Process Started

(proces zagnan) in vse do opravljenega prevoza s taksijem, ko taksist odloži stranko na

želenem mestu označeno z dogodkom Task Completed (naloga opravljena), po končanju te

instance pa sledi še dogodek Process Ended (proces končan). V primeru, ko čas od zagona

procesa do opravljene naloge presega določeno mejo, lahko sprožimo dogodek Process

Delayed (zakasnjen proces). Vse te aktivnosti so torej določene v nadzornem modelu, ki jih

uporablja Business Monitor, katerih definicije nadzornega konteksta določajo vhodne in

izhodne dogodke, poslovne meritve in prožilce za poslovne situacije. [14]


Postopek delovanja nadzornega modela :[14]

1. Nalaganje nadzornega modela

WebSphere Business Monitor strežnik ob zagonu naloži nadzorni model, ki definira

njegovo konfiguracijo. Vsebuje lahko eno ali več definicij nadzornega konteksta.

2. Čakanje

Naložen nadzorni model čaka na dve situaciji in sicer na vhodni dogodek ali na

presežen čas. V primeru, ko se pojavi vhodni dogodek, je dostavljen do vseh

instanc nadzornega konteksta, katerim se spremeni stanje. Sprožijo se določeni

prožilci, na koncu se pa te instance zaključijo in postopek se vrne nazaj na čakanje.

Vsi ti vmesni koraki (3., 4., 5., 6. in 7.) so podrobneje opisani v nadaljevanju. Ko je

čas čakanja na vhodni dogodek presežen, se sprožijo prožilci (6. korak) in

spremenijo stanja njihovih učinkov, zaključijo se vse potrebne instance in postopek

se vrne na čakanje. Korak 6 se torej izvrši v vsakem primeru.

3. Iskanje ustreznih naročnin na vhodne dogodke

Business Monitor poišče vse ustrezne t.i. naročnine na vhodne dogodke (angl.

Event Subscriptions) v vseh zagnanih nadzornih modelih. Naročnine na dogodke so

definirane skozi dogodkovne tipe na vstopni točki dogodka v definiciji nadzornega

konteksta. Vsi dogodki, ki ustrezajo pogojem za vstopni dogodek, so skozi vstopne

točke podani instancam nadzornega konteksta. Za podajanje dogodkov k ustrezni

instanci skrbi naslednji korak.

4. Iskanje soodvisnih instanc nadzornega konteksta

Vsak vhodni dogodek se ovrednoti za vsako instanco nadzornega konteksta z

naslednjimi možnimi rezultati: nič, eno ali več ujemanj. Za te rezultate je

definiranih več možnih dejanj: dostavi ujemajoči se instanci, dostavi vsaki

ujemajoči se instanci, dostavi katerikoli ujemajoči se instanci, ustvari novo

instanco, obravnavaj kot napako ali prezri dogodek.

5. Osvežitev ključa in vrednosti metrik

Vsi izrazi, ki so odvisni od vhodnih dogodkov se preračunajo, vrednosti njihovih

ciljnih metrik pa osvežijo. Izrazi, katerih vhodne vrednosti so odvisne od metrik, ki


so bile spremenjene, se iterativno preračunajo. To si lahko predstavljamo kot

računsko formulo, kjer sprememba ene spremenljivke vpliva na rezultat.

6. Proženje procesov

Prožilci, ki so bili aktivirani s strani vhodnih dogodkov, sprememb metrik ali

preseženega časa čakanja, so v tem koraku pregledani, kateri se dejansko sprožijo.

V primeru sprememb metrik se lahko sprožijo novi prožilci in tako se 5. in 6. korak

ponavljata, vendar nadzorni model ne sme vsebovati cikličnih odvisnosti, saj se

postopek stopnjevanja mora končati v omejenem številu korakov. Na koncu se vse

instance nadzornih kontekstov zaključijo, tako da so vsi prožilci označeni za

končanje in so končani, ko se vsi procesi in njihovi koraki zaključijo.

7. Pošiljanje izhodnih dogodkov

Če nadzorni model vsebuje izhodne dogodke, se le-ti na koncu pošljejo spet na 2.

korak, če so primerni glede na stanje procesa.


Postopek delovanja nadzornega modela ponazarja Slika 4.3.

Slika 4.3: Delovanje nadzornega modela [14]


5 PRAKTIČNI PRIMER

5.1 Opis

Učinkovitost in funkcionalnosti BAM bi najlažje predstavili z realnim primerom

poslovnega procesa in realnimi podatki poslovnih dogodkov. Vpeljava BAM v podjetju

zahteva skrbno načrtovanje in sodelovanje vodstva in ostalega osebja s IT strokovnjaki in

je dolgo časa trajajoči projekt, kar predstavlja omejitev pri preučevanju praktičnega

primera. Poleg tega pa bi s podrobnostmi poslovanja lahko razkrili poslovne skrivnosti. Iz

teh razlogov smo za praktični primer izbrali namišljeno podjetje, katerega poslovni proces

bo zadostoval za izdelavo nadzornega modela, ki bo lahko prikazal glavne značilnosti

BAM.

Za izdelavo nadzornega modela smo si zamislili podjetje, ki opravlja taksi prevozne

storitve v večjem mestu. S pomočjo BAM želi povečati dobiček ter učinkovitost in sicer

tako, da bo spremljalo tekoče stroške in le-te skušalo znižati.

V osnovi bo spremljanje posameznega prevoza vključevalo naslednje podatke:

• Identifikator (v nad. ID) prevoza

• Ime in priimek voznika

• Ime in priimek stranke, če gre za telefonsko naročilo

• Začetni naslov

• Končni naslov

• Začetno stanje števca prevoženih kilometrov

• Končno stanje števca prevoženih kilometrov

• Število potnikov

• Predviden začetni čas

• Čas prihoda voznika na začetni naslov


• Ali je bilo naročilo preko telefona ali je voznik pobral stranko spontano na ulici

• Porabljeno gorivo, ki predstavlja neposredni strošek

S pomočjo teh osnovnih podatkov bomo lahko spremljali naslednje meritve:

• S pomočjo naslovov bo mogoče ugotoviti, v katerem mestu ali celo v katerem

predelu mesta je mogoče pridobiti največ strank

• S številom zasedenosti sedežev bo razvidno ali je potreba po vozilih z večjim

številom sedežev

• Z razliko med začetnim in končnim časom posameznega prevoza je razviden čas

vožnje, z razliko stanja števca na začetku in stanja števca na koncu prevoza pa

prevožena razdalja. S pomočjo obeh skupaj pa bo lažje oblikovanje cen storitev.

• V primeru, ko je bilo naročilo izvedeno preko telefona in stranka določi začetni

čas, lahko v primerjavi z dejanskim časom začetka prevoza ugotovimo ali je prišlo

do zamude ali pa je voznik prišel na začetni naslov pravočasno.

• Podatki o porabljenemu gorivu, ki predstavlja neposredni strošek, bodo pomagali

pri odločitvi nabave novih vozil oz. o morebitni zamenjavi trenutnih vozil z bolj

ekonomičnimi vozili. V kombinaciji s podatki o povprečnih prevoženih kilometrih

na teden/mesec lahko tudi predvidimo stroške vnaprej.

Vse ostale meritve bomo opisali pozneje v kombinaciji z dogodki.

Za osnovno delovanje nadzornega modela bomo tako potrebovali nekaj dogodkov, na

katere se bomo sklicevali. Recimo, da ima naše podjetje kontrolorja, ki sprejema naročila

po telefonu in jih sporoča voznikom, prost voznik pa lahko dobi stranko spontano na ulici

in to sporoči kontrolorju, tako da ima le-ta pregled nad zasedenostjo vozil. Vsak začetek

naročene vožnje bomo obravnavali kot dogodek, s katerim bomo imeli pregled o

posamezni vožnji. Naslednji dogodek bo takrat, ko voznik pobere stranko in prične s

prevozom. Kot zaključek vožnje pa bo predstavljal prihod na cilj in izstop stranke.


5.2 Izdelava nadzornega modela

Nadzorni model smo izdelali s pomočjo prej opisanega orodja IBM WebSphere Integration

Developer V6.2 in dodatkom IBM WebSphere Business Monitor Development Toolkit

V6.2. Najprej je bilo potrebno ustvariti Business Monitoring projekt, ki vsebuje definicijo

dogodkov (angl. Event definition), nadzorni model (angl. Monitoring Model) in SVG

(Scalable Vector Graphics) datoteke, ki so razdeljeni vsak v svojo mapo.

Za izdelavo nadzornega modela najprej potrebujemo poslovne procese oz. dogodke, ki jih

bomo nadzorovali. Iz delujočega BPEL modela bi lahko generirali nadzorni model, saj ta

že vsebuje posamezne korake delovanja samega poslovnega procesa in podatke, ki se v

procesu uporabljajo. Tako bi lahko pridobivali podatke o poslovnem procesu v vsakem

želenem koraku. Ker pa v našem primeru nismo imeli pripravljenega BPEL modela, smo

izdelali definicijo dogodkov. Definicija dogodkov je v bistvu XSD shema za dogodke, ki

so zapisani v XML formatu. Definicija dogodkov tako vsebuje dogodkovne elemente in

njihove tipe podatkov, na katere se bomo sklicevali pri izdelavi nadzornega modela.

5.2.1 Definicija dogodkov

Naš primer vsebuje naslednje dogodkovne elemente: naročilo taksija (narociloTaxija),

vstop (vstopStranke) in izstop stranke (izstopStranke). Definirati moramo tudi vse tipe

podatkov, ki jih bomo uporabljali v našem nadzornem modelu. Ti tipi so lahko osnovni ali

kompleksni tipi, ki so sestavljeni iz osnovnih tipov in jih definiramo sami. Tako smo za

naš primer naredili glavni tip TaxiDogodek, ki vsebuje podatka osnovnega tipa idTaxija in

casDogodka ter podrobne podatke o samem vozilu podatkiVozila, ki je kompleksni tip

Vozilo, sestavljen iz naziva in povprečni porabi vozila. Podrobne podatke o vozilu bi lahko

predstavili tudi kot osnovne tipe, vendar smo ga zaradi možnosti naknadne razširitve

definirali kot samostojni tip. Ker se posamezna vožnja nanaša na posamezno vozilo, smo

glavni tip TaxiDogodek razširili s tipom NarociloDogodek, ki tako deduje vse njegove

podatke, sam pa vsebuje ID naročila, podatke o vozniku, podatke o stranki, začetni in

končni naslov, začetno in končno stanje števca, število potnikov, predviden začetni čas, čas


prihoda voznika in podatek o tem ali je bilo naročilo sprejeto po telefonu ali ne. Vsi

podatki so osnovnega tipa razen začetnega in končnega naslova, ki je kompleksnega tipa

Naslov in vsebuje ime ulice, hišno številko ter ime mesta oz. predela mesta. Slika 5.1

prikazuje vizualni pregled nad definicijo dogodkov in pripadajoče tipe v orodju Business

Modeler.

Slika 5.1: Grafični pregled na elementi in tipi definicije dogodkov


Slika 5.2 prikazuje definicijo vseh tipov, ki jih bomo uporabili pri izdelavi nadzornega modela.

Slika 5.2: Definicija tipov

5.2.2 Naročanje na dogodke

Po definiciji dogodkov ustvarimo nadzorni model, ki lahko vsebuje enega ali več

nadzornih kontekstov. V našem primeru smo edini nadzorni kontekst poimenovali

TaxiPrevoz MC, kjer bomo definirali vse potrebno za delovanje nadzornega modela,

najprej pa naročnine na dogodke, katerih definicijo smo naredili v prejšnjem koraku.

Naročnine na dogodke smo omenili že pri opisu samega delovanja nadzornega modela. V

naslednjem koraku izdelave nadzornega modela moramo te naročnine na dogodke tudi

definirati. Dogodki namreč predstavljajo edin neposredni vnos vhodnih podatkov iz

nadzorovane entitete v nadzorni model. Ker pa je v nadzorovani entiteti lahko veliko

različnih tipov dogodkov, moramo narediti naročnino le na tiste dogodke, ki so potrebni za


obdelavo. Ko nadzorni kontekst prejme dogodek, najprej preveri tip tega dogodka. V ta

namen obstajajo v prvem koraku filtri, s pomočjo katerih določimo, kaj se zgodi, ko pride

do določenega dogodka. V našem primeru so to filtri za tri dogodke: narociloTaxija,

vstopStranke in izstopStranke. V drugem koraku pa je za ustrezen dogodek potrebno

definirati še korelacijski izraz (angl. Correlation expression) oz. izraz soodvisnosti. S tem

izrazom ugotovimo, katere instance so relevantne za ta dogodek, ki je prišel skozi filter.

Možni so trije rezultati korelacijskega izraza in sicer: izraz se ne ujema z nobeno instanco,

izraz se ujema z eno instanco in izraz se ujema z več instancami. Za vsakega od teh

rezultatov lahko potem določimo ustrezno akcijo, ki so opisane spodaj: [12]

• Izraz se ne ujema z nobeno instanco:

o Ignoriraj in ne naredi ničesar, obnašaj se kot da se dogodek ni zgodil

o Obravnavaj kot napako in vrni sporočilo o napaki – zgodi se, ko nekdo želi

nekaj narediti na nečem, kar ne obstaja

o Ustvari instanco – na ta način se ustvarjajo nove instance konteksta

o Ponovi preverjanje – lahko se zgodi, da hoče ta dogodek poslati akcijo

obstoječi instanci, vendar le-ta še ne obstaja. Na strežniku se namreč lahko

dogodki pojavijo v različnem sosledju, kot so dejansko nastali. Strežnik tako

ohrani ta dogodek in ga ponovno pošlje kasneje, ko obstaja možnost, da

ciljna instanca takrat že obstaja.

• Izraz se ujema z eno instanco:

o Ignoriraj in ne naredi ničesar, obnašaj se, kot da se dogodek ni zgodil.

o Obravnavaj kot napako in vrni sporočilo o napaki – zgodi se v primeru, ko

želimo ustvariti eno in isto instanco večkrat.

o Dostavi instanci – ko najdemo ustrezno instanco, lahko obdelamo ta

dogodek.

• Izraz se ujema z več instancami:

o Ignoriraj in ne naredi ničesar, obnašaj se, kot da se dogodek ni zgodil.

o Obravnavaj kot napako in vrni sporočilo o napaki – zgodi se, ko je ta

dogodek namenjen eni ali nobeni instanci.


o Dostavi katerikoli instanci – dogodek dostavimo le eni instanci pri čemer ni

pomembno, točno kateri instanci je bila dostavljena.

o Dostavi vsem instancam – vse ustrezne instance obdelajo dogodek.

Definicijo dogodkov smo že ustvarili, sedaj pa jo moramo še povezati z dogodki na našem

nadzornem modelu. Tu so vsi dogodki v IBM Common Base Event (v nad. CBE) formatu,

za dostop do njihove vsebine pa so uporabljeni XPath izrazi. Tako moramo vhodne

dogodke v nadzornem modelu povezati z dogodki v definiciji dogodkov, pri čemer lahko

podamo poljubno okrajšavo za to povezavo, v našem primeru vsebina. Tabela 5.1 prikazuje

poti povezav vhodnih dogodkov našega primera z definicijo dogodkov.

Tabela 5.1: Povezava med definicijo dogodkov in vhodnimi dogodki nadzornega modela

Ime vhodnega dogodka Okrajšava povezave Tip dogodka

voziloPoslano Vsebina tns:narociloTaxija

strankaPobrana Vsebina tns:vstopStranke

strankaOdlozena Vsebina tns:izstopStranke

Sedaj, ko imamo urejeno povezavo do definicijo dogodkov, je potrebno definirati že prej

opisane filtre in korelacijske izraze. Slika 5.3 prikazuje uporabniški vmesnik izdelave

nadzornega modela s prikazom lastnosti vhodnega dogodka voziloPoslano.


Slika 5.3: Uporabniški vmesnik nadzornega modela in prikaz lastnosti vhodnega dogodka voziloPoslano

V Tabela 5.2, Tabela 5.3 in Tabela 5.4 so definicije filtrov in korelacijskih izrazov za vse

tri dogodke našega primera.

Tabela 5.2: Definicija vhodnega dogodka voziloPoslano

Vhodni dogodek voziloPoslano Filter fn:exists(voziloPoslano/vsebina/tns:idTaxija) Korelacijski izraz voziloPoslano/vsebina/tns:IdNarocila = Prevoz_Key Izraz se ne ujema z nobeno instanco Ustvari novo instanco Izraz se ujema z eno instanco Obravnavaj kot napako Izraz se ujema z več instancami Obravnavaj kot napako


Filter preveri ali je tip vhodnega dogodka ustrezen, torej če obstaja v naši definiciji

dogodkov. Za identifikacijo ustrezne instance pa potrebujemo unikaten ključ, zato ima

vsak nadzorni kontekst svoj ključ, v našem primeru poimenovan Prevoz_key, ki smo ga

povezali z IdNarocila v definiciji dogodkov. Tako se ob vsakem vhodnem dogodku tipa

voziloPoslano preveri še ključ in se ustvari nova instanca s tem ključem kot ID instance.

Tabela 5.3: Definicija vhodnega dogodka strankaPobrana

Vhodni dogodek strankaPobrana Filter fn:exists(strankaPobrana/vsebina/tns:idTaxija) Korelacijski izraz strankaPobrana/vsebina/tns:idTaxija = voziloID Izraz se ne ujema z nobeno instanco Obravnavaj kot napako Izraz se ujema z eno instanco Dostavi instanci Izraz se ujema z več instancami Obravnavaj kot napako

Tabela 5.4: Definicija vhodnega dogodka strankaOdlozena

Vhodni dogodek strankaOdlozena Filter fn:exists(strankaOdlozena/vsebina/tns:idTaxija) Korelacijski izraz strankaOdlozena/vsebina/tns:idTaxija = voziloID Izraz se ne ujema z nobeno instanco Obravnavaj kot napako Izraz se ujema z eno instanco Dostavi instanci Izraz se ujema z več instancami Obravnavaj kot napako

Posamezni prevoz lahko opravi le eno vozilo hkrati, zato vsako naročilo predstavlja svojo

instanco. Tako se pogoj filtra pri dogodkoma strankaPobrana in strankaOdlozena nanaša

na ID vozila. Ko se pojavita dogodka teh tipov, ju le dostavimo ustrezni instanci.

5.2.3 Definiranje metrik

Metrike so meritve podatkov, ki jih pridobimo iz vhodnih dogodkov. Neposredno lahko od

dogodkov pridobivamo le tiste tipe podatkov, ki so definirani v definiciji dogodkov. Te

podatke lahko potem obdelamo. Pri tem je možno uporabiti aritmetične in/ali logične

operatorje ter vgrajene funkcije za delo z vsemi osnovnimi podatkovnimi tipi, kot so npr.

in, ali, večje/manjše, povprečje, ali niz vsebuje določen podniz itd. Uporabimo lahko tudi


podatke iz drugih metrik. Izraze za izračun vrednosti metrik določimo v njihovi definiciji,

kjer lahko temu izrazu določimo tudi prožilec (angl. Trigger). Prožilce lahko definiramo

tako, da se sprožijo le v določeni situaciji in tako se tudi izračun vrednosti izvede le v

določeni situaciji in ne ob vsakem pojavu instance dogodka, iz katerega beremo podatke.

Slika 5.4 prikazuje ponujeno pomoč ob definiciji izraza za vrednost metrike, ki pokaže

naše definirane podatke, vnaprej definirane podatke, operacije, funkcije in vrednosti drugih

že definiranih metrik, s katerimi lahko po želji obdelamo podatke.

Slika 5.4: Podatki in operacije, ki jih lahko uporabimo za izračun vrednosti metrik


Poleg samega izraza za vrednost metrik moramo določiti tudi njihov tip podatkov, lahko pa

določimo tudi ali je vrednost vedno zahtevana za to metriko, njeno privzeto vrednost in ali

bomo to metriko uporabili za sortiranje. Tabela 5.5 prikazuje ime, opis, tip in izraz za

vrednost metrik, ki smo jih definirali za naš primer.


Tabela 5.5: Definicija metrik




Z vrednostnimi izrazi za metrike smo naredili povezavo med vhodnimi dogodki in samimi

metrikami. Ta povezava je poimenovana mapiranje, kar ponazarja Slika 5.5.

Slika 5.5: Mapiranje

Ker lahko v tej definiciji uporabljamo tudi medsebojne vrednosti metrik, obstaja omejitev v

urejevalniku, ki zahteva, da so te medsebojne odvisnosti med matrikami ne smejo pojaviti

v ciklih. To pomeni, da če je ena metrika odvisna od druge, ne more ta druga biti odvisna

od prve. Druga omejitev je ta, da se ena metrika lahko nanaša le na en dogodek hkrati, saj

se tudi dogodki ne zgodijo vsi hkrati. Pri tem nam je v pomoč vgrajeni pogled v

urejevalniku imenovan nadzorni tok (angl. Monitoring Flow), ki prikazuje povezave med

dogodki in metrikami ter njihovimi medsebojnimi odvisnostmi, kar prikazuje Slika 5.6.


Slika 5.6: Povezava med dogodki in metrikami ter njihova soodvisnost v pogledu nadzornega toka

Poleg metrik bi lahko nadzornemu modelu dodali še prej omenjene prožilce, katerim

določimo pogoj, v kateri situaciji naj se sprožijo; števce, katerim podamo vhodni dogodek

ali prožilec, in ti štejejo, kolikokrat se je ta dogodek ali prožilec pojavil; štoparice, ki


merijo čas med pojavitvijo dogodka in izhodne dogodke. V našem primeru bi lahko

uporabili štoparice, le-te pa upoštevajo dejanski čas pojava dogodka. Mi pa bomo uporabili

namišljene testne podatke in jih poslali zaporedno v kratkem času, tako da pridejo nekatere

funkcionalnosti bolj do izraza na realnem primeru kot pa na našem namišljenem primeru.

Iz tega razloga smo npr. za izračun trajanja vožnje uporabili vnesene testne podatke o času

začetka in konca vožnje in ne dejanski čas, ko sta se ta dva dogodka pojavila v nadzornem

kontekstu. Z razliko teh dveh časov bomo izračunali čas v metriki, namesto da bi uporabili

štoparico, ki bi upoštevala dejanski čas. [16]

5.2.4 Definiranje KPI

Ključni kazalniki učinkovitosti KPI so merljivi kazalniki uspešnosti poslovanja podjetja.

Pri definiranju KPI-jev lahko določimo ciljno vrednost, ki jo želimo doseči in različna

območja trenutnega stanja ali oboje. Izberemo lahko med dejansko ali procentualno ciljno

vrednostjo. Tako je v našem primeru cilj podjetja čim več oz. v idealnem primeru 100%

pravočasnih prihodov voznikov na začetni naslov za naročila preko telefona. Za večjo

preglednost lahko trenutno stanje razdelimo na različna območja. Tako smo v našem

primeru razdelili odstotek pravočasnih prihodov voznikov na cilj na tri območja in sicer:

zelo dobro (80-100%), sprejemljivo (60-80%) in kritično (0-60%). Prav tako lahko kasneje

glede na ta območja definiramo prožilce za opozorila. Za ta primer KPI-ja bomo kasneje

definirali opozorilo, ki se bo poslalo takrat, ko bo odstotek pravočasnih prihodov padel v

kritično območje. Za izračun KPI-jev lahko pridobimo skupek vrednosti iz metrik ali

uporabimo vrednosti KPI-jev med seboj. V realnem primeru bi KPI-je definirali skupaj z

vodstvom, ki določi najpomembnejše kazalnike. V našem primeru smo definirali nekaj

primerov za prikaz principa delovanja le-teh.

V urejevalniku KPI modela najprej ustvarimo nov KPI kontekst, ki smo ga v našem

primeru poimenovali Taxi KPI Context. Znotraj konteksta tako dodamo KPI-je, ki jim

določimo ime, tip podatkov (decimalno število ali trajanje), lahko uporabimo prikaz

vrednosti kot odstotke, ali pa prikažemo kot denarno valuto. Vrednosti lahko shranjujemo

za kasnejši pregled zgodovine le-teh in za pomoč pri izračunu napovedi oz. predvidevanj v


prihodnosti. Določimo cilj h kateremu strmimo s KPI-jem in razpone vrednosti. Za večjo

preglednost lahko razponom določimo tudi barvo prikaza v grafikonu na pregledni plošči.

Najpomembnejša je izbira metrike, iz katere bomo prebrali skupek vrednosti in izbira

agregacijske funkcije. Agregacijske funkcije, med katerimi lahko izbiramo so naslednje:

največja in najmanjša vrednost, povprečje, število pojavitev, vsota in razlika. Časovni filter

omogoča izbiro časa, kdaj naj se vrednost tega KPI-ja izračuna, s pomočjo podatkovnega

filtra pa izberemo le tiste podatke, ki so pomembni za izračun. Ob izračunu KPI-ja s

pomočjo vrednosti drugih KPI-jev, pa sami definiramo izraz za izračun le-tega. V ta namen

imamo definirane pomožne KPI-je, ki jih bomo uporabili le v pomoč za izračun končnih

KPI-jev in jih ne bomo prikazovali v pregledni plošči. Slika 5.7 prikazuje KPI urejevalnik

z lastnostmi enega od njih, ki predstavlja odstotek zamujenih prihodov voznikov na začetni

naslov. Izračunali smo ga s pomočjo količnika pomožnega KPI-ja Število zamujenih

prihodov in Število telefonskih naročil. Tabela 5.1 vsebuje definicije vseh KPI-jev, ki smo

jih definirali za naš nadzorni model.

Slika 5.7: KPI urejevalnik s prikazom lastnosti


Tabela 5.6: Definicija KPI






5.2.5 Definiranje dimenzijskega modela

Dimenzionalna analiza (angl. Dimensional analysis) je pogosto uporabljena metoda v

raznih znanstvenih panogah za preverjanje verodostojnosti izračunov in meritev.

Dimenzija predstavlja abstrakcijo merske enote oz. količine. Tako kot npr. za fizikalno

količino hitrosti predstavljata dimenzijo čas in razdalja. [33] Tudi nadzornemu modelu

lahko dodamo dimenzije za lažje razumevanje in analizo merjenih podatkov, saj jih s tem

razdelimo na manjše dele.

Za definiranje dimenzijskega modela najprej potrebujemo t.i. kocko (angl. Cube), ki

predstavlja večdimenzionalni model. Kocka se samodejno ustvari ob kreiranju nadzornega

konteksta, ali pa jo dodamo sami. Kocka vsebuje definicijo, kako so shranjeni podatki

pridobljeni od instanc nadzornega modela. Za dostop do teh podatkov moramo poleg IBM

Business Monitor imeti nameščen še IBM DB2 Alphablox (v nad. Alphablox). Alphablox

vpelje pomembne poslovne informacije in analize v poslovni proces. To omogoča

določanje glavnih vzrokov zmanjšanja poslovnega uspeha, tako da se poglobimo v

podatke, ki temeljijo na opravilih in vlogi dela. Tako lahko učinkovito vključimo analitska

orodja v obstoječe spletne aplikacije.[6] Za prikaz podatkov dimenzijskega modela bomo v

pregledni plošči uporabili pregledovalnik dimenzij (angl. Dimensions) in poročil (angl.

Reports).

Kocki definiramo dimenzije in njihove nivoje (angl. Levels) ter meritve (angl. Measures).

Dimenzije so hierarhično razdeljene na enega ali več nivojev, ki vsebujejo njihove atribute.

Za primer vzemimo čas trajanja nekega dogodka, saj lahko čas po nivojih razdelimo na

leta, mesece, dneve, minute, sekunde itn., npr. naslov pa lahko razdelimo na celino, državo,

regijo, mesto in ulico. V urejevalniku dimenzijskega modela dodamo dimenzije, ki jim

podamo ime in želene nivoje. Nivoju pa določimo metriko, ki predstavlja ta nivo. Podamo

tudi meritve, ki predstavljajo kalkulacije na podlagi vsebine metrik. Meritvi določimo

agregacijsko funkcijo kot je povprečna vrednost, vsota vrednosti, minimalna ali

maksimalna vrednost, ki opravi kalkulacijo nad izbrano metriko. Privzeto je dodano merilo

InstancesCount, ki vrne število vseh instanc.


Podatki dimenzijskega modela so na pregledni plošči prikazani v tabelah in grafikonih in

sicer kot razmerje med meritvami in dimenzijami. Tako lahko npr. na grafikonu izberemo

katera dimenzija predstavlja os X in katera meritev predstavlja os Y. Meritve, definirane v

dimenzijskem modelu pa lahko uporabimo tudi v prikazu poročil, kjer je uporabljen le en

tip dimenzije tj. čas nastanka instance (angl. Creation Time).[17] Slika 5.8 prikazuje

definiran dimenzionalni model za naš nadzorni kontekst.

Slika 5.8: Dimenzijski model

Recimo, da želimo za naš primer analizirati podatke o prevozih glede na mesto, kjer je

voznik pobral stranke in podatke o prevozih, ki jih je opravil določen voznik. Tako smo

ustvarili dimenziji Voznik in Naslov, vsako z ustreznim nivojem in njegovo metriko. Za ti

dve dimenziji, in kasneje v poročilu tudi za dimenzijo časa, nas zanimajo naslednje

meritve: vsota potnikov, povprečno število potnikov, povprečno porabljeno gorivo in


povprečno prevožena razdalja. Definicijo dimenzij in pripadajočih nivojev prikazuje

Tabela 5.7, definicijo meritev pa Tabela 5.8.

Tabela 5.7: Definicija dimenzij in pripadajočih nivojev

Ime dimenzije Ime nivoja Metrika Naslov Mesto Mesto Voznik Ime in priimek voznika Voznik

Tabela 5.8: Definicija meritev za dimenzijski model

Ime meritve Metrika Agregacijska funkcija Vsota potnikov Št. potnikov Vsota Povprečna poraba Porabljeno gorivo Povprečje Povprečno število potnikov Št. potnikov Povprečje Povprečna razdalja Prevožena razdalja Povprečje

Po končani definiciji dimenzionalnega modela smo končali z izdelavo našega nadzornega

modela. Sledi generiranje delujoče aplikacije, njen prenos na testni strežnik, pošiljanje

testnih dogodkov in pregled rezultatov.

5.3 Zagon in testiranje nadzornega modela

5.3.1 Generiranje in zagon nadzornega J2EE projekta

Nadzorni modeli tečejo na strežniku Application Server kot J2EE aplikacije (Java 2

Platform, Enterprise Edition). Integration Developer skupaj s Monitor Toolkit omogočata

generiranje ustreznih J2EE aplikacij iz nadzornega modela. Ob tem se generirajo tri

datoteke in sicer dve Java zrni EJB (Enterprise JavaBean) in paket vseh potrebnih datotek

vključno s tema dvema EJB zrnoma v formatu EAR (Enterprise ARchive). EAR datoteko

lahko potem uporabimo za namestitev nadzorne aplikacije na produkcijski strežnik. V

našem primeru predstavlja datoteka MonitorTaxiModelLogic EJB zrno, ki vsebuje logiko

obdelave dogodkov nadzornega modela. Datoteka MonitorTaxiModerator predstavlja

logiko konzumacije nadzornega modela. Celotna aplikacija pa je zapakirana v EAR

datoteki MonitorTaxiApplication. Aplikacije ne moremo zagnati samostojno, zato tudi ni


prikazana znotraj Integration Developer projektnega raziskovalca. Integrirano testno okolje

vsebuje Process Server, na katerem teče tudi Monitor Server. [11, 20] Ustvarjeno

aplikacijo namestimo in zaženemo na tem strežniku kot prikazuje Slika 5.9.

Slika 5.9: Dodajanje in zagon nadzorne aplikacije na testnem strežniku


5.3.2 IBM Business Space

IBM Business Space je spletni uporabniški vmesnik preglednih plošč namenjen poslovnim

uporabnikom. Vključen je v Business Monitor in v ostale WebSphere produkte.

Uporabnikom s pomočjo različnih komponent za prikaz podatkov omogoča vizualni

pregled nad učinkovitostjo poslovanja podjetja. Do Business Space dostopamo preko

spletnega brskalnika, kjer lahko upravljamo s poslovnimi prostori (angl. Business

Space).[12, 9] Za naš primer smo ustvarili nov poslovni prostor in ga poimenovali Taksi

prevozi. Ob ustvarjanju novega poslovnega prostora lahko izbiramo med že pripravljenimi

predlogami, med katerimi je tudi predloga za nadzor poslovnih aktivnosti. Ta predloga

vsebuje strani razdeljene glede na vrsto komponent na njih. Za naš primer smo ustvarili

novo stran poimenovano Prevozi, na katero bomo postavili želene komponente.

Konfiguracijo in prikaz samih komponent bomo opisali v nadaljevanju.

5.3.3 Pošiljanje testnih dogodkov

Za testiranje nadzornega modela potrebujemo zanj primerne testne podatke. Vnos podatkov

oz. bolj natančno pošiljanje vhodnih testnih dogodkov v nadzorni model, lahko opravimo

na več načinov. Mi smo uporabili vgrajen testni odjemalec (angl. Integrated Test Client), ki

je del Monitor Toolkit-a. V testnem odjemalcu izberemo nadzorni model, pripadajoči

nadzorni kontekst in želen vhodni dogodek, ki ga želimo poslati. Odpre se nam obrazec za

vnos podatkov z ustreznimi podatkovnimi tipi, ki smo jih definirali v definiciji dogodkov.

Za simulacijo pretečenega časa med dogodki lahko dodamo časovni zamik. Možno pa je

tudi dodajanje premorov za pregled stanja poslanih dogodkov in posameznih instanc. Slika

5.10 prikazuje odjemalec za pošiljanje dogodkov.


Slika 5.10: Testni odjemalec za pošiljanje vhodnih dogodkov

Skupek testnih dogodkov lahko shranimo v testno skripto, ki je zapisana v formatu XML.

V njej se nahajajo podatki za CBE dogodek, struktura dokumenta pa je skladna s XSD

shemo definicije dogodkov. Primer dogodka voziloPoslano prikazuje del XML kode z

oznako Programska koda 5.1. Ta prikazuje le podatkovne elemente z njihovimi vrednostmi

in nekatere lastnosti CBE dogodka.


Programska koda 5.1: Testni vhodni dogodek voziloPoslano

Skripta vsebuje lastnosti samega CBE dogodka in njegove podatke. Te lastnosti so: čas

nastanka, čas poteka, verzija, globalni in lokalni identifikator, zaporedna številka, število

ponavljanj, sporočilo in prioriteta. Podatki so zapisani tudi kot delci dogodka, pri čemer je

poleg vrednosti podan še njen podatkovni tip in povezava CBE dogodka z definicijo

dogodkov. Tak primer elementa predstavlja izsek Programska koda 5.2.

Programska koda 5.2: Element s podatkovnim tipom in povezavo definicije dogodkov


Poslati moramo še vhodni dogodek, ki predstavlja pobiranje stranke na začetnem naslovu.

V tem dogodku pošljemo le podatek o ID-ju taksi vozila. Preko tega ID-ja so namreč

povezani vsi trije tipi dogodkov v našem primeru. Eno taksi vozilo lahko namreč opravlja

en prevoz hkrati. Pošljemo še tudi čas pobiranja stranke, kar hkrati predstavlja časovno

oznako. Primer podatkovnih elementov dogodka strankaPobrana prikazuje izsek

Programska koda 5.3.

Programska koda 5.3: Testni vhodni dogodek strankaPobrana

Konec posameznega prevoza predstavlja dogodek strankaOdlozena. Njegova struktura je

enaka kot pri dogodku strankaPobrana. Bolj pozen je le čas dogodka, ki predstavlja čas,

ko je bila stranka odložena in s tem prevoz zaključen. Primer tega dogodka prikazuje

Programska koda 5.4.

Programska koda 5.4: Testni vhodni dogodek strankaOdlozena

Pripravili smo testne podatke o prevozih za obdobje dveh tednov. Za vsak dan smo testne

dogodke shranili posebej v svojo skripto. Podatki so namišljeni in kakršna koli podobnost z

realnimi podatki, kot sta ime in priimek osebe, je zgolj naključna razen enega voznika, kjer

smo uporabili ime in priimek avtorja tega dela. Upoštevati je bilo potrebno nekatere

faktorje, da bi bili testni podatki čim bolj podobni realni situaciji. In sicer je bilo potrebno


gledati na to, da eno vozilo istočasno ne opravlja dveh ali več prevozov hkrati. Določili

smo tri vozila (Mercedes Benz Vito, Renault Espace in Pontiac Firebird). Vsakemu vozilu

pripada svoj voznik in svoj podatek o povprečni porabi goriva. Čase dogodkov je bilo

potrebno določiti v smiselnem zaporedju, saj se npr. dogodek strankaOdlozena ne more

zgoditi pred dogodkom strankaPobrana. Prevozi so čez dan razporejeni podobno čez

celotno obdobje dveh tednov. Prevožena razdalja je izračunana kot razlika med začetnim in

končnim stanjem števca vozila. Tako smo upoštevali, da se stanje števca z vsako

opravljeno vožnjo povečuje, vendar le za prevoze čez en dan. Stanje števca smo za čez

teden spreminjali le toliko, da smo dobili različne prevožene razdalje, nismo pa ga

povečevali zvezno glede na stanje predhodnega dne, saj le-to ni bilo relevantno za prikaz

delovanja. KPI, ki prikazuje obrabljenost vozila, upošteva pa maksimalno vrednost stanja

števca, tako da bi v realnem primeru prikazoval pravilno vrednost. Število potnikov na

prevoz smo izbrali naključno čez celotno obdobje. Kot mesto začetnega naslova, smo

pogosto določili mesti Maribor in Celje za kasnejši prikaz analize. Vsi ostali podatki so bili

vneseni naključno.

Vizualne komponente na pregledni plošči upoštevajo dejanski čas, ko se je zgodil nek

dogodek. Pridobijo ga iz sistemske ure strežnika, na katerem teče nadzorni model. Tak

primer predstavljajo poročila. To predstavlja omejitev v testiranju našega nadzornega

modela. Testne dogodke smo namreč pripravili za razporeditev čez obdobje dveh tednov,

zato bi jih bilo potrebno pošiljati vsak dan posebej. To omejitev smo obšli tako, da smo

med pošiljanjem testne skripte za določen dan spremenili sistemski datum. S tem sicer

nismo dobili tako točnega časa izraženega v urah in minutah kot bi ga dobili v realnem

primeru. Časovna razpršitev pa je vseeno zadostna za ugotavljanje trenda prevozov glede

na dneve v tednu.

5.4 Pregledna plošča

Pregledna plošča je tista, ki pokaže vse funkcionalnosti BAM. Njihovo delovanje pa lahko

vidimo šele po vseh korakih, ki smo jih do sedaj opravili. Opisali bomo nekatere

komponente, ki jih je mogoče postaviti na pregledno ploščo. Komponente dodamo tako, da


jih enostavno potegnemo na želen prostor na pregledni plošči in jim ustrezno nastavimo

konfigurator. Do preglednih plošč lahko dostopamo tudi preko spleta s pomočjo mobilnih

naprav kot so dlančniki, mobilni telefoni kot npr. iPhone in Blackberry. Na ta način lahko

njihovo stanje spremlja osebje, ki dela izven pisarne oz. na terenu.

5.4.1 Seznam instanc

Komponenta seznam instanc (angl. Instances) prikazuje instance z vsemi pripadajočimi

podatki. V konfiguratorju izberemo nadzorni model in podatke, ki jih želimo prikazati. Ti

podatki so dejansko vrednosti metrik za posamezno instanco. Nastavimo lahko število

prikazanih instanc na stran in čas osvežitve podatkov. Lahko tudi določimo vrstni red

prikaza podatkov in jih filtriramo. Slika 5.11 prikazuje konfigurator seznama instanc z

nastavitvami za naš primer.


Slika 5.11: Konfigurator seznama instanc

V seznamu instanc imamo tako podroben pregled nad posamezno instanco, ki jo lahko

posebej analiziramo. Seznam lahko tudi izvozimo, iščemo po njem in ga sortiramo glede

na izbran stolpec. Slika 5.12, Slika 5.13 in Slika 5.14 prikazujejo seznam testnih instanc,

sortiran padajoče glede na začetni čas prevoza.


Slika 5.12: Seznam instanc 1/3





5.4.2 Prikazovalnik KPI-jev

Med najpomembnejše komponente spada KPI prikazovalnik. V njegovem konfiguratorju

izberemo želene KPI-je in način prikaza. Način prikaza lahko izbiramo med: tabela, števec,

polovični števec, vrstica in enostavni prikaz. Primer konfiguratorja prikazuje Slika 5.15.

Slika 5.15: KPI konfigurator

Za prikaz KPI-jev, ki smo jih definirali v našem nadzornem modelu smo naslednjim

določili tabelarno obliko: Izraba vozila Mercedes Benz Vito, Izraba vozila Renault Espace,

Izraba vozila Pontiac Firebird, Povprečno prevožena razdalja na prevoz, V povprečju

porabljeno gorivo na vožnjo, Število vozil v teku. Obliko polovičnega števca pa KPI-jem:

Število vozil v teku, Odstotek prevozov v mestu Maribor, Odstotek telefonskih naročil in

Odstotek zamud voznika Aleš Gjerkeš. Slika 5.16 prikazuje trenutno stanje naših KPI-jev.


Slika 5.16: Prikaz KPI-jev


5.4.3 Opozorila

Za vsak KPI lahko določimo opozorila, ki se pošljejo ob določenem pogoju. Pogoj

določimo glede na območje, če je le-to bilo definirano ali glede na trenutno vrednost.

Primeri pogojev za območje so: nad območjem, pod območjem, v območju, zapustitev

zgornje ali spodnje meje itd. Definiramo lahko tudi kako pogosto (vsakih x

minut/ur/dni/tednov/mesecev) in kdaj točno se bo ta pogoj začel preverjati. Glede na to pa

izberemo še frekvenco ponavljanja opozorila kot npr.: enkrat glede na določeno periodo, le

enkrat ob pogoju ali le enkrat skozi celotno obdobje. Konfigurator že sam pripravi vsebino

sporočila, ki vsebuje ime KPI-ja in v katerem območju se le-ta nahaja, seveda pa lahko

napišemo poljubno sporočilo. Izberemo lahko še naslovnike in kam vse naj se jim pošljejo

sporočila. Izberemo lahko samo prikaz na pregledni plošči, pošiljanje na mobilni telefon,

elektronski naslov ali pozivnik. Primer definicije opozorila prikazuje Slika 5.17. Pošlje se

takrat, ko se odstotek pravočasnih prevozov nahaja v kritičnem območju.

Slika 5.17: Definicija opozorila


Za prikaz opozoril na pregledni plošči uporabimo komponento seznam opozoril. Možno jih

je pošiljati med uporabniki znotraj Business Space. Ob kliku na posamezno opozorilo se

nam izpiše njegova vsebina, kar prikazuje Slika 5.18.

Slika 5.18: Prikaz opozorila

5.4.4 Poročila

Poročila prikazujejo vrednosti poslovnih meritev glede na čas. Izberemo želeno meritev, ki

smo jo določili v kocki dimenzijskega modela in časovni interval. Iz teh podatkov se nam

generira grafikon, katerega obliko lahko izbiramo med enostavnim stolpčnim, razdeljenem

na četrtine in grafikonom s prikazom trenda. Prikazana je lahko tudi tabela z dejanskimi

vrednostmi izbrane meritve za vsako časovno enoto. Skozi tabelo in grafikone se lahko

pomikamo globlje za bolj podrobno analizo (angl. Drill Down). Ustvarili smo poročilo, ki

prikazuje vsoto potnikov na dan v našem testnem časovnem intervalu. Uporabili smo

grafikon s prikazom trenda. Trend nam kaže, da vsota potnikov na splošno upada z vrhunci

med vikendom. Desno od grafikona se nahaja tabela z dejanskimi vrednostmi vsote


potnikov za posamezni dan, skupnim seštevkom za posamezni mesec in celotno leto, kar je

razvidno iz Slika 5.19.

Slika 5.19: Poročilo vsote potnikov/dan s prikazom trenda

Meritev števila instanc je že pripravljena meritev, ki je ni potrebno posebej definirati. To

smo izkoristili za prikaz števila prevozov v določenem časovnem obdobju. V mesečnem

pregledu nam poročilo pove, da se je število prevozov v mesecu avgustu glede na prejšnji

mesec povečalo. Tedenski prikaz pa kaže na to, da je število prevozov največje med

vikendi. Mesečni in dnevni grafikon števila prevozov prikazujeta grafikona na Slika 5.20.


Slika 5.20: Poročilo števila prevozov po mesecih in posameznih dnevih

5.4.5 Dimenzije

Naslednjo stopnjo poročil predstavlja prikaz dimenzijskega modela. Njegove dimenzije in

meritve smo že definirali. Za prikaz meritev na grafu izbranih dimenzij na pregledni plošči

izberemo komponento dimenzije. V njenem konfiguratorju izberemo katere dimenzije

želimo uporabiti kot vrstice in katere kot stolpce v tabeli. S tem določimo tudi osi na grafu.

V našem primeru smo izbrali dva prikaza dimenzij. Prvemu smo za vrstice izbrali začetni

naslov prevoza, po stolpcih pa smo izbrali izpis meril, ki smo jih definirali v dimenzijskem

modelu. Za drug primer smo za vrstice izbrali podatke o vozniku. Prvi dimenzijski

grafikon in tabela nam prikazujeta meritve število instanc, vsota potnikov, povprečna

poraba, povprečno število potnikov in povprečna razdalja glede na mesto začetnega

naslova. Iz tega smo lahko razbrali, da imata mesti Maribor in Celje večinski delež pri

številu prevozov in vsoti potnikov, pri čemer prevladuje mesto Maribor. V povprečju

porabljeno gorivo in število potnikov na prevoz je čez vsa mesta razporejeno enakomerno.


Povprečno prevožena razdalja pa je večja v mestu Vurberk, saj tam gre večinoma za

prevoze iz enega mesta v drugega. Pripadajoče grafe in tabelo prikazuje Slika 5.21.

Slika 5.21: Prikaz dimenzije začetni naslov glede na meritve

V drugem primeru smo izmed meritev pustili le število instanc in vsoto potnikov ter ju

prikazali za vsakega voznika posebej. Iz te analize je mogoče razbrati, kateri voznik je bil


najbolj dejaven in kateri je prepeljal največ potnikov. Razmerje med dimenzijo voznik in

meritvami prikazuje Slika 5.22. Dimenzijam lahko tudi zamenjamo os ali premaknemo

posamezno vrstico ali stolpec na drugo os (angl. Pivoting).

Slika 5.22: Prikaz dimenzije Voznik glede na meritvi število instanc in vsota potnikov

5.4.6 Pregled zgodovine in napovedi

Komponenta KPI zgodovine in napovedi, kot že samo ime pove, povzame dosedanje

podatke in s pomočjo le-teh predlaga napovedi za prihodnja obdobja. Želenemu KPI-ju

aktiviramo beleženje zgodovine in pripravimo model za napoved. Izberemo časovni

interval in obdobje, ki bo upoštevano za napoved. Za primer smo izbrali odstotek prevozov

v mestu Maribor (Slika 5.23).


Slika 5.23: Zgodovina in napoved KPI

5.4.7 Ostale komponente

Vse te komponente pregledne plošče, ki smo jih uporabili in opisali, pa niso edine, ki jih

lahko uporabimo. Na voljo je še komponenta diagrami (angl. Diagrams), ki prikazuje

poslovni proces v obliki diagrama toka (angl. Flowchart). Diagram toka prikazuje stanje in

informacije o procesu. Na diagramu lahko kliknemo na proces za ogled pripadajočega

podprocesa in tako vidimo njegov podroben potek. Za uporabo diagramov bi bilo potrebno

nadzornemu modelu definirati tudi vizualni model. To pa pride do izraza ob bolj zapletenih

poslovnih procesih, kjer s tem lahko ugotavljamo njihova ozka grla. Poleg tega imamo še

komponento seznam človeških opravil (angl. Human Tasks) in orodja za upravljanje s KPI-

ji, opozorili in varnostjo. Lahko izvozimo vrednosti, uporabimo koledar, upravljamo z

osebjem naše poslovne skupine, pošiljamo komponente med osebjem, imamo pregled nad

opravili celotne skupine in pridobimo pregled nad stanjem celotnega sistema. V stanju

celotnega sistema poslovne rešitve lahko vidimo trenutno stanje vseh strežnikov,

sistemskih in poslovnih aplikacij ter čakalno vrsto.[12] Tako bi nekatere funkcionalnosti


prišle do izraza šele v večjem, bolj zapletenem in dlje trajajočem poslovnem procesu, kot

je bil naš praktični primer.

Naš primer bi lahko za uporabo v praksi še razširili in s tem rudi razširili raziskovanje

diplomske naloge. Lahko bi npr. pridobili podatke o cenah avtomobilskega zavarovanja,

cenah parkirnin ter vseh ostalih podatkov, ki so relevantni za poslovanje. Tako bi še bolj

podrobno lahko spremljali in predvideli stroške. Testiran nadzorni model bi v realnem

podjetju naslednji korak zajemal prenos na produkcijski strežnik in s tem pričetek njegove

uporabe.


6 SKLEP

Elektronsko podprto poslovanje podjetjem lahko olajša njihov poslovni proces. Sami

informacijski sistemi, ki podpirajo poslovanje, pa ne dajejo povratnih informacij o poslovni

uspešnosti. Tukaj nastopijo BAM rešitve, katerih namen uporabe in funkcionalnosti smo

preučili. Že sama povezljivost z aplikacijami, od katerih pridobivamo podatke s pomočjo

spletnih storitev, nam daje neomejene možnosti. Tako nismo omejeni le na podatke iz

našega podjetja, ampak se lahko povežemo in pridobivamo podatke drugih organizacij, ki

so vpleteni v naše poslovanje.

Vpeljava BAM rešitve v podjetje je odvisna od IT rešitev, ki jih podjetje trenutno

uporablja. Od tega je odvisen tudi način implementacije nadzornega modela. Skozi

praktični primer smo preučili izdelavo nadzornega modela kot integracijsko aplikacijo, ki

zbira vse pomembne podatke za nadzor. Najpomembnejši korak predstavlja definiranje

metrik, ki zbirajo podatke iz poslovnih dogodkov in definiranje KPI-jev. Tu pride do izraza

sodelovanje med managerji in IT strokovnjaki. Nadzorni model lahko tako nenehno

izboljšujemo, kar omogoča SOA življenjski cikel.

Nadzorovanje poslovnih aktivnosti v IS ne vpliva neposredno na izboljšavo poslovnega

procesa, zato se morda za nekatera podjetja investicija v BAM rešitve ne zdi upravičena.

Že zelo enostaven primer, ki smo ga preučili, prikazuje da pogled na trenutno stanje

preglednih plošč pomaga pri poslovnih odločitvah. Zgodovinski podatki in trendi pa

omogočajo predvidevanja za prihodnje obdobje, kar pripomore k doseganju in preseganju

poslovnih ciljev.


7 VIRI, LITERATURA

1. Colin White, Is BAM Alive and Well?, Information Management Magazine, 2005, http://www.information-management.com/issues/20050901/1035618-1.html (zadnji obisk: 14.4.2008)

2. David Luckham, The Beginnings of IT Insight: Business Activity Monitoring, 2004, http://www.ebizq.net/topics/bam/features/4689.html?page=3 (zadnji obisk: 7.9.2009)

3. David McCoy, Business Activity Monitoring: Calm Before the Storm, Gartner Research, 2002 http://www.gartner.com/resources/105500/105562/105562.pdf (zadnji obisk: 26.3.2008)

4. Gary Anthes, Computerworld, Eyes Everywhere: Business activity monitoring offers a constant watch on business processes, http://www.computerworld.com/softwaretopics/software/story/0,10801,86895,00.html

5. Harpal Kochar, Oracle, Business Activity Monitoring and Business Intelligence, 2005, http://www.ebizq.net/topics/bam/features/6596.html?page=1 (zadnji obisk: 12.9.2008)

6. IBM DB2 Alphablox, http://www-01.ibm.com/software/data/db2/alphablox/ (zadnji obisk: 18.8.2009)

7. IBM developerWorks, WebSphere, New to WebSphere, http://www.ibm.com/developerworks/websphere/newto/ (zadnji obisk: 16.6.2009)

8. IBM Education Assistant, Common Event Infrastructure, Monitoring Applications with CEI, http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp?topic=/com.ibm.iea.wpi_v6/wpswid/6.0/CEI/WPSWIDv6_MonitoringWithCEI/player.html (zadnji obisk 24.7.2009)

9. IBM Information center, Business Space powered by WebSphere, Business space concepts, http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.bspace.620.help.framework.doc/concepts/bspace_concepts_main.html (zadnji obisk: 16.7.2009)

10. IBM Information center, WebSphere Business Modeler Advanced 6.2, Product overview http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.btools.modeler.advanced.help.doc/doc/concepts/overviews/productoverview.html (zadnji obisk: 17.6.2009)

11. IBM Information center, WebSphere Business Modeler Advanced 6.2, Testing monitor models in the test environment, http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.btools.help.monitor.dev.doc/testing/testingmonitormodels.html (zadnji obisk 7.8.2009)

12. IBM Information center, WebSphere Business Modeler Advanced 6.2, Monitoring with Business Space dashboards, http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.btools.help.monitor.dash.doc/dash/widgets.html (zadnji obisk 9.8.2009)

13. IBM Information center, WebSphere Business Monitor Version 6.0.2, Monitor models, http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.btools.help.monitor.doc/Doc/concepts/monitor_model/monitormodels.html (zadnji obisk 27.7.2009)

14. IBM Information center, WebSphere Business Monitor Version 6.2, How monitoring works,


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.btools.help.monitor.install.doc/toolkit/model/howmonitoringworks_intro.html (zadnji obisk 27.7.2009)

15. IBM Information center, WebSphere Business Monitor Version 6.2, Installing and removing the toolkit, http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.btools.help.monitor.install.doc/install/tkit.html (zadnji obisk 26.7.2009)

16. IBM Information center, WebSphere Business Monitor, Version 6.2, Creating monitor models, http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.btools.help.monitor.dev.doc/toolkit/mme/creatingamonitormodel.html (zadnji obisk: 17.7.2009)

17. IBM Information center, WebSphere Business Monitor, Version 6.2, Dimensions overview, http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.btools.help.monitor.dash.doc/dash/help_dim_ov.html (zadnji obisk: 17.7.2009)

18. IBM Information center, WebSphere Integration Developer Version 6.2, WebSphere business process management family, http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.wbit.620.help.prodovr.doc/topics/cbpmfamily.html (zadnji obisk 26.7.2009)

19. IBM Tivoli news, Common Event Infrastructure, Intelligent automation that saves time and improves resource utilization, http://www-01.ibm.com/software/tivoli/features/cei/ (zadnji obisk: 24.7.2009)

20. IBM WebSphere Business Monitor Development Toolkit 6.2, Samples and Tutorials 21. IBM, WebSphere Business Monitor, Features and benefits http://www-

01.ibm.com/software/integration/wbimonitor/features/ (zadnji obisk: 15.7.2009) 22. Information Builders, soloutions, BAM

http://www.informationbuilders.com/solutions/bam.html (zadnji obisk: 24.5.2008) 23. Jonathan Marshall, IBM developerWorks, Transforming models from WebSphere

Business Modeler to WebSphere Integration Developer, 2005, http://www.ibm.com/developerworks/websphere/library/techarticles/0605_marshall/0605_marshall.html?S_TACT=105AGX10&S_CMP=LP (zadnji obisk: 16.6.2009)

24. Mark Hellinger in Scott Fingerhut, Business Activity Monitoring: EAI Meets Data Warehousing - http://www.businessactivitymonitoring.com/docs/bam.pdf (zadnji obisk: 24.5.2008)

25. Microsoft, BizTalk Server 2009 BAM Poster, http://www.microsoft.com/downloads/thankyou.aspx?familyId=193cd7a4-e271-46bb-b4ee-8434dfa779a0&displayLang=en (zadnji obisk: 7.9.2009)

26. Microsoft, BizTalk Server Overview System Requirements, http://www.microsoft.com/biztalk/en/us/system-requirements.aspx (zadnji obisk: 7.9.2009)

27. Microsoft, BizTalk Server Overview, http://www.microsoft.com/biztalk/en/us/overview.aspx (zadnji obisk: 7.9.2009)

28. Oracle, Oracle Business Activity Monitoring, Oracle Data Sheet, 2009, http://www.oracle.com/technology/products/integration/bam/collateral/BAM%2011g%20Datasheet.pdf (zadnji obisk: 7.9.2009)

29. TIBCO Developer Network, http://developer.tibco.com/ (zadnji obisk: 14.11.2008)


30. TIBCO, BusinessFactor Datasheet, http://www.tibco.com/multimedia/ds-businessfactor_tcm8-768.pdf (zadnji obisk: 7.9.2009)

31. webMethods, Business Activity Monitoring (BAM) - The New Face of BPM, 2006, http://www.bpminstitute.org/uploads/media/BAM-The_New_Face_of_BPM_1106.pdf (zadnji obisk: 3.5.2008)

32. Wikipedia, Business activity monitoring http://en.wikipedia.org/wiki/Business_activity_monitoring (zadnji obisk 27.3.2008)

33. Wikipedia, Dimensional analysis, http://en.wikipedia.org/wiki/Dimensional_analysis 34. Wikipedia, Performance indicator,

http://en.wikipedia.org/wiki/Key_performance_indicator (zadnji obisk: 27.3.2008) 35. Wikipedia, Service-oriented architecture, http://en.wikipedia.org/wiki/Service-

oriented_architecture (zadnji obisk: 11.7.2009)


8 PRILOGE

8.1 Seznam slik Slika 3.1: Prikaz interakcije v SOA [29] ............................................................................... 9

Slika 3.2 Splošen cikel modeliranja z IBM orodji [23] ....................................................... 11

Slika 3.3: Koraki SOA cikla z ustreznimi IBM produkti [23]............................................. 12

Slika 4.1: Arhitektura IBM WebSphere platforme [7] ........................................................ 15

Slika 4.2: Družina IBM WebSphere orodij razdeljena na posamezne faze razvoja

nadzornega modela z medsebojnimi povezavami in tokovi [18] ........................................ 17

Slika 4.3: Delovanje nadzornega modela [14]..................................................................... 24

Slika 5.1: Grafični pregled na elementi in tipi definicije dogodkov.................................... 28

Slika 5.2: Definicija tipov.................................................................................................... 29

Slika 5.3: Uporabniški vmesnik nadzornega modela in prikaz lastnosti vhodnega dogodka

voziloPoslano ...................................................................................................................... 32

Slika 5.4: Podatki in operacije, ki jih lahko uporabimo za izračun vrednosti metrik.......... 34

Slika 5.5: Mapiranje ............................................................................................................ 39

Slika 5.6: Povezava med dogodki in metrikami ter njihova soodvisnost v pogledu

nadzornega toka................................................................................................................... 40

Slika 5.7: KPI urejevalnik s prikazom lastnosti .................................................................. 42

Slika 5.8: Dimenzijski model .............................................................................................. 49

Slika 5.9: Dodajanje in zagon nadzorne aplikacije na testnem strežniku............................ 51

Slika 5.10: Testni odjemalec za pošiljanje vhodnih dogodkov ........................................... 53

Slika 5.11: Konfigurator seznama instanc........................................................................... 58

Slika 5.12: Seznam instanc 1/3............................................................................................ 59



Slika 5.15: KPI konfigurator................................................................................................ 61

Slika 5.16: Prikaz KPI-jev ................................................................................................... 62

Slika 5.17: Definicija opozorila........................................................................................... 63

Slika 5.18: Prikaz opozorila ................................................................................................ 64

Slika 5.19: Poročilo vsote potnikov/dan s prikazom trenda ................................................ 65

Slika 5.20: Poročilo števila prevozov po mesecih in posameznih dnevih........................... 66


Slika 5.21: Prikaz dimenzije začetni naslov glede na meritve ............................................ 67

Slika 5.22: Prikaz dimenzije Voznik glede na meritvi število instanc in vsota potnikov .... 68

Slika 5.23: Zgodovina in napoved KPI ............................................................................... 69

8.2 Seznam tabel Tabela 5.1: Povezava med definicijo dogodkov in vhodnimi dogodki nadzornega modela31

Tabela 5.2: Definicija vhodnega dogodka voziloPoslano ................................................... 32

Tabela 5.3: Definicija vhodnega dogodka strankaPobrana................................................ 33

Tabela 5.4: Definicija vhodnega dogodka strankaOdlozena .............................................. 33

Tabela 5.5: Definicija metrik............................................................................................... 36

Tabela 5.6: Definicija KPI................................................................................................... 43

Tabela 5.7: Definicija dimenzij in pripadajočih nivojev..................................................... 50

Tabela 5.8: Definicija meritev za dimenzijski model ......................................................... 50

8.3 Seznam programske kode

Programska koda 5.1: Testni vhodni dogodek voziloPoslano ............................................ 54

Programska koda 5.2: Element s podatkovnim tipom in povezavo definicije dogodkov ... 54

Programska koda 5.3: Testni vhodni dogodek strankaPobrana ......................................... 55

Programska koda 5.4: Testni vhodni dogodek strankaOdlozena ........................................ 55

8.4 Izvorna koda nadzornega modela in testnih podatkov

Izvorna koda nadzornega modela je priložena na zgoščenki v mapi TaxiPrevozi.

Pripadajoči testni podatki pa v mapi Testni podatki.


8.5 Naslov študenta

Aleš Gjerkeš

Nedelica 33

9224 Turnišče

Tel.: 041 991 423

E-pošta: [email protected]

8.6 Kratek življenjepis

Rojen: 8.5.1985, Ljubljana

Šolanje: 1992-2000 Osnovna šola Turnišče

2000-2004 Srednja tehnična in poklicna šola, Murska Sobota

2004-2009 FERI, Maribor (VS – Računalništvo in informatika)

Documents

NADZOR POSLOVNIH AKTIVNOSTI V INFORMACIJSKIH SISTEMIH · Z upoštevanjem poslovne logike ne potrebujemo dodatnega analitika za odkrivanje napak, saj npr. velika čakalna vrsta v za