ZNANSTVENI PRISPEVKI B Modeliranje in izvajanje poslovnih procesov v storitveno orientiranih arhitekturah Marcel Križevnik, Matjaž B. Jurič Fakulteta za elektrotehniko, računalništvo in informatiko, Smetanova ulica 17, 2000 Maribor marcel.krizevnik@uni-mb.si Izvleček Dolgoročno uspešnost organizacije lahko zagotovimo le s celostnim pristopom k upravljanju njenih poslovnih procesov (BPM - Business Process Management). Prispevek predstavlja posamezne faze življenjskega cikla ter poudarja ključne prednosti pristopa storitveno orientiranih arhitektur (Service Oriented Architecture) s posebnim poudarkom na fazah modeliranja, implementacije in izvajanja. Prva faza v življenjskem ciklu je modeliranje poslovnih procesov. Pristop SOAza modeliranje predvideva uporabo notacije 6PMN (Business Process Modeling Notation), za implementacijo pa jezik BPEL (Business Process Execution Language). Po končanem modeliranju je na vrsti pretvorba modela v izvršilno obliko (BPEU. Prispevek predlaga postopek pretvorbe ter s pomočjo SWOT-analize identificira njene ključne prednosti, slabosti, priložnosti in pasti. Po končani implementaciji sta na vrsti namestitev in izvajanje poslovnega procesa. Ena izmed ključnih prednosti pristopa SOA je ravno odlična podpora izvajanju, saj so podprti tako dolgotrajni kot kratkotrajni procesi, omogočeno je vključevanje ljudi, prav tako sta mogoča direkten vpogled v izvajanje instanc ter prikaz sledi poslovnega procesa. Če želimo zagotavljati visoko učinkovitost poslovnih procesov, je nujno nenehno spremljanje njihovega izvajanja s pomočjo orodij BAM (Business Activity Monitoring). Tako lahko hitreje odkrijemo morebitna ozka grla ter pravočasno ukrepamo. Če poslovni proces ne dosega želene učinkovitosti, je treba opraviti optimizacijo in ponoviti predstavljeni cikel. Ključne besede: SOA, BPM, BPMN, BPEL, BAM, KPI, upravljanje poslovnih procesov, življenjski cikel poslovnih procesov. Abstract MODELING AND EXECUTING BUSINESS PROCESSES IN SERVICE ORIENTED ARCHITECTURE Long-term success of the organization can only be achieved through comprehensive approach to the management of its business processes (BPM - Business Process Management). This article presents different phases of business process life cycle and highlights the key advantages of SOA (Service Oriented Architecture) approach, with particular emphasis on the stages of modelling, implementation and execution. The first phase of the life cycle is business processes modelling with the use of BPMN (Business Process Modelling Notation). Modelling is followed by automated translation of business model into executable process (BPEL - Business Process Execution Language). The article provides a proposal for the conversion process and with the help of SWOT analysis identifies its key strengths, weaknesses, opportunities and threats. When the implementation is finished, we have to deploy the business process and start with its execution. One of the key advantages of SOA approach is excellent support to business process execution. Processes can include human tasks and can be short or long-running. It is also possible to get the direct insight into each instance and see its audit trail. If we want to provide a high efficiency of business processes, it is essential to continuously monitor their execution with the use of BAM (Business Activity Monitoring). If the business process does not achieve the desired effectiveness, optimization needs to be done and the cycle has to be repeated. Key words: SOA, BPM, BPMN, BPEL, BAM, KPI, business process management, business process lifecycle. 1 UVOD proces. Ker model ni predstavljal aktualnega stanja, ni bil Številne organizacije se soočajo s težavami pri obvladovanju v veliko pomoč. Tovrstno nepoznavanje poslovnih procesov svojih poslovnih procesov. U preteklosti se je namreč po- ima za posledico težje zaznavanje neučinkovitosti, oteženo gosto dogajalo, da se model procesa ni ustrezno posodabljal uvajanje novo zaposlenih, slabo dodeljene odgovornosti in in je bil le statična slika, ki ni odražala dejanskega stanja, slabo podlago za informatizacija. Drugi velik problem je po-Poleg tega ti modeli največkrat niso bili javno dostopni, gosto predstavljala informacijska podpora, ki podpirala po-temveč so obležali v pisarniških predalih. V primeru kom- samezne funkcije, ne pa celotnega poslovnega procesa. Ka-pleksnejših poslovnih procesov, ki vključujejo večje število kršne koli spremembe procesa so zato terjale dolgotrajne in ljudi iz različnih oddelkov, se je zato pogosto zgodilo, da v finančno potratne spremembe enega ali več informacijskih nekem trenutku ni bilo niti ene osebe, ki hi poznala celoten sistemov. Prav tako ta, klasični pristop k BPM v bistvu ne omogoča vpogleda v izvajanje in spremljanja učinkovitosti, zato je oteženo izvajanje optimizacije, ki se po navadi dogaja v glavi ene osebe. Zaradi opisanih težav se v zadnjem času vedno več organizacij odloča za vpeljavo celovitega pristopa k obvladovanju procesov, ki ga imenujemo tudi upravljanje poslovnih procesov (BPM). BPM definira naslednje faze življenjskega cikla: modeliranje, simuliranje, implementacijo, izvajanje in spremljanje ter optimiziranje. Klasični pristop k BPM se v preteklosti ni izkazal kot učinkovit, saj ne zagotavlja želene fleksibilnosti in ne nudi zadostne podpore vsem naštetim fazam. Ker omogoča SOA tesno porav-nanost poslovnih zahtev z dejansko implementacijo in zagotavlja dobro podporo izvajanju procesov, predstavlja trenutno najboljši pristop k vpeljavi BPM. 2 PROBLEMI PRI OBVLADOVANJU POSLOVNIH PROCESOV Po definiciji je poslovni proces nabor medsebojno povezanih aktivnosti, katerih cilj je doseganje zastavljenih poslovnih rezultatov. Te aktivnosti so lahko uporabniška opravila, lahko pa se izvajajo samodejno. Vrstni red in učinkovitost aktivnosti določata učinkovitost procesa in s tem celotne organizacije. Poslovni procesi so torej jedro vsake organizacije, njihovo celovito obvladovanje pa predstavlja ključ za dolgoročno uspešnost. Kljub temu se številne organizacije pri obvladovanju poslovnih procesov soočajo z naslednjimi težavami [1]: ■ Pogosto spreminjanje. Zaradi spreminjajočih se razmer na globalnem trgu je treba poslovne procese pogosto spreminjati in prilagajati novim zahtevam. Če informacijska podpora poslovnega procesa ni zastavljena dovolj fleksibilno, so lahko spremembe dolgotrajne, kar znižuje raven učinkovitosti in konkurenčnosti. ■ Številnost. S širjenjem poslovanja in povezovanjem z drugimi organizacijami se število poslovnih procesov v organizacijah veča, kar ima za posledico slabše poznavanje. ■ Kompleksnost. Nemalokrat so poslovni procesi zelo kompleksni; posledica tega je nepoznavanje procesov in nižja stopnja fleksibilnosti. ■ Nepoznavanje. Do nepoznavanja poslovrüh procesov najpogosteje pride v primeru, ko organizacija nima izdelanih ustreznih poslovnih modelov ali pa se ti niso posodabljali in ne predstavljajo aktualnega stanja. Nepoznavanje lahko precej upo- časni postopek spreminjanja procesa ali uvajanja novo zaposlenih. ■ Razkorak med poslovnimi zahtevami in dejansko implementacijo. Glavna razloga za omenjeni razkorak sta predvsem neustrezno ažuriranje modela poslovnega procesa ter tehnološke omejitve pri izvedbi implementacije. ■ Neučinkovitost. Posledica naštetih težav je neučinkovitost, ki predstavlja glavni problem pri obvladovanju poslovnih procesov. 3 ŽIVUENJSKI CIKEL POSLOVNIH PROCESOV Upravljanje poslovnih procesov predstavlja pristop nenehnega prilagajanja organizacije potrebam strank in predvideva merjenje in izboljševanje učinkovitosti poslovnih procesov v skladu z življenjskim ciklom, kot ga prikazuje slika 1 [1,8]: medeliraiiiig n n ^BlUni^iSiB r . . . 1 llmplenr letiitasiial i Slika 1: Življenjski ciliei poslovnih ■procesov Življenjski cikel poslovnega procesa se začne z modeliranjem in nadaljuje z implementacijo. Pristop SOA k BPM za modeliranje priporoča uporabo notacije BPMN [10], za izvedbo implementacije pa jezik BPEL. Ko je poslovni proces v uporabi, je treba nenehno spremljati njegovo učinkovitost s pomočjo ključnih kazabiikov uspešnosti (KPI - Key Performance Indicator). Če ugotovimo, da proces ne dosega želene učinkovitosti, ga je treba optimizirati. Osnovo za izvedbo optimizacije predstavljajo KPI-ji, zbrani v času izvajanja. Realno vrednost optimizacije je priporočljivo preveriti tudi z izvajanjem simulacij. Vse spremembe je treba nato popraviti v poslovnem modelu in implementaciji ter dati v uporabo novo verzijo procesa. Tudi to, popravljeno verzijo, je treba spremljati in po potrebi se cikel ponovi. V nadaljevanju sledi podrobnejši opis posameznih korakov življenjskega cikla. 3.1 Modeliranje Glavni namen modeliranja je izdelava trenutnega (as-is) modela poslovnega procesa. Pred začetkom modeliranja je treba oblikovati delovno skupino in izbrati ustrezno notacijo. Delovno skupino po navadi sestavljajo lastnik (ki lahko ima tudi enega ali dva pomočnika), odgovorna oseba za kakovost, poslovni analitik in predstavniki informacijske tehnologije. S pomočjo izvajanja intervjujev je nato treba odgovoriti na naslednja vprašanja [1]: ■ Kakšen je rezultat poslovnega procesa? ■ Katere aktivnosti se morajo izvesti? ■ Kakšen je vrstni red aktivnosti? ■ Kdo. izvaja aktivnosti? ■ Kateri dokumenti se izmenjujejo? ■ Kako se lahko proces spremeni v prihodnosti? V zadnjem času se vedno pogosteje uporablja notacija-BPMN, saj je pregledna in lahko razumljiva tudi nestrokovnjakom, poleg tega^pa -nekatera boljša orodja omogočajo avtomatsko pretvorbo modela BPMN v izvršilno obliko (BPEL). Pri modeliranju je treba paziti, da modeliramo trenutno stanje in izpustimo, želje. Kompleksnejše poslovne procese je priporočljivo.-razbiti z uporabo; padprocespv. ;Med izdelavo modela je dobro izvesti več skupnih pre^ gledov.. Kadar je cilj modeliranja, celostna (end-to-end) implementacija poslovnega procesa, je treba veliko pozornosti nameniti pravilni stopnji granu-larnosti. Če imamo namen izdelani, model avtomatsko pretvoriti v skelet BPEL, je treba upoštevati dejstvo, da vseh modelov BPMN ni .mogoče direktno pretvoriti v izvršilno obHko. Jezik BPEL je namreč namenjen zaporednemu izvajanju, aktivnosti, zato so pri pretvorbi nestrukturiranih ciklov pogoste težave. Modeliranje poslovnih procesov prinaša številne koristi, med drugim natančneje določene odgovornosti, poznavanje obremenjenosti virov, lažje identificiranje ozkih grl in kritičnih-poti ter hitrejše uvajanje, novo zaposlenih. Učinkovitost modela je včasih smiselno preveriti tudi z izvajanjem simulacij in po potrebi model optimizirati pred izvedbo implementacije. 3.2 Pretvorba med BPMN in BPEL (Bound-trippingl 3.2.1 Pomen pretvorbe Avtomatizirana preslikava modela BPMN v BPEL [2,3,5,6,7] predstavlja enega izmed ključnih korakov v življenjskem ciklu, saj odpravlja razkorak med obema domenama in omogoča tesno poravnanost poslovnih zahtev m implementacije. Razvijalcem se tako ni. treba več ukvarjati z definiranjem zaporedja aktivnosti, marveč izvedejo le potrebne dopolnitve implementacije. V primeru nove verzije modela BPMN je mogoče preprosto opraviti spojitev obeh verzij in razvijalec lahko nadaljuje z delom. Komunikacija pa lahko poteka tudi v obratni smeri. Če postopek implementacije zahteva dodajanje aktivnosti, se lahko te spremembe posredujejo nazaj. Tako je v vsakem trenutku zagotovljena ažurnost modela BPMN. To dvosmerno komunikacijo v praksi imenujemo Round-tripping. 3.2.2 Postopek pretvorbe V osnovi poznamo dva načina preslikave [2]. Preslikana koda BPEL ima lahko strukturo grafa (graph structure) - v tem primeru je cel proces gnezden znotraj elementa Flow, zaporedje aktivnosti pa je določeno s povezavami Link. Drugi način preslikave, ki temelji na blokovni strukturi (block structure), pa sekvenčni tok preslika s pomočjo elementa Sequence. Poudariti je treba, da z nobenim načinom ni mogoče direktno preslikati arbitrarnih ciklov (cikli z različnim številom vhodnih in izhodnih povezav). V praksi se na žalost pogosto izkaže, da prehod med fazo modeliranja in fazo implementacije ni tako preprost, kot zgleda na prvi pogled. Razlog tiči v konceptualnem razkoraku [3,4,5] med notacijo BPMN in jezikom BPEL. BPEL je tipično blokovno Strukturiran jezik in je namenjen zaporednemu izvajanju aktivnosti (ne pozna t. i. ukazov GOTO). S pomočjo aktivnosti While sicer omogoča definiranje preprostih strukturiranih ciklov, ne omogoča pa uporabe nestrukturiranih oz. arbitrarnih ciklov. Po drugi strani pa notacija BPMN pri modeliranju postavlja zelo malo omejitev in omogoča modeliranje procesov v obliki grafov, torej tudi uporabo arbitrarnih ciklov. Na BPMN lahko gledamo kot na nadmnpžico BPEL. Notacije in jezike, ki omogočajo definiranje delovnih tokov, med seboj najlaže primerjamo s primerjalno tabelo, ki prikazuje podporo različnim kontrolnim vzorcem. Tabela 1 [3] s tovrstno primerjavo prikazuje razlike med BPMN in BPEL. Znak + predstavlja polno podporo, znak +/- pa delno podporo vzorcu. Z - so označeni ne-podprti vzorci. Tabela 1: Podpora kootrolnim vzorcem v BPMN in BPEL Vzorec BPMN BPEl Vzorec BPMN BPEL Osumili kontrolni vzoni 11. Implicitna terminacija + + 1. Zaporedje + + Več instanc IVI) 2. Vzporedna razvejitev + + 12. VI brez sinhronizacije + + 3. Sinhronizacija + + 13. VI z vnaprejšnjim znanjem v času modeliranja + + 4. El ' • , > ^^ 'A. ž ' V-' . ■) ■' ' ■ -V '.' ■: XXX Slika 5: Primer razrešitve arbitrarnega cikla Preoblikovanju sledi ponovna analiza modela. Ta dva koraka se ponavljata, dokler model ni pripravljen za pretvorbo in začetek implementacije. Pred izvedbo pretvorbe je mogoče nastaviti še nekatere parametre preslikave [2]. Določimo naziv ciljnega procesa BPEL ter imenski prostor (target namespace). Prav tako je treba nastaviti tip procesa (sinhron ali asinhron). Popobioma avtomatizirani procesi so po navadi sinhroni, medtem ko so procesi z uporabniškimi aktivnostmi praviloma asinhroni. Nekatera boljša modelirna orodja omogočajo uvoz obstoječih shem in datotek WSDL. Tako lahko klice spletnih storitev povežemo z dejanskimi storitvami. Ob pretvorbi se tako za vsako storitev samodejno ustvari ustrezen Partner Link. Včasih po izvedeni pretvorbi ugotovimo, da je proces BPEL nepregleden in bi se ga dalo izboljšati s preoblikovanjem modela BPMN. V tem primeru je smiselno popraviti model in ponoviti postopek preslikave. 3.2.3 SWOT-analiza preslikave med BPMN in BPEL S pomočjo analize SWOT (Strenghts, Weaknesses, Opportunities and Threats) bomo identificirali ključne prednosti, slabosti, priložnosti in. pasti, ki jih prinaša pretvorba med BPMN in BPEL. Vnaprejšnje poznavanje slabosti in pasti nam namreč lahko prihrani mnogo časa in finančnih sredstev. Prednosti ■ Lažja implementacija. Pretvorba BPMN modela v BPEL skelet lahko olajša delo razvijalcem, saj ti ne izgubljajo časa s kreiranjem potrebnih aktivnosti in definiranjem zaporedja le-teh, temveč izvedejo le potrebne dopolnitve implementacije, kot so izdelava spletnih storitev, definiranje uporabniških opravil, izdelava in vključitev poslovnih pravil, dodajanje logike lovljenja in obravnave napak itd. ■ Lažja komvmikacija. Komunikacija med razvijalci in poslovnimi uporabniki je močno poenostavljena že samo z možnostjo kreiranja skeleta BPEL, vendar pa se še ne zaključi na tem koraku. Model poslovnega procesa se namreč lahko spreminja tudi, ko se je implementacija že začela. Razvijalec je obveščen o spremembi in lahko opravi združitev obeh modelov brez izgube dotedanjega dela. Prav tako lahko razvijalec poda predloge za spremembo procesa, ki jih mora nato potrditi ali zavreči poslovni uporabnik. ■ Implementacija se lahko začne še pred koncem modeliranja. Ker je proces v fazi implementacije mogoče kadar koli sinhronizirati z novo verzijo modela, se lahko implementacija začne še pred koncem modeliranja. Ta pristop pride v poštev predvsem v primerih, ko proces ne vsebuje kompleksnih ciklov. ■ Model ni več le statična risba. Klasičen pristop k BPM je v prvi fazi predvideval modeliranje poslovnega procesa, kasneje pa izvedbo implementacije. Ko so se tekom življenjskega cikla poslovnega procesa pojavile potrebe po spremembah, je temu po navadi sledilo le izvajanje sprememb v implementaciji, sam model pa se ni redno posodabljal. Model je torej postal statična risba brez konkretne uporabne vrednosti. Z avtomatsko pretvorbo med modelom BPMN in jezikom BPEL se temu izognemo ter tako zagotovimo, da je model ažuren v vsakem trenutku. Priložnosti ■ Odprava razkoraka med poslovnimi zahtevami in implementacijo. Možnost neposredne pretvorbe poslovnega modela v BPEL omogoča tesno po-ravnanost med pričakovanji poslovnih uporabnikov in funkcionalnostjo razvitih rešitev ■ Hitrejši razvoj in povečana fleksibilnost. Zaradi izboljšane komunikacije in lažje implementacije se lahko razvoj in vzdrževanje občutno pohitrita. Slabosti ■ Slaba berljivost procesov BPEL. Ker BPEL ne omogoča prikaza vlog, je preglednost procesa že v osnovi nekoliko slabša. V nekaterih primerih pa se lahko s pretvorbo preglednost še precej zmanjša. Najpogosteje se to zgodi ob pretvorbi kompleksnih ciklov. V tem primeru je smiselno razmisliti o znižanju nivoja kompleksnosti s pomočjo uporabe podprocesov. ■ Nedodelana orodja za pretvorbo. Ker je problem pretvorbe med BPMN in BPEL vse prej kot preprost, večino orodij za pretvorbo še vedno pestijo številne poporodne težave, kar lahko precej oteži razvoj. Pasti ■ BPEL ni primeren za implementacijo vseh poslovnih procesov. Če nismo dovolj pozorni, se nam lahko zgodi, da po končanem modeliranju ugotovimo, da modela ni mogoče preprosto pretvoriti, ali pa celo, da zaradi številnih ciklov BPEL sploh ni primeren za implementacijo. ■ Nujno je poznavanje osnov jezika BPEL. Nekaterih modelov BPMN zaradi omejitev pretvorbe ni mogoče neposredno pretvoriti v BPEL, temveč jih je treba pred tem ustrezno prilagoditi. To pa ni mogoče, če ne poznamo jezika BPEL. Omenjeno dejstvo lahko predstavlja precejšnjo oviro, saj je modeliranje v osnovi domena poslovnih analitikov in ne razvijalcev. 3.3 Implementacija in izvajanje Ko končamo z modeliranjem poslovnega procesa, je na vrsti implementacija. V preteklosti je programska oprema ponujala številne funkcionalnosti, ki so predstavljale podporo posameznim aktivnostim, vendar so poslovni proces še zmeraj vodili ljudje. Zaposleni so morali sami skrbeti za pravilno zaporedje aktivnosti, obveščanje ter prenos dokumentacije. Takšen pristop, imenujemo ga tudi klasični pristop k BPM, ima precej slabosti. Ker se je poslovni proces nahajal v glavah ljudi, je velik problem predstavljalo nepoznavanje. Poleg tega obstoječa inforniadjska podpora ni zagotavljala potrebne fleksibilnosti ter vpogleda v izvajanje poslovnih procesov. Kot alternativa klasitoemu pristopu se v zadnjem-času uveljavlja tudi uporaba rešitev ERP (Enterprise Resource Planning) [1]. Poslovni procesi orgarüzacij znotraj iste industrijske panoge so si v osnovi precej podobni, vendar je zaželeno, da jih organizacije poskušajo nekoliko prilagoditi in optimizirati ter na ta način na trgu vzpostaviti konkurenčno prednost. To velja predvsem za temeljne poslovne procese. Nekateri podporni poslovni procesi pa se med organizacijami bistveno ne razlikujejo in jih je smiselno podpreti z rešitvami ERP, ki omogočajo uporabo vgrajenih, standardiziranih poslovnih procesov. Vpeljava ERP je včasih celo cenejša kot razvoj lastnih rešitev. Na žalost pa na ta način ne moremo pokriti vseh potreb V organizaciji (statistično le okoli 40 odstotkov vseh procesov). Danes se vse bolj pojavljajo zahteve po tem, da so poslovni procesi in programska oprema čim tesneje sklopljeni. To pomeni, da je treba ob spremembi poslovnega procesa ustrezno prilagoditi tudi informacijsko podporo. Čas, potreben za prilagoditev obstoječih aplikacij (IT gap time), igra zelo pomembno vlogo in mora biti čim krajši, če želimo zagotoviti fleksibihiost. Vemo pa, da spremembe programske opreme praviloma zahtevajo veliko časa. S polno , informatizacijo poslovnih procesov se lahko znatno izboljša fleksibilnost ter omogoči vpogled v izvajanje in spremljanje poslovnih procesov. Ravno to pa omogoča SOA. SOA ni nov koncept, predstavlja pa najnovejši pristop k rešitvi starega problema, to je integracija v heterogenem okolju. SGA- tako. predstavlja-posebno vrsto porazdeljenih sistemov, v katerih so komponente sistema storitve. S svojo naravno podporo implementaciji in izvajanju poslovnih procesov zagotavlja odlično podporo vsem fazam življenjskega cikla. Celotno arhitekturo SOA prikcizuje sUka 6 [9]. Predstavitveni sloj 1 1.1. Uporabniška interakcija 1 pwi Sloj poslovnih storitev Sloj obstoječih IT rešitev Implementacija rešitev SOA je sestavljena iz dveh korakov. Prvi korak, imenujemo ga tudi pristop od spodaj navzgor, predvideva izpostavljanje funkcionalnosti v obliki ustrezno načrtovanih storitev. Pri tem se najpogosteje uporablja tehnologija spletnih storitev. Ker SOA promovira ponovno uporabo, je treba olajšati iskanje in uporabo razvitih storitev. To je naloga registra, ki predstavlja imenik arhitekture SOA in omogoča dinamično iskanje naslovov ter tako zagotavlja šibko sklopljenost. Ko imamo pripravljen nabor takšnih modularnih, šibko sklopljenih storitev, pride na vrsto združevanje oz. kompozicija teh storitev v poslovne procese, kar predstavlja procesni vidik realizacije SOA oz. pristop od zgoraj navzdol. Za kompozicijo poslovnih procesov se najpogosteje uporablja jezik BPEL, ki se je v zadnjem času uveljavil kot splošno sprejet standard na področju integracije. Ker je mogoča avtomatizirana preslikava med BPMN in BPEL, je odpravljen razkorak med poslovnimi zahtevami in dejansko implementacijo. Zelo pomemben člen v arhitekturi SOA predstavlja storitveno vodilo (ESB - Enterprise Service Bus). ESB predstavlja hrbtenico SOA in je zanesljivo storitveno ogrodje, ki ponuja transparentnost komunikacije med storitvami z uporabo različruh protokolov ter zagotavlja podporo varnosti, transakcijam, dostavi sporočil, usmerjanju ter transformacijam. Pristop SOA predvideva ločitev poslovnih pravil in implementacije, kar omogoča fleksibilnejše spreminjanje pravil, brez nepotrebnega programiranja. Za izvajanje pravil skrbi stroj za poslovna pravila (business rule engine), poslovni uporabniki pa lahko pravila spreminjajo s pomočjo za to prilagojenih vmesnikov. Pristop SOA pa ne poenostavi le postopka implementacije, temveč tudi samo izvajanje ter spremljanje. Procesi BPEL se izvajajo na procesnem strežniku, ki omogoča vključevanje ljudi v poslovne procese ter odlično podporo izvajanju tako kratkotrajrüh, kot tudi dolgotrajnih procesov. Mogoče je verzioniranje procesov ter vpogled v izvajanje posamezne instance. Za vsako instanco procesa si je možno ogledati sled (audit trail), kar omogoča enostaven pregled vhodov in izhodov pri klicih storitev ter posledično olajša iskanje napak. Izvajanje poslovnih procesov pa je mogoče spremljati tudi z orodji BAM, kar je podrobneje opisano v poglavju 3.4. Predstavljena arhitektura SOA torej omogoča polno podporo poslovnim procesom, odpravlja razkorak med poslovnimi zahtevami implementacijo ter močno poveča raven fleksibilnosti organizacije. 3.4 Spremljanje poslounih procesov Spremljanje poslovnih procesov nam omogočajo rešitve BAM. Glavni namen BAM-a je zagotoviti popoln nadzor nad izvajanjem poslovnih procesov v organizaciji, pri čemer je glavni poudarek na spremljanju učinkovitosti. Učinkovitost merimo s pomočjo ključnih kazalnikov uspešnosti (KPI). Primeri teh kazalnikov so: povprečni čas izvedbe instance, stroški za izvedbo instance ali posamezne aktivnosti, obremenjenost virov ipd. Kazalnike določimo v času implementacije poslovnega procesa. Vodstvo organizacije in vse osebe, odgovorne za posamezne poslovne operacije, spremljajo izvajanje s pomočjo nadzorne plošče (dashboard). Ključna komponenta BAM-a je čas, saj želimo spremljati izvajanje z miiumalnim zamikom (skoraj v realnem času). To omogoča pravočasno reagiranje v primeru kritičnih situacij. Seveda pa je treba najprej zbrati podatke, šele nato jih lahko prikazujemo. Odločitev, katere podatke bomo zbirali, je ključna, saj s tem postavimo omejitve za kasnejše oblikovanje nadzorne plošče. Poleg zbiranja podatkov je naloga BAM tudi njihova obdelava in predstavitev čim bolj preprosto in zgovorno, da predstavljajo temelj pri sprejemanju ključnih strateških odločitev. Zbrane podatke lahko BAM obdela na tri različne načine: ■ Takojšnja obdelava podatkov. KPI-ji so izračunani takoj in predstavljeni odgovornim osebam ali poslani v aplikacijo, ki je namenjena podpori pri odločanju. ■ V primeru kritičnih situacij (vrednost KPI je previsoka ali prenizka) so podatki samodejno posredovani odgovornim osebam (e-pošta, SMS) aU pa se prožijo samodejni korekcijski mehanizmi. ■ BAM se lahko uporablja tudi za samodejno pre-poznavo vzorcev vhodnih sporočil. Ker BAM zbira podatke iz različnih poslovnih procesov, lahko prepozna določene vzorce med procesi in reagira na njih (korekcijski mehanizmi, obveščanje). To v informacijski sistem vnaša dodatno stopnjo kontrole in fleksibilnosti. BAM nadzorna plošča (slika 7) mora biti čim bolj preprosta in pregledna. Večina orodij BAM pri gradnji nadzorne plošče omogoča uporabo grafičnih elementov, kot so grafi, krivulje ter preglednice. 3.5 Optimizacija Namen optimizacije je oblikovanje optimiziranega (to-be) modela poslovnega procesa. Podlaga za izvedbo optimizacije so KPI-ji, zbrani v fazi spremljanja. Investicijski proces Zadniie iiwtancp. \ 1011 Osobnov 10.3,ZOC 1D.3.200'INV PUBLICj: 28.3.200' Uspeäen;« 1010 Računalril 10.3.200 INV PUBUC.C 20.3.200' V Izvajan) 1009 Kombi 9.3.2009 mv PUBLIC_C 14.3.200'V Izvajanj 1008 Avtobus 9.3.2009 INV PUBLIC_C 21.3.200' V izvajanj 3 1007 Stavba 9.3.2009 GaS PUBIIC.C 7.3.2009 V izvajanj 1006 Strežnik 9.3.2009 INV DIRECTJ 12.3.200'V izvajanj i lOOS Nodem 9.3.2009 9.3.OT9 GaS PUBLIC_t 21.3.200' Nrizbrant^ 1004 Gsterna 9,3.2009 18.3.200' GaS.SV PUBUC.C 28.3.200'ZZNzavrr inn:i Tistolnik o.XTim 17.4.™ a,"; niRFrr i ?a.ft.7nn' lisn^m:» [jPravotasno Zamuda Stani, instanc'S « jts m itjt^ Traja -"P"'' ^vpre ^D^faja nj e o^a^ po u^^ b m ki h F* ^ ^ ^ S ^l! UPORABNIK Slika 7: Primer nadzorne ploiče BAM Izvedba optimizacije je zadnji korak v življenjskem ciklu poslovnega procesa in daje organizacijam možnost izboljšanja konkurenčnosti. Sistematični pristop k optimizaciji ima naslednje pozitivne učinke [1]: ■ Povečanje prodaje produktov in storitev zaradi izboljšane produktivnosti in boljše uporabniške izkušnje. ■ Znižanje stroškov je najbolj očiten pozitiven učinek in je predvsem posledica boljše izkoriščenosti ljudi in drugih sredstev. Tudi poenostavitev poslovnih procesov ima lahko za posledico nižje stroške. Včasih med optimizacijo identificiramo dele procesov, ki jih je mogoče izpostaviti kot samostojne procese in se lahko delijo med več procesi. ■ Izboljšanje učinkovitosti poslovnih operacij omogoča predvsem izboljšano koordiniranje zasebnih (procesi, ki so v celoti vezani na meje organizacije) in javnih procesov (procesi, ki vključujejo poslovne partnerje). Dostava »tik-pred-zdajci« in proizvodnja sta dva primera dobro usklajenih poslovnih procesov med več partnerji. ■ Izboljšanje zadovoljstva uporabnikov. Boljša podpora uporabnikom, hitrejši odzivni časi in izboljšana preglednost procesa (strarüca lahko na primer spremlja, kaj se dogaja s spletnim naročilom) so neposredno povezani z zadovoljstvom uporabnikov. ■ Izboljšano obvladovanje napak. Napake so najmanj zaželeni dogodki v poslovnih procesih, ker začasno prekinejo ali celo ustavijo normalno izvajanje. Optimiziranje in avtomatiziranje obvladovanja napak je lahko zelo koristno. Za nekatere specifične industrijske panoge obstajajo izdelani primeri dobrih praks poslovnih procesov. Uporaba tovrstnih ogrodij je priporočljiva, saj na ta način standardiziramo poslovni proces, olajšamo morebitno integracijo z drugimi podjetji znotraj industrijske panoge in poenostavimo merjenje učinkovitosti ter izvajanje optimizacij. Nekateri strokovnjaki so mnenja, da izražajo dobre prakse povprečno stanje v industriji. Če neki organizaciji koristi uporaba tovrstnih dobrih praks, to pomeni, da so njeni poslovni procesi pod povprečjem. Najuspešnejše organizacije namreč po navadi skrivajo svoje poslovne procese in tako zadržujejo konkurenčno prednost. V telekomunikacijskem sektorju je dobro poznano ogrodje eTOM (Enhanced Telecom Operations Map), ki definira dobre prakse, vezane na posamezne aspekte telekomunikacijske tehnologije, kot so upravljanje strank in dobaviteljev, obravnava zah- tevkov, obravnava napak, upravljanje SLA in QoS (Quality of Service), upravljanje storitev, konfigu-riranje in aktivacija storitev, upravljanje virov itd. Podobnih primerov dobrih praks bi lahko našteli še mnogo. Vsekakor pa je treba upoštevati, da se tudi organizacije znotraj iste panoge nekoliko razlikujejo in je po navadi treba splošne dobre prakse prilagoditi posamezni organizaciji. Po končani optimizaciji je realno vrednost izboljšav priporočljivo preveriti s ponovnim izvajanjem simulacij. Pri izvedbi optimizacije lahko naletimo na naslednje težave [1 ]: ■ Premalo domišljije. Pri optimizaciji se ni dobro omejiti le na odpravo ozkih grl, temveč je priporočljivo vključiti tudi izboljšave. ■ Nekritično posnemanje praks drugih organizacij. Čeprav je zaželeno proučiti izkušnje drugih organizacij, ne smemo pozabiti, da kar je dobro za druge, ni nujno dobro tudi za nas. ■ Prevelika pričakovanja. Pri modeliranju in opti-miziranju poslovnih procesov se ne smemo osre-diniti le na informacijsko podporo. Posledica tega so namreč lahko prevelika pričakovanja. Informacijska tehnologija ne more rešiti vseh problemov. ■ Neustrezne metrike. Če smo si zastavili napačne metrike za spremljanje poslovnega procesa (KPI), ne moremo realno oceniti učinkovitosti. a PREGLED TRENUTNEGA STANJA IN PRIČAKOVANI TRENDI Dosledna uporaba opisanega pristopa k celostnemu upravljanju poslovnih procesov po načelih SOA se v praksi počasi uveljavlja, čeprav je trenutno prej izjema kot pravilo. Številne organizacije namreč še niso dosegle stopnje zrelosti, ki je potrebna za prehod na SOA. Glede na raziskave družbe Forrester Research [12] se tudi v organizacijah, v katerih že imajo večletne izkušnje s SOA, pogosto zadovoljijo le z izdelavo modela poslovnega procesa in ločeno implementacijo, torej brez avtomatizirane pretvorbe in spremljanja izvajanja. To je do neke mere tudi razvimljivo, saj nekatere platforme SOA še ne nudijo podpore vsem fazam predstavljenega življenjskega dkla. Pomembno pa je poudariti dejstvo, da se vedno več organizacij zaveda pomena celovitega obvladovanja poslovnih procesov in se jih vedno več odloča za vpeljavo SOA. V pripravi so nove specifikacije za modeliranje poslovnih procesov (BPMN 2.0 [11]) in razširitve jezika BPEL, ki rešujejo nekatere identificirane pomanjkljivosti. Tudi vodilni ponudniki rešitev SOA vlagajo veliko truda v razvoj zmogljivejših orodij, ki bodo poenostavila in pohitrila razvoj ter podpirala najnovejše standarde. Na podlagi omenjenih dejstev lahko upravičeno sklepamo, da se bo v prihodnjih letih v praksi močno razširil opisani pristop k upravljanju poslovnih procesov. 5 SKLEP v prispevku smo spoznali celovit pristop k upravljanju poslovnih procesov v SOA s poudarkom na fazah modeliranja, implementacije in izvajanja. Na začetku smo identificirali težave, s katerimi se organizacije pogosto soočajo pri obvladovanju svojih poslovnih procesov. Spoznali smo dobre prakse pri modeliranju poslovnih procesov ter pomen uporabe notacije BPMN. Nadalje smo predstavili predlog postopka pretvorbe BPMN modela v BPEL ter s pomočjo analize SWOT spoznali ključne prednosti, slabosti, priložnosti in pasti avtomatizirane pretvorbe. Opisali smo tri pristope k implementaciji BPM: klasični pristop, uporabo rešitev ERP ter pristop SOA. Pristop SOA se je v praksi izkazal kot najbolj učinkovit, saj odlično podpira implementacijo, izvajanje in spremljanje poslovnih procesov ter veča raven fleksibilnosti in učinkovitosti. Ključne prednosti BPM s pristopom SOA so tako izboljšano dokumentiranje in razumevanje poslovnih procesov, lažje uvajanje novo zaposlenih, vpeljava standardov kakovosti, poenostavljen razvoj novih rešitev, vpogled v izvajanje ter spremljanje izvajanja poslovnih procesov. Končni rezultat celostnega upravljanja življenjskega cikla poslovnih procesov z uporabo SOA je tako izboljšana učinkovitost in konkurenčnost celotne organizacije. 6 VIRI IN LITERATURA [1] Jurič, M., Pant, K. (2008). Business Process Driven SOA using BPMN and BPEL, 1- izd., Pacl