U N I V E R Z A V L J U B L J A N I

Transcription

1 U N I V E R Z A V L J U B L J A N I EKONOMSKA FAKULTETA MAGISTRSKO DELO M A N A G E M E N T P O S L O V N I H P R O C E S O V LJUBLJANA, MAJ 2005 PETER GERŠAK

2

3 IZJAVA Študent Peter Geršak izjavljam, da sem avtor tega magistrskega dela, ki sem ga napisal pod mentorstvom prof. dr. Andreja Kovačiča in skladno s 1. odstavkom 21. člena Zakona o avtorskih in sorodnih pravicah dovolim objavo magistrskega dela na fakultetnih spletnih straneh. V Ljubljani, dne Podpis:

4

5 KAZALO VSEBINE 1. UVOD Namen magistrskega dela Opis praktičnega primera Cilj magistrskega dela Uporabljene metode dela, predpostavke, trditve in omejitve TEORETIČNI DEL Prenova poslovanja Opredelitev poslovnega procesa Opredelitev managementa poslovnih procesov Cilji, učinki in tveganja uvedbe managementa poslovnih procesov Zgodovinski vidik managementa poslovnih procesov Prenova prenove poslovnih procesov Cilji in problemi prenove poslovnih procesov Primerjava prenove in managementa poslovnih procesov Management kakovosti Celovit management kakovosti Metodologija šest sigma Primerjava metodologij celovitega managementa kakovosti in šest sigma Od identificiranja do managementa poslovnega procesa Metode spremljanja in analize poslovnih procesov Metode modeliranja poslovnih procesov Simulacija poslovnih procesov Prihodnost managementa poslovnih procesov Standardi za management poslovnih procesov Implementacija managementa poslovnih procesov Storitveno orientirana arhitektura Sistem za management poslovnih procesov PRAKTIČNI DEL Tehnološke komponente Modeliranje in analiziranje Izvajalno okolje Nadzorovanje in management Opis primera poslovnega procesa Modeliranje in analiziranje procesa naročanja polizdelkov Model obstoječega stanja "kot-je" procesa naročanja polizdelkov Analiziranje "kot-je" procesa naročanja polizdelkov Predlog prenove "naj-bo" modela procesa naročanja polizdelkov Analiziranje "naj-bo" modela naročanja polizdelkov Prenos "naj-bo" procesa naročanja polizdelkov v izvajalno okolje Finalizacija "naj-bo" procesa za izvajalno okolje Izgradnja uporabniškega vmesnika za ročne aktivnosti "naj-bo" procesa Avtomatizacija aktivnosti in povezovanje uporabniških programov "naj-bo" procesa Določevanje poslovnih mer za nadzorovanje "naj-bo" procesa naročanja polizdelkov...89

6

7 3.6. Nadzorovanje izvajanja "naj-bo" procesa naročanja polizdelkov Analiziranje istočasnega spremljanja izvajanja "naj-bo" procesa Analiziranje zgodovine izvajanja "naj-bo" procesa ZAKLJUČEK LITERATURA IN VIRI PRILOGE Slovar slovenskih prevodov tujih izrazov Opis uporabljenih kratic Primeri poti "kot-je" procesa naročanja "Kot-je" model procesa naročanja polizdelkov Primeri poti "naj-bo" procesa naročanja "Naj-bo" model procesa naročanja polizdelkov "Kot-je" in "naj-bo" modeli procesa naročanja polizdelkov Opis tabel v JPK bazi podatkov v DDL jeziku Opis vsebine tabel v JPK bazi podatkov v DML jeziku Opis "naj-bo" procesa naročanja polizdelkov v FDL jeziku KAZALO SLIK Slika 1: Časi sprememb, ki jih pogojuje poslovno okolje....6 Slika 2: Razširjen Leavitt-ov diamant....8 Slika 3: Shematski prikaz poslovnega procesa Slika 4: Podpora BPM korenitim in postopnim spremembam poslovnih procesov Slika 5: Povezovanje EAI in B2B v BPM kontekstu...15 Slika 6: Porterjev model petih tekmovalnih sil Slika 7: Vrste poslovnih procesov in njihova delitev Slika 8: Temeljni cilji prenove poslovanja...18 Slika 9: Glavne tehnologije ter njihov vpliv na spreminjanje in prenavljanje poslovnih procesov Slika 10: Porterjeva vrednostna veriga...24 Slika 11: Rummler-Branch diagram nivojev in pogledov organizacije Slika 12: Demingov PDCA krog nenehnega izboljševanja poslovnih procesov...33 Slika 13: Gausova krivulja in standardna deviacija Slika 14: DMAIC metodologija izvedbe šest sigma projektov...34 Slika 15: Življenjska doba poslovnega procesa...36 Slika 16: Standardi BPM Slika 17: Shematičen prikaz sistema za management poslovnih procesov Slika 18: IBM On-Demand arhitektura Slika 19: Organizacijska shema podjetja JPK d.d Slika 20: Proces naročanja polizdelkov v širšem kontekstu podjetja JPK d.d Slika 21: Cilji prenove procesa naročanja polizdelkov...63 Slika 22: Meje kot-je procesa naročanja polizdelkov Slika 23: Terminski plan izvedbe projekta prenove procesa naročanja polizdelkov....66

8

9 Slika 24: Kot-je proces naročanja polizdelkov na najvišjem nivoju Slika 25: Razvit kot-je model procesa naročanja polizdelkov...67 Slika 26: "Naj-bo" model procesa naročanja polizdelkov na najvišjem nivoju Slika 27: Razvit naj-bo model procesa naročanja polizdelkov Slika 28: Modeliranje procesa naročanja polizdelkov v integracijskem načinu...81 Slika 29: Podatkovna struktura S_NP za naj-bo proces naročanja polizdelkov Slika 30: WebSphere MQ Workflow spletni odjemalec Slika 31: WebSphere Studio Application Developer in WMQWF RAD dodatek Slika 32: JSP strani za izvajanje ročnih aktivnosti procesa naročanja polizdelkov...85 Slika 33: JSP strani za vnos odgovorov dobaviteljev za proces naročanja polizdelkov Slika 34: WBI Message Broker aplikacija JPK_8 VnosDobaveVERP Slika 35: Entitetno relacijski model JPK baze podatkov in tabel za proces naročanja polizdelkov...88 Slika 36: Določevanje poslovnih mer v WebSphere Business Integration Modeler orodju...90 Slika 37: Spremljanje in upravljanje izvajanja posameznih primerov procesa naročanja polizdelkov z WBI Monitor orodjem...91 Slika 38: Prikaz in analiza izvajanja primera naj-bo procesa naročanja polizdelkov KAZALO TABEL Tabela 1: Razlike med tradicionalno in procesno organizacijo...8 Tabela 2: Prehod iz konvencionalne v procesno orientirano organizacijo...9 Tabela 3: Razlogi za neuspeh BPR in BPM pogled na njih...31 Tabela 4: Primerjava BPR in BPM Tabela 5: Primerjava TQM in metodologije šest sigma Tabela 6: Različni vidiki in metode modeliranja poslovnih procesov Tabela 7: Preteklost, sedanjost in prihodnost BPM...42 Tabela 8: Primerjava BPM standardov...44 Tabela 9: Viri in stroški virov udeleženih pri kot-je procesu naročanja polizdelkov Tabela 10: Aktivnosti kot-je procesa naročanja polizdelkov...62 Tabela 11: SWOT analiza kot-je procesa naročanja polizdelkov Tabela 12: Aktivnosti posameznih faza projekta prenove procesa naročanja polizdelkov in stroškovna analiza...65 Tabela 13: Odločitvene točke kot-je procesa naročanja polizdelkov, možne izbire in njihove verjetnosti pojava Tabela 14: Možne poti skozi kot-je proces naročanja polizdelkov in njihove verjetnosti pojava...68 Tabela 15: Časovna in stroškovna analiza kot-je proces naročanja polizdelkov po metodi povprečnih utežnostih faktorjev Tabela 16: Viri in stroški virov pri izvajanju naj-bo procesa naročanja polizdelkov Tabela 17: Rezultati simulacije kot-je procesa naročanja polizdelkov po aktivnostih...71 Tabela 18: Rezultati simulacije kot-je procesa naročanja polizdelkov po vlogah in oddelkih....72

10

11 Tabela 19: Aktivnosti naj-bo procesa naročanja polizdelkov...74 Tabela 20: Odločitvene točke naj-bo procesa naročanja polizdelkov, možne izbire ter verjetnosti pojava Tabela 21: Možne poti skozi naj-bo proces naročanja polizdelkov in njihove verjetnosti pojava Tabela 22: Časovna in stroškovna analiza naj-bo procesa po metodi povprečnih utežnostih faktorjev...76 Tabela 23: Viri in stroški virov pri izvajanju naj-bo procesa naročanja polizdelkov Tabela 24: Rezultati simulacije naj-bo procesa naročanja polizdelkov po aktivnostih Tabela 25: Rezultati simulacije naj-bo procesa naročanja polizdelkov po vlogah in oddelkih...80 Tabela 26: Podatki aktivnosti naj-bo procesa naročanja polizdelkov za integracijski način Tabela 27: Avtomatske aktivnosti naj-bo procesa naročanja polizdelkov Tabela 28: Določitev poslovnih mer Tabela 29: Procent pojavljanja primerov poti pri izvajanju naj-bo procesa naročanja polizdelkov ter njihovi stroški...93 Tabela 30: Resnični podatki izvajanja naj-bo procesa naročanja polizdelkov...93 Tabela 31: Časovna in stroškovna analiza izvajanja naj-bo procesa po metodi povprečnih utežnostnih faktorjev Tabela 32: Viri in stroški virov izvajanja naj-bo procesa naročanja polizdelkov Tabela 33: Rezultati simulacije resničnega procesa naročanja polizdelkov po aktivnostih Tabela 34: Rezultati simulacije resničnega procesa naročanja polizdelkov po vlogah in oddelkih...95 Tabela 35: Utežnostna povprečja stroškov virov in časa trajanja procesa naročanja polizdelkov...100

12

13 1. UVOD Podjetje ima spletno trgovino. Vendar za spletno stranjo, kjer stranke naročajo izdelke, pogosto ni vse tako kot bi moralo biti. Velikokrat se dokumenti, že vneseni v bazo podatkov, ponovno tiskajo; nato se ponovno, včasih tudi s tipkarskimi napakami, vnašajo v različne uporabniške programe; kopije dokumentov pozabljene obležijo na delovni mizi; faksi "letijo" naokoli ipd.. Vsa ta zmešnjava in neurejenost poslovnega procesa kažejo na to, da organizacija nima ustreznega in z ustreznimi informacijskimi tehnologijami podprtega managementa poslovnih procesov (angl. Business Process Management, BPM). Ko stranka pokliče in vpraša kako je z njenim naročilom, vsekakor ne želi slišati: "Oprostite, vašega naročila pa nimamo nikjer zavedenega! Kdaj ste ga vnesli? Kaj ste naročili?" Vendar ni potrebno, da je tako! V začetku devetdesetih let prejšnjega stoletja se je, kot ena izmed ključnih rešitev za težave, ki so v prehodu v informacijsko družbo pestile večino organizacij, pojavila prenova poslovnih procesov (angl. Business Process Reengineering, BPR). Šlo je za nov način izboljševanja delovanja organizacij, usmerjen v analiziranje in spreminjanje celotnega poslovanja, ki zahteva korenite spremembe in drugačen pogled vodstva na poslovanje organizacije. Prenovo poslovnih procesov lahko opredelimo kot temeljito preverjanje poslovnih procesov in njihovo korenito spremembo z namenom, da se doseže zniževanje stroškov, poveča kakovost izdelkov, skrajšajo dobavni roki ipd. (Kovačič et al., 2004, str 58-72). Management poslovnih procesov je ena izmed oblik prenove, ki zajema veliko več kot sama prenova poslovnih procesov (Kovačič et al., 2004). Je naslednja logična razvojna stopnja, ki zajema BPR in vključuje od analize obstoječega stanja procesa do opazovanja obnašanja in korekcij novega procesa v izvajanju, kar razlagata avtorja v svoji knjigi Business Process Management: The Third Wave (Smith, Fingar, 2003). Omenjena avtorja trdita tudi, da se je ob prelomu tisočletja začelo tretje obdobje managementa poslovnih procesov. Prvo BPM obdobje je trajalo nekako sedemdeset let do začetka devetdesetih let prejšnjega stoletja. Zaznamovali so ga ročno izvajani (neavtomatizirani) procesi, ki so bili implicitno vsebovani v delovnih nalogah. V drugem BPM obdobju so bili procesi prenavljani na zelo brutalen način. Hammer in Champy v knjigi Reengineering the Corporation: A Manifesto for Business Revolution opisujeta preurejanje poslovanja kot začeti znova. Njuna formalna definicija preurejanja podjetja je sestavljena iz štirih besed: temeljen, korenit, dramatičen in procesi (Hammer, Champy, 1993, str ). Avtorja zagovarjata, da je potrebno star poslovni proces zavreči ter narediti novega, boljšega, kar se je v praksi izkazalo kot zelo težko izvedljivo. V drugo obdobje spadajo tudi sistemi za načrtovanje virov podjetja (angl. Enterprise Resource Planning, ERP). Doug Neal iz Computer Sciences Corporation Research Services je pojasnil: Preden je ERP sistem nameščen ima vse lastnosti še ne strjenega betona, ter vse lastnosti strjenega betona po namestitvi. (povzeto po Smith, Fingar, 2003). Podjetja torej potrebujejo metodologijo za izboljševanje poslovnih procesov, ki jih ne bo omejila na sicer preurejene poslovne procese, ki pa mogoče že čez leto ali dve ne bodo več odgovarjali aktualnim razmeram poslovanja, ampak bo podjetju dopuščala fleksibilnost pri spreminjanju poslovnih procesov v realnem času. 1

14 Tretje obdobje managementa poslovnih procesov omogoča to kar sta bili pomanjkljivosti prejšnjih dveh obdobij: matematičen, formalen opis poslovnih procesov, postopno izboljševanje poslovnih procesov, odprte standarde za opis in izvajanje poslovnih procesov ter razvojno in izvajalno okolje, popolnoma podprto s strani informacijske tehnologije. Iz zornega kota informacijske tehnologije je za tretje BPM obdobje ključnega pomena načrtovanje informacijskih sistemov, ki so sposobni zaznavati spremembe poslovnega okolja ter se na njih pravilno in pravočasno prilagoditi (Smith, Fingar, 2003). Management poslovnih procesov obsega celotno življenjsko dobo poslovnega procesa: od njegove zaznave, modeliranja in analize, integracije potrebnih komponent, izvajanja, nadzora, do managementa in njegovih korekcij. Programska oprema, ki nudi informacijsko tehnološko podporo celotnemu življenjskemu ciklu procesa, se imenuje sistem za management poslovnih procesov (angl. Business Process Management System, BPMS) (Bosilj-Vukšić, Kovačič, 2004). Z uporabo BPMS programske opreme lahko podjetje zazna spremembe v poslovanju ter hitro spremeni in prilagodi poslovni proces na nivoju pogojev prehoda iz enega v drugo stanje, ne pa na nivoju (pre)programiranja uporabniških programov. V prvi fazi analize in modeliranja poslovnih procesov se s pomočjo namenske programske opreme naredi posnetek obstoječega stanja procesa, ki ga imenujemo kot-je model (angl. As-Is Model). Po analizi obstoječega procesa se naredi eden ali več predlogov modelov prenove procesa. Predlog prenove procesa se imenuje naj-bo model (angl. To-Be Model). Z različnimi variantami naj-bo modela se potem s pomočjo simulacij, ugotavlja način doseganja željenih sprememb. Ugotavlja se, kako doseči, da bi postal proces stroškovno učinkovitejši, zmogljivejši, enostavnejši, prijaznejši ipd. (Kovačič et al., 2004). Harmon navaja malce drugačno terminologijo. Kot-je model poslovnega procesa imenuje "je" model (angl. Is Model), končni naj-bo model pa imenuje bo model (angl. Should Model). Uvaja tudi "lahko" modele (angl. Could Model), ki niso nič drugega kot različne variante naj-bo modelov (Harmon, 2003). V nadaljevanju bomo za prenavljane poslovne procese uporabljali poimenovanje kot-je in naj-bo. Po analizi in modeliranju pride na vrsto prenos končnega naj-bo modela poslovnega procesa v izvajalno okolje. Teži se k največji možni stopnji avtomatizacije poslovnega procesa. Zato je potrebno preučiti kateri, uporabniški programi in na kakšen način bodo sodelovali v poslovnem procesu. Pogosto, odvisno od informacijskega sistema, ki ga podjetje ima, prav integracija uporabniških programov (angl. Enterprise Application Integration, EAI), ki temelji na storitveno orientirani arhitekturi (angl. Service Oriented Architecture, SOA), je predpogoj za uspešno uvedbo managementa poslovnih procesov (Slak, Geršak, 2002). Ponavadi procesa ni mogoče popolnoma avtomatizirati, ker v njem sodelujejo tudi ljudje z ročnimi aktivnostmi. Za izvajalno okolje lahko podjetje izbere BPMS programsko opremo, ki vključuje sistem za management delovnega toka (angl. Workflow Management System, WfMS) ter programske opreme za opazovanje in merjenje uspešnosti izvajanja poslovnega procesa. Ta programska oprema zajema podatke o času izvajanja procesa, trenutno stanje določenega primera procesa, kdo je izvedel določeno aktivnost, strošek procesa ipd.. Iz analize teh podatkov je razvidno ali je bil dosežen prvotni namen izboljšanja procesa. Če namen ni bil dosežen, se modeliranje naj-bo procesa ponovi. Nato se model ponovno prenese v izvajalno okolje, kjer se zopet preverja njegovo obnašanje. Uvedba BPM prinese podjetju poslovno fleksibilnost, kar je za uspešna podjetja nepogrešljiva lastnost v svetu, kjer vlada potezni (angl. Pull) model tržišča, kjer stranke same oblikujejo razmere na tržišču in 2

15 njegovo hitrost spreminjanje (Kovačič et al., 2004, str. 317). Lahko rečemo, da so zelo daleč tisti časi, ko je Henry Ford dejal za svoj slavni T-model avtomobila: Lahko ga kupite v katerikoli barvi, samo v črni mora biti!. Management poslovnih procesov je sveti gral, ki prinese podjetju, če ga najde, konkurenčno prednost pred ostalimi podjetji na tržišču Namen magistrskega dela Magistrsko delo je razdeljeno na teoretični in praktični del. Namen teoretičnega dela je opredelitev managementa poslovnih procesov, njegove zgodovine, sedanjosti in prihodnosti, potrebnih korakov za uspešno uvedbo v podjetje, opredelitev tehnoloških rešitev in standardov ter pregled teorij, ki jih management poslovnih procesov implicitno vsebuje, kot je na primer prenova poslovnih procesov, in ki so komplementarne managementu poslovnih procesov, kot je na primer koncept šest sigma. Namen praktičnega dela je prikaz BPM metodologije v praksi. Ročno izvajani poslovni proces naročanja polizdelkov bo s pomočjo BPM programske opreme modeliran, analiziran, avtomatiziran, postavljen v izvajanje ter nadzorovan. S pomočjo resničnih podatkov o izvajanju procesa, bo proces ponovno analiziran. Uporabljena bodo BPM orodja podjetja IBM, ki je znan proizvajalec BPM programske opreme. To bo prvi takšen primer uporabe IBM BPM orodij v Sloveniji Opis praktičnega primera Podjetje JPK d.o.o. proizvaja kakovostna kolesa za svetovni trg. Imajo lastno proizvodnjo polizdelkov; veliko polizdelkov naročajo tudi pri dobaviteljih. Vodstvo podjetja ima namen analizirati celoten proces skladiščnega poslovanja. Še posebej želi izboljšati proces nabave polizdelkov. Podjetje imenuje ta proces proces naročanja polizdelkov. Vodstvo ima občutek, da proces traja predolgo časa, preveč stane ter, da imajo na račun tega tudi večje stroške skladiščenja polizdelkov in izdelkov. Želijo, da bo nov proces naročanja stroškovno učinkovitejši, zmogljivejši, prilagodljivejši, enostavnejši ter lažje obvladljiv. Želijo tudi izboljšati odnose z dobavitelji in preiti na nove načine komunikacije z njimi. Trenutno poslujejo z dobavitelji preko faksov in elektronske izmenjave podatkov (angl. Electronic Data Interchange, EDI), želijo pa vsaj delno preiti na spletno poslovanje med podjetji (angl. Internet Business-to-Business, B2Bi oz. B2B 1 ). Oddelek planiranja proizvodnje v ERP sistemu pripravi zahtevo za povečanje zalog v skladišču. Količina in vrsta polizdelkov se določi glede na naročila kupcev, ki ji podjetje JPK d.o.o. trenutno ima, ter glede na navodila oddelka konstrukcije. V ERP sistemu obstaja tabela dobaviteljev z naborom polizdelkov, ki jih dobavitelj lahko dobavi. Vsakemu polizdelku, ki se ga želi naročiti, se pripiše določen dobavitelj, nato oddelek za planiranje proizvodnje sproži v ERP sistemu proceduro, ki odloži podatke v obliki datotek na datotečni sistem. Imena datotek so enaka kot je šifra dobavitelja v ERP sistemu. 1 Pravilna okrajšava za elektronsko poslovanje preko svetovnega spleta je B2Bi. Vendar se večinoma v praksi uporablja samo okrajšava B2B (Gavin et al., 2003). 3

16 Oddelek skladiščnega poslovanja pošlje določenemu dobavitelju poizvedbo ali je dobavitelj sposoben dobaviti željeno količino polizdelkov. Odvisno od dobavitelja sta možna dva načina pošiljanja te zahteve. Približno 80% zahtev se preko faksa pošlje dobavitelju. Ostalih 20% zahtev se ročno vnese v EDI uporabniški program. Dobavitelj ima do tri delovne dni časa, da odgovori na zahtevo po enaki poti kot je zahtevo dobil. Možni so trije odgovori: 1. Zahtevani polizdelki bodo dobavljeni v celoti. Odgovor (potrjena zahteva) se pošlje dobavitelju preko faksa ali po EDI (odvisno od dobavitelja). 2. Zahtevani polizdelki bodo dobavljeni delno. Odgovor (delno potrjena zahteva) se pošlje dobavitelju preko faksa ali po EDI (odvisno od dobavitelja). Za tiste sestavne dele, ki ne bodo dobavljeni, mora podjetje poiskati nadomestnega dobavitelja. Proces se mora torej ponoviti. 3. Dobavitelj v celoti ne more dobaviti zahtevanih polizdelkov. Podjetje mora poiskati nadomestnega dobavitelja in celotni proces se ponovi. Ko podjetje prejme potrjeno, delno potrjeno ali zavrnjeno zahtevo, pošlje dobavitelju naročilnico po enaki poti, kot prej zahtevo, ter počaka na dobavo Cilj magistrskega dela Glavni cilj magistrskega dela je slovenski javnosti približati management poslovnih procesov. To magistrsko delo je razdeljeno na dve logični celoti: teoretični in praktični del. V teoretičnem delu bomo opredelili osnovna izhodišča in metodologijo izvajanja managementa poslovnih procesov. Pogledali bomo sledeče: Kaj je poslovni proces? Kaj je management poslovnih procesov? Zgodovinski vidik managementa poslovnih procesov. Katere so teorije komplementarne managementu poslovnih procesov. Kakšna je metodologija izvajanja managementa poslovnih. S pomočjo teoretičnih osnov managementa poslovnih procesov bomo v drugem delu te naloge prikazali praktični primer uporabe managementa poslovnih procesov v praksi. Za ponazoritev primera bomo uporabili poslovni proces naročanja polizdelkov v namišljenem podjetju JPK d.o.o.. V ta namen bomo s programsko opremo za management poslovnih procesov prikazali sledeče: modeliranje in analiziranje poslovnega procesa, prikaz integracije in avtomatizacije uporabniških programov, ki sodelujejo pri izvajanju procesa, postavitev poslovnega procesa v izvajanje, izvajanje in nadzorovanje izvajanja poslovnega procesa, analiziranje zgodovine izvajanja poslovnega procesa. 4

17 1.4. Uporabljene metode dela, predpostavke, trditve in omejitve Za rešitev zadane problematike je potreben sistematičen pristop. Najprej je potreben študij domače in mednarodne literature, pristojne za področje integracije uporabniških programov, modeliranja, prenove in managementa poslovnih procesov ter ostalih komplementarnih teorij in standardov. Ta študij je osnova za teoretični del magistrskega dela. Za izvedbo praktičnega primera modeliranja, analiziranja, izvajanja in nadzorovanja poslovnega procesa bomo uporabili metodologijo managementa poslovnih procesov (slika 4, str. 13). Praktični primer bomo izvedeli z IBM WebSphere programsko opremo. To bo prvi prikaz celovite programske rešitve za management poslovnih procesov v Sloveniji, ki je v celoti zasnovan na IBM programski opremi. Kolikor je znano, v Sloveniji še nihče ne uporablja celotne palete IBM BPMS programske opreme. Ključne trditve pri poslovnem procesu naročanje polizdelkov so naslednje: 1. Z uvedbo metodologije managementa poslovnih procesov trdimo, da se bo stopnja avtomatizacije aktivnosti dvignila iz popolnoma ročnega kot-je procesa (gledano po številu avtomatskih aktivnosti) na vsaj 60% avtomatiziranih aktivnosti naj-bo procesa. 2. Simulacija kot-je procesa naročanja polizdelkov bo pokazala dejanske stroške posameznih možnih poti procesa. Trdimo, da je strošek komunikacijske poti z dobavitelji preko EDI ob uspešno izvedenem naročilu nižji kot pri komunikacijski poti preko faksa. 3. Zaradi dviga stopnje avtomatizacije v naj-bo procesu bo potreba po udeležbi človeških virov manjša kot pri kot-je procesu. Trdimo, da bo ta potreba manjša za vsaj 8 delovnih ur oz. vsaj en udeleženec procesa za njegovo uspešno izvajanje ne bo več potreben. 4. Aktivnost pošiljanje dokumenta dobavitelju po faksu se trenutno izvaja ročno. Trdimo, da jo je s pomočjo primerne programske opreme možno popolnoma avtomatizirati. 5. Trdimo, da je lahko prenos dokumentov med aktivnostmi v naj-bo procesu naročanja polizdelkov popolnoma elektronski. 6. Aktivnost pregledovanje odgovorov in primerjava z zahtevo je ročna, vendar bi se jo dalo v naj-bo procesu naročanja polizdelkov popolnoma avtomatizirati. 7. Trdimo, da se investicija v prenovo poslovnih procesov z metodologijo BPM in v BPMS programsko opremo, ob izbiri vsaj treh za prenovo ustreznih poslovnih procesov, povrne v manj kot treh letih. 8. Komunikacijski poti z dobavitelji sta dve: faks (80% vseh dokumentov) in elektronska izmenjava podatkov EDI (20% vseh dokumentov). V primeru, da se uvede še B2B komunikacijska pot s predpostavko, da se nadomesti 60% pošiljanja dokumentov preko faksa, trdimo, da bi podjetje lahko razpolovilo stroške in čas naročanja polizdelkov. Omejitve pri prikazu praktičnega primera so vsebovane v dejstvu, da je proces naročanja polizdelkov v podjetju JPK d.d. izmišljen. Vendar ne glede na to, izhaja ta proces iz avtorjevih izkušenj pri delu v Oracle Slovenija d.o.o., kjer je delal kot nabavni uslužbenec za nabavo Oracle programske opreme. Pridobljene izkušnje je uporabil že pri izdelavi diplomske naloge z naslovom Razvoj informacijskega sistema za skladiščno poslovanje (Geršak, 1997). V diplomski nalogi je tudi razvil entitetno-relacijski model baze 5

18 podatkov. V magistrskem delu zato predpostavljamo, da bralec pozna tovrstno snovanje baz podatkov ter zato razvoj modela baze podatkov za podjetje JPK d.d. ni razložen do potankosti. Tehnično znanje za implementacijo bo avtor črpal iz več kot 5-letnih izkušenj dela pri IBM Slovenija d.o.o. na področju tehničnega svetovanja o WebSphere programski opremi za poslovno integracijo (angl. WebSphere Business Integration, WBI). Pri praktičnem prikazu modeliranja bo avtor sledil modelu življenjske dobe poslovnega procesa na sliki 4, stran 13. Le-ta prikazuje življenjsko dobo poslovnega procesa, ki se prične z identifikacijo in vodi preko modeliranja, postavitve v izvajanje, izvajanja, nadzora do analize in optimalizacije. To zaporedje aktivnosti se ponavlja skozi celotno življenjsko dobo procesa. 2. TEORETIČNI DEL V hitro se spreminjajočem poslovnem okolju se pred organizacijo in s tem seveda pred informatizacijo kot infrastrukturno dejavnostjo postavlja zahteva po sprotnem in učinkovitem prilagajanju spremembam. Samo uspešne organizacije, ki bodo hitro in ustrezno odgovorile na nove izzive, bodo lahko dolgoročno v takšnem poslovnem okolju tudi preživele. Slika 1 kaže drastičnost teh sprememb, ki prikazujejo prehod iz industrijske v informacijsko dobo. Slika 1: Časi sprememb, ki jih pogojuje poslovno okolje. Vir: Kovačič et al., 2004, str. 5. V zadnjih desetletjih opažamo, da se korenito krajša proizvodni cikel, čas izvedbe procesa in dinamika prenove poslovnih procesov oz. prenove poslovanja. Na tej osnovi lahko predvidimo ključna vplivna področja, ki jih bo v prihodnosti potrebno posebej in dosledneje obravnavati, v smislu učinkovitejšega odgovora na s strani poslovnega okolja pogojene spremembe. Ta vplivna področja so: poslovno načrtovanje, poslovni procesi, kadri, podatki in informacije ter znanje. Tradicionalno načrtovanje poslovanja, ker izhaja predvsem iz preteklih dogodkov, ne daje ustreznih rezultatov. Iz tega razloga se vedno bolj uveljavlja načrtovanje poslovne in konkurenčne vizije, katerima je osnova strateška vizija organizacije. Seveda se morajo spremembi vizije prilagoditi tudi poslovni procesi, ki naj bi to vizijo izvajali. Ključnega pomena je, da se ti poslovni procesi lahko hitro in enostavno prenavljajo ter prilagajajo trenutnim tržnim razmeram in konkurenci, ki se pojavlja na trgu. Da bi organizacija lahko hitro 6

19 in enostavno prenovila ter prilagodila poslovne procese, lahko uporabi informacijsko tehnologijo (angl. Information Technology, IT), ki je ključnega pomena za pravočasno izvajanje poslovnih odločitev. Eden izmed novejših pristopov k prenovi poslovnih procesov je management poslovnih procesov (Kovačič et al., 2004, str. 4) Prenova poslovanja 21. stoletje bo nedvomno prineslo nove dejavnike, kot so metode poslovanja, tehnologije ipd., ki bodo vplivali na organizacije, delavce, kupce ter na samo poslovanje. Čeprav smo komaj na začetku stoletja, je na podlagi raznih znanstvenih raziskav in interpolacij že moč predvidevati dejavnike, ki bodo usmerjali poslovanje organizacij. Eisner (Eisner, 2000) navaja naslednje dejavnike: informacijska doba se nadaljuje, hitrost in odzivnost poslovanja se stopnjuje, vedno večja konkurenčnost na globalnem tržišču (zagotavljanje višje kakovosti, krajših časov izdelave ter nižjih stroškov), pojavljajo se novi delovni vzorci in okolja (delo na domu ipd.), lojalnost dobrega delavca (strokovnjaka) do delodajalca se manjša, saj lahko dober strokovnjak v vsakem trenutku zapusti delodajalca in najde zaposlitev drugje. V prihodnosti bodo preživele samo organizacije, ki bodo sposobne upoštevati in uporabljati te dejavnike sebi v prid, še posebej dejavnika konkurence in informacijske dobe ter z njima povezanega svetovnega spleta ter elektronskega poslovanja. Da bi organizacije bile tega sposobne, potrebujejo prenovo poslovanja v smeri preoblikovanja, prestrukturiranja ali prenove poslovnih procesov ob uporabi sodobnih informacijskih tehnologij. Poslovni procesi so največkrat nepregledni, nedokumentirani in neprilagodljivi. Potekajo skozi različne funkcijske celote oz. oddelke ter vsebujejo vse probleme, ki se tradicionalno pojavljajo pri prehodu iz enega oddelka v drugega. Splošne pomanjkljivosti izvajanja poslovnih procesov v veliki večini organizacij so naslednje: neenotnost izvajanja, nepoznavanje celotnega procesa (izvajalci poznajo samo aktivnosti, ki jih izvajajo), podvajanje dela, dolgi čakalni časi za podpise, odobritve, pošto ipd.. Takšna organizacija se bo morala soočiti z dejstvom prenove poslovanja ali pa bo odmrla. Poslovne procese bo morala poenotiti, dokumentirati, opredeliti njihove značilnosti ter jih prenoviti. Prenovljenemu poslovnemu procesu je potrebno zagotoviti potrebno organizacijsko in informacijsko podporo (Kovačič et al., 2004). Prenovo poslovanja moramo gledati v širšem smislu, ne samo v smislu uvedbe informacijskih tehnologij. Leavitt je v članku Allied Organizational Change in Industry: Structural, Technological and Humanistic Approaches (Leavitt, 1965 in El Savy, 2001) pojasnil, da pri spreminjanju organizacije (prenovi poslovanja) ne gre samo za tehnološki vidik, ampak tudi za vidik kadrov, vidik organizacijske strukture in vidik nalog. 7

20 Svoj vidik je predstavil s sliko, ki se imenuje Leavitt-ov diamant in prikazuje, da so vsi štirje vidiki enako pomembni in soodvisni. Razširjen Leavittov diamant, kateremu je dodan vidik kulture je prikazan na sliki 2. Slika 2: Razširjen Leavitt-ov diamant. Vir: Kovačič et al., Vidik kulture vsebuje izhodišča za pripravo pogojev v širši družbi in organizaciji, ki bodo naklonjeni spremembam, ter ocenjuje možnosti, obravnava strateške cilje in strategijo prenove in izvajanja sprememb. Kadrovski vidik obravnava možnosti dviga razpoložljivosti, prilagodljivosti in produktivnosti obstoječih človeških virov. Sodobne organizacije gradijo na lastnih, obstoječih kadrih. Hkrati se trudijo zadržati in pridobiti nove dobre kadre. Vidik informacijskih tehnologij omogoča modeliranje, izvajanje in management prenovljenih poslovnih procesov. Vidik strukture obravnava strukturo organizacije, kjer potekajo ponavadi procesi skozi več funkcijskih enot. Za uspešno prenovo poslovnega procesa je potrebno uvesti takšne organizacijske strukture, ki bodo omogočale čimvečje sodelovanje med enotami. Tabela 1: Razlike med tradicionalno in procesno organizacijo. Tradicionalna organizacija Procesna organizacija poslovni izid poslovna funkcija poslovni proces organizacijska enota oddelek delovna skupina opis dela ozko določen širok osredotočenost nadrejeni kupec nadomestilo temelji na aktivnosti rezultatih vloga managementa nadzor mentorstvo ključna oseba direktor poslovne funkcije lastnik procesa poslovna kultura konfliktno naravnana sodelovanje Vir: Hammer, Tradicionalna organizacijska struktura je delitev organizacije na funkcijske silose, ki privede do organiziranosti organizacije v organizacijske enote (oddelke) in poslovne funkcije, ki so med seboj nepovezane ter so kot utrdbe znotraj same organizacije. Organizacijske enote so pomembnejše od procesov in projektov. Organizacija optimalizira organizacijske enote, da so učinkovite in donosne, vendar gre to ponavadi v škodo celotne organizacije, ki je ravno zaradi tega manj učinkovita in donosna. Razlike med tradicionalno organizacijo in organizacijo, usmerjeno na celovite procese, so navedene v tabeli 1. Prehod iz tradicionalnega mišljenja v procesno orientirano mišljenje je težak. Potrebno je spremeniti celotno strukturo organizacije iz klasične hierarhične v horizontalno, to je organizacijo, ki ima kolikor se le da malo hierarhičnih stopenj. V tabeli 2 poglejmo, kaj se pri tem prehodu spremeni. 8

21 Tabela 2: Prehod iz konvencionalne v procesno orientirano organizacijo. Prehod iz konvencionalne funkcijski oddelki enostavna opravila nadzorovani izvajalci trening zaposlenih plačilo po izkušnjah in porabljenem času plačilo narašča z napredovanjem in časom prisotnosti napredovanje odvisno od sposobnosti zaščitniška organizacijska kultura vodje nadzirajo in kontrolirajo hierarhična organizacijska kultura ločitev na zadolžitve in funkcije masovna proizvodnja delo v pisarni v procesno organizacijo. procesne skupine opolnomočeni izvajalci pooblaščeni izvajalci izobraževanje zaposlenih plačilo po rezultatih/učinku nizko plačilo z visokimi bonusi odvisnimi od učinka oz. uspešnosti napredovanje odvisno od rezultatov produktivna organizacijska kultura vodje usmerjajo in svetujejo horizontalna timsko delo procesnih skupin masovno prilagajanje kupcem delo kjerkoli Vir: Kovačič, Prenova poslovanja se je z leti razvijala. S tem se je spreminjalo tudi poimenovanje le-te. Poglejmo različna poimenovanja prenove v angleškem in v slovenskem jeziku. Prenova poslovanja se je razvila v smeri celovite prenove poslovanja, h kateri so pristopi različni: od radikalnih sprememb do postopnega izboljševanja poslovnih procesov. V literaturi je metodologija celovite prenove poslovanja poznana pod različnimi imeni, ki se razlikujejo glede na radikalnost in pogostost sprememb ter glede na čas, ko je neka metodologija prenove bila aktualna (poglavje Zgodovinski vidik managementa poslovnih procesov). Najpogosteje uporabljena angleška imena za prenovo poslovanja so naslednja: Business Process Reengineering (na primer Hammer, 1993), Business Process Redesign in Process Innovation (na primer Davenport, 1993), Business Process Change (na primer Harmon, 2003), Business Performance Management (na primer BPM Magazine), Business Renovation (na primer Kovačič, 2004a), Business Process Improvement (na primer Harrington, Esseling, Nimwegen, 1997), Business Process Restructuring (na primer Bosilj-Vukšić, Ćurko, Kovačič, 2000), X-engineering (na primer Champy, 2002 in Attaran, Attaran, 2004), Business Process Management (na primer Smith, Fingar, 2003). V slovenski literaturi se za prenovo poslovanja pojavljajo sledeči izrazi: prenova poslovnih procesov (na primer Kovačič, Peček, 2002), preurejanje poslovnih procesov 2, reinženiring poslovnih procesov (na primer Česen, 1998), management poslovnih procesov (na primer Kovačič, 2004). V magistrskem delu bomo uporabljali izraz management poslovnih procesov oz. njegovo angleško kratico BPM. Kronološko gledano je izraz management poslovnih procesov naslednik izraza prenova poslovnih 2 Izraz, uporabljen v slovenskem prevodu knjige Michael Hammer, James Champy: Reenginering the Corporation: A Manifesto for Business Revolution. Knjigo sta prevedli Lili Potpara in Bernarda Petelinšek. Leta 1995 jo je izdal Gospodarski vestnik. 9

22 procesov (BPR). Vendar celotna stvar ni tako enostavna, ker BPM predstavlja širši pojem in temelji na nekoliko drugačni metodologiji kot BPR. Razlike med BPM in BPR bodo pojasnjene v naslednjih poglavjih tega dela Opredelitev poslovnega procesa Slovar slovenskega knjižnega jezika razlaga: Proces je celota del, delovanja za dosego kakega cilja: načrtovati, organizirati, usmerjati proces; delovni, proizvodni proces, izobraževalni, vzgojni proces ali poslovni (ki se nanaša na posel) (Bajec et al., 1994). V strokovni literaturi je moč zaslediti veliko definicij poslovnega procesa. Naj jih navedemo samo nekaj: 1. Poslovni proces opredeljujemo kot seštevek dejavnosti, ki zahteva eno ali več vrst vložkov in ustvarja rezultat, ki za odjemalca pomeni neko vrednost (Hammer, Champy, 1993, str. 45). 2. Proces je strukturiran, merljiv nabor aktivnosti, katerega izhod je določen izdelek ali storitev za določenega kupca na tržišču (Davenport, 1993, str. 5). 3. Poslovni proces je nabor aktivnosti, ki kupcu predstavljajo neko vrednost. Predstavlja tok materiala, informacij in poslovnih obveznosti od zasnove do prodaje izdelka ali storitve. Proces je ponavadi dolgo trajajoč in podprt z informacijskimi tehnologijami. Mora biti transakcijski in sodelovalen z ostalimi procesi. Njegove aktivnosti se lahko izvajajo avtomatsko in/ali ročno (Smith, 2002, str. 44). 4. Poslovni proces opredeljujemo kot takšno sestavo logično medsebojno povezanih izvajalskih in nadzornih aktivnosti, katerih posledica je proizvod (izdelek ali storitev). Poslovni procesi tipično ne potekajo v samo eni organizacijski enoti, pač pa posamezne aktivnosti izvajajo različni oddelki (Kovačič et al., 2004, str. 58). 5. Poslovni proces se lahko opiše kot niz logičnih aktivnosti, ki izkoriščajo vire organizacije. Glavni cilj poslovnega procesa je zadovoljevanje potreb kupca po proizvodih in storitvah zadovoljive kakovosti in cene v ustreznem časovnem terminu in ob istočasnem ustvarjanju vrednosti (Bosilj- Vukšić, Kovačič, 2004, str. 9). Vsem zgornjim definicijam poslovnega procesa je skupen vhod in izhod ter ustvarjanje dodane vrednosti, kar je prikazano na sliki 3. Osnovne značilnosti poslovnega procesa so naslednje (Kovačič, 2005): vsak proces ima svoj cilj, vsak proces naj bi imel lastnika, vsak proces ima svoj začetek in konec, v proces vstopajo vhodi ter izstopajo izhodi (na primer izdelek, storitev, informacije, znanje ipd.), proces je sestavljen iz zaporedja izvajanja korakov, glede na vhode in izhode procesa se lahko zbirajo merljive značilnosti iz katerih se lahko ugotavlja učinkovitost procesa, da proces sploh lahko obstaja, mora imeti znane notranje in/ali zunanje kupce in dobavitelje, nenehno izboljševanje procesa. 10

23 Slika 3: Shematski prikaz poslovnega procesa. Vir: Kovačič et al., 2004, str. 59. Ni nujno, da je vsak proces, ki izpolnjuje zgornje osnovne značilnosti dober proces. Z izrazom dober proces razumemo naslednje značilnosti: proces je orientiran na kupca, stalno dvigovanje dodane vrednosti izhodov iz procesa (izdelkov ali storitev), proces ima znanega in sposobnega lastnika, proces je razumljiv in sprejet s strani vseh v njemu sodelujočih, postavljena so merila uspešnosti in učinkovitosti procesa, ki se dajo tudi meriti, nenehno izboljševanje procesa Opredelitev managementa poslovnih procesov Vsakdo je v svojem vsakdanjiku obdan z desetinami poslovnih procesov poslovnih procesov, ki so zapletena, vedno spreminjajoča se manifestacija ekonomske aktivnosti organizacije. Organizacije neprestano iščejo nove poslovne procese s katerimi se bodo razlikovale od konkurence na tržišču ter orodja, ki jih bodo pomagala v dobi informacijske tehnologije dinamično spreminjati in upravljati. Prav z uporabo in trenutno stopnjo razvitosti informacijske tehnologije lahko v tem trenutku govorimo o novi dobi celovite prenove poslovanja. O dobi, kjer strategija podjetij ni več zamenjava procesa z novim, temveč o strategiji in orodjih za upravljanje neprestanih sprememb poslovnih procesov v realnem času. Ta strategija in orodja za upravljanje neprestanih sprememb poslovnih procesov v realnem času se imenujejo BPM. BPM razkriva kaj organizacija dela in nato upravlja spremembe in optimalizacije na način, ki je neposredno povezan s proizvodnim okoljem. BPM je naslednik BPR in odpravlja njegove pomanjkljivosti (Smith, Fingar, 2003). Vendar BPM ni samo naslednik BPR, ampak ponuja še veliko več. Poglejmo na BPM iz večih zornih kotov in ga poskusimo razumeti. Vedeti tudi moramo, da je BPM relativno mlada disciplina in kot taka še na določenih področjih nedefinirana. Različnim ljudem pomeni BPM različne stvari. Poskusimo jih zaobjeti in definirati kaj BPM je (Smith et al., 2002): A. Poslovni procesi so kompleksni, dinamični, distribuirani in prilagojeni. Prehajajo skozi različne oddelke in različne informacijske sisteme. Tako so dejanski procesi v organizacijah: Obsežni in zapleteni. Vključujejo tok materiala, podatkov in poslovnih pravil. Zelo dinamični, saj se morajo prilagajati spremembam tržišča. Distribuirani in prilagojeni glede na poslovne zahteve in glede na aplikacije in tehnološke platforme. Dolgo trajajoči posamezen primer procesa lahko teče dneve, mesece, celo leta. Vsaj delno avtomatizirani z informacijsko tehnologijo. 11

24 Odvisni od človeške presoje. Ljudje delajo naloge, ki so preveč kompleksne in nestrukturirane, da bi jih računalnik lahko izvajal ali pa so to naloge, ki zahtevajo človeško komunikacijo; na primer osebna interakcija s stranko. Velikokrat nevidni in jih je težko narediti vidne. Procesi ponavadi niso eksplicitni in zavedni, ampak implicitni, nezavedni, nedokumentirani in vgrajeni v zgodovino organizacije. B. IT do sedaj ni bila zmožna uspešno implementirati oz. digitalizirati poslovne procese. Namenska programska oprema (aplikacije) se je že od nekdaj uporabljala kot podpora poslovnim procesom. Dandanašnji so tovrstne aplikacije postale zaledne (angl. Legacy Application); so zanesljive, vendar ne ustrezajo novim zahtevam po prilagodljivosti. Organizacija z velikim številom zalednih aplikacij se ne more hitro in brez težav prilagajati, ker je logika poslovnih procesov zapečena v aplikacijah. Te pomanjkljivosti naj bi odpravili ERP sistemi. Poleg tega naj bi podpirali večino potreb organizacije po programski opremi ter podpirali zapletene in medsebojno povezane poslovne procese. V praksi ERP sistemi niso prinesli, kar so obljubljali, predvsem zaradi zapletenega in dragega vmesnega programja (angl. Middleware) za povezovanje različnih ERP sistemov z ostalimi aplikacijami. WfM sistemi so bili še ena obetajoča tehnologija. Podpirajo predvsem statične poslovne procese. Prinesli so ločitev poslovne logike od aplikacijske logike. Prinesli so tudi gibčnost, saj se lahko pogoji prehodov enostavno in hitro spreminjajo. Dve glavni pomanjkljivosti WfM sistemov sta: prvič, ne da si jih enostavno podaljšati do partnerjev (drugih organizacij), drugič, večina WfM sistemov ni dobra pri povezovanju različnih aplikacij, ki sodelujejo v procesu. Dandanes organizacije uporabljajo razne tehnike povezovanja za implementacijo njihovih poslovnih procesov. Tipične tehnike so naslednje: sporočilna hrbtenica (angl. Messaging Backbone), integracijski posredniki (angl. Integration Brokers), ORB posredniki (angl. Object Request Broker), WfM sistemi in nadzorniki transakcij (angl. Transaction Monitors, TM). Seveda je težko, drago in zamudno upravljati z vsem tem vmesnim programjem in razvijati potrebne vmesnike do aplikacij. Poleg tega ta arhitektura ne podpira dovolj dobro poslovnih procesov, ki se razprostirajo preko meja organizacij (procesov na B2B nivoju). Organizacije potrebujejo tehnologije za BPM, ki bodo enostavne za uporabo, zelo prilagodljive in sposobne premostiti ovire povezovanja poslovanja in tehnologije. C. BPM pomeni nadzor celotnega poslovnega procesa vse do kupca (slika 4, stran 13). BPM je zmožnost identifikacije, snovanja, postavitve v izvajanje, izvajanja, interakcije, delovanja in vzdrževanja, optimalizacije ter analize poslovnih procesov od začetka do konca procesa na nivoju poslovnega načrtovanja in ne na nivoju tehnične implementacije. BPM zagotavlja zanesljivo izvrševanje zapletenih, diskretnih poslovnih transakcij, ki lahko trajajo tedne, mesece ali celo leta. Identifikacija pomeni, da do podrobnosti vemo kako deluje proces interno in eksterno. Poenoti razumevanje sistemov in aktivnosti, ki so vključeni v poslovni proces. Poleg tega vključi vse, ki sodelujejo v procesu v fazo načrtovanja. Avtomatizirana identifikacija poslovnih procesov je ena izmed funkcionalnosti BPMS sistema. Načrtovanje pomeni modeliranje, oblikovanje, simuliranje ter ponovno načrtovanje procesa, ko organizacija ugotovi resnične meje procesa. Tudi hitra sestava in razgradnja procesov je ena izmed funkcionalnosti BPMS. 12

25 Slika 4: Podpora BPM korenitim in postopnim spremembam poslovnih procesov. Vir: Smith, 2002, str. 8. Postavitev v izvajanje (angl. Deployment) pomeni dati nov proces v izvajanje. Z dobrim BPMS je postavitev novih procesov v izvajanje enostavno opravilo, ki naj bi se izvedlo z zelo malo programiranja. Aplikacije so že vnaprej povezane in se zavedajo procesov (angl. Process Aware). Izvajanje pomeni, da poslovni proces teče in ga uporabljajo vsi soudeleženi viri (ljudje, druge organizacije, sistemi, ostali procesi ipd.). BPMS mora upravljati distribuirane transakcije, ki se raztezajo med novimi procesi in starimi zalednimi aplikacijami. Interakcija pomeni, da lahko ljudje upravljajo z ročnimi aktivnostmi procesa. Delovanje in vzdrževanje pomeni vzdrževanje BPMS in procesov, ki tečejo na njem ter razreševanje posebnih situacij in napak pri izvajanju procesa. Optimalizacija je izboljševanje procesa. Pomeni povratno zanko med načrtovanjem in vzdrževanjem. BMPS naj bi avtomatsko zaznaval in odpravljal ozka grla, mrtve zanke (angl. Deadlock) in ostala nekonsistentna stanja v procesu. Analiza je merjenje učinkovitosti procesa ter na podlagi rezultatov meritev odločanje o nadaljnji strategiji izboljševanja procesa. 13

26 D. BPM se izvaja po pristopu od vrha navzdol (angl. Top-Down). Orodja BPM bodo poenotila raznorodne funkcionalnosti vmesnega programja. Vsak element v BPMS arhitekturi je storitev, ki jo poslovni proces lahko kliče. Največja prednost tega je neodvisnost snovanja procesa od tehnične postavitve. Ta pristop ne vsiljuje, da bi celoten proces moral biti BPM-iziran naenkrat, niti ne vsiljuje, da bi morala organizacija imeti samo en, vse obsegajoči model procesa. Vsekakor pa je možno uvajati BPM vzporedno na vseh nivojih organizacije. Ta vzporedni model se pogosto uporablja v kombinaciji z od spodaj navzgor pristopom integracije aplikacij. E. Vse poti vodijo k BPMS, ki bo postal IT srce poslovnega sistema organizacije. Pojavila se je nova generacija IT orodij in sistemov, katerih naloga je koordinacija drugih sistemov ali ljudi. Poimenovani so različno: četrti nivo IT arhitekture, nove sestavljene aplikacije, naslednja generacija WfM sistemov, nova platforma za aplikacije ali pametnejše vmesno programje. Vsekakor vsi ljudje mislijo na isto, to je na BPMS. BPMS mora: integrirati različne sisteme oz. aplikacije (tudi zaledne), avtomatizirati rutinske aktivnosti, upravljati vse faze procesa (vključno z identifikacijo in analizo), enostavno postaviti proces v izvajanje ter zagotavljati kontrolo, transakcijsko integriteto 3 in nedvoumno izvajanje procesa. F. Integracija znotraj IT organizacije se srečuje z napori integracije navzven. Dve ločeni vrsti integracije. Prva je v organizacijo usmerjena integracija aplikacij, ki je ne zanima sodelovanje s partnerji ampak predvsem integracija aplikacij v organizaciji (angl. Application to Application, A2A). Z A2A integracijo in vmesnim programjem za EAI, poskušajo te organizacije povezati različne programske rešitve kot so ERP, WF, management oskrbovalne verige (angl. Supply Chain Management, SCM), management odnosov s strankami (angl. Customer Relationship Management, CRM) ipd.. Druga vrsta integracije je navzven usmerjeno povezovanje s poslovnimi partnerji in strankami (B2B), ki zajema EDI, elektronsko poslovanje in trgovanje, sodelovalno trgovanje 4 (angl. Collaborative Commerce) ipd.. Ti dve vrsti integracije se srečujeta pod imenom BPM (slika 5, stran 15). Na meji med tema dvema svetovoma integracije se seveda srečujejo poslovni procesi, ki so znotraj organizacij narejeni po meri in kot taki nesposobni prilagajanja navzven. Potreba je po uvedbi eksplicitnih, s standardi določenih procesov, s katerimi bodo organizacije komunicirale med sabo. Vendar EAI niti B2B nista dovolj za celotno rešitev. Organizacije potrebujejo standarde in orodja, ki bodo sposobna opisati tako notranje kot tudi zunanje procese, to je celotno vrednostno verigo. G. IT tehnologije se združujejo v BPMS. Posamezne tehnologije so se izkazale nemočne odgovoriti na zahteve modernega poslovanja. Zato se te tehnologije združujejo in izboljšujejo, da bodo sposobne ustrezati zahtevam BPMS. Na primer: Sistemi WfM so ključna funkcionalnost, so most med avtomatiziranimi in ročnimi procesi. 3 Štiri lastnosti vsake transakcije so: atomarnost, doslednost, izolacija in obstojnost (angl. atomicity, consistency, isolation and durability, ACID). 4 Sodelovalno trgovanje predstvalja (v okviru skupnosti) poslovne interakcije med podjetji, poslovnimi partnerji in strankami na podlagi elektronske izmenjave podatkov. 14

27 Integracija aplikacij je infrastrukturno orodje. Je dobra za povezovanje sistemov, vendar ne za sodelovanje. Nadzornik transakcij in aplikacijski strežnik (angl. Application Server) sta tudi infrastrukturno orodje, ki izvaja poslovni proces na nivoju objektov in ne vsebuje višje abstrakcije procesa. B2B integracija. Poslovni partnerji in stranke imajo svoje zapletene poslovne procese, ki jih je potrebno upoštevati pri modeliranju ter klicati v času izvajanja. Delitev na privatne in javne procese ni dobra, saj ne prinese zadosti velike učinkovitosti spremembe poslovnih procesov. Spletne storitve (angl. Web Services, WS) so abstrakcija aplikacijskega vmesnika in definicija poslovne storitve. Postajajo zaželjena arhitektura za izpostavljanje storitev, ki jih je aplikacija sposobna ponuditi. Slika 5: Povezovanje EAI in B2B v BPM kontekstu. Poglejmo še dve definiciji managementa poslovnih procesov: Vir: Smith, 2002, str.14. BPM je nov pristop prenove poslovnih procesov. Je popolnoma poslovni pristop k managementu sprememb pri prenovi poslovnih procesov in kot tak namenjen poslovnim ljudem in ne specialistom informacijske tehnologije. Spremembe vključujejo celoten življenjski cikel poslovnega procesa od identifikacije, analize, snovanja, do informatizacije in avtomatizacije izvajanja poslovnega procesa. Pri pristopu BPM naredimo samo eno definicijo poslovnega procesa v fazi analize, iz katere je potem možno izluščiti različne poglede na ta poslovni proces in na podlagi tega zgraditi oz. prilagoditi informacijski sistem organizacije. Ta univerzalen opis procesa pomeni, da ljudje z različnimi znanji (poslovni direktorji, poslovni analitiki, programerji 15

28 ipd..) lahko vidijo proces in manipulirajo z njim. Bistvo je v tem, da pri tem vsak uporablja svoj pogled na isti proces in svoj uporabniški vmesnik, ki ga razume, v osnovi pa manipulirajo vsi samo z eno izvorno različico procesa. (Smith, Fingar, 2003). V The New Agenda je predsednik podjetja IBM Samuel Palmisano naznanil novo obdobje elektronskega poslovanja (angl. e-business) obdobje poslovanja na zahtevo (angl. On-Demand), katere jedro je BPM in informacijska podpora BPM. Obdobje poslovanja na zahtevo je definiral kot (Palmisano, 2002): Organizacija znotraj katere so poslovni procesi od začetka do konca medsebojno integrirani ter ima poslovne procese integrirane tudi s ključnimi poslovnimi partnerji, dobavitelji in kupci, lahko odgovori fleksibilno in hitro na katerokoli zahtevo kupcev, tržno priložnost ali zunanjo grožnjo Cilji, učinki in tveganja uvedbe managementa poslovnih procesov Podjetja, ki bodo spoznala moč in uvedla BPM, se bodo oborožila s sposobnostjo digitalne predstavitve, izvajanja in upravljanja procesov, na ravni, ki si je nekaj let nazaj ni bilo moč zamisliti. Smith in Fingar (Smith, Fingar, 2003) sta v svoji knjigi navedla zgornjo misel. Poglejmo zakaj mislita tako. Porterjev model tekmovalnih sil nas uči, da mora biti organizacija privlačna, da doseže dobičkonosnost. Tekmovalna strategija mora zrasti iz razumevanja pravil konkurenčnosti, ki definirajo privlačnost organizacije. Osnovni cilj tekmovalne strategije je, da obvladuje ta pravila ter jih tudi spreminja v korist organizacije. V vsaki gospodarski dejavnosti, pa najsi bo izdelčno ali storitveno naravnana, obstaja pet tekmovalnih sil (slika 6): grožnja novih konkurentov, grožnja novih proizvodov, pogajalska moč kupcev, pogajalska moč dobaviteljev in tekmovanje med obstoječimi konkurenti. Teh pet tekmovalnih sil določa profitabilnost industrije, kar vpliva na cene proizvodov, z njimi povezane stroške ter zahteva vlaganje organizacij v lasten razvoj (Porter, 1985). Slika 6: Porterjev model petih tekmovalnih sil. Vir: Porter, 1985, str

29 BPM je disciplina, s katero se lahko doseže nenehno izboljševanje in prilagajanje strateških poslovnih procesov organizacije ter s tem pripomore k večji konkurenčnosti organizacije znotraj industrije. Gonilne sile BPM so predvsem ekonomske narave. Dandanes sta dva glavna ekonomska trenda komoditizacija 5 in globalizacija. Informacije o produktih in njihovih cenah so globalno in kadarkoli na voljo, trgovske meje med državami in regijami izginjajo. Odgovor poslovnega sveta je usmeritev na produktivnost, iskanje strateških zaveznikov za sodelovanje ter predajanje nestrateških procesov zunanjim izvajalcem (angl. Outsourcing). Slika 7 prikazuje delitev poslovnih procesov glede na strateško pomembnost ter zapletenost in dinamiko spreminjanja procesov. Vidimo, da je poslovna vrednost procesa tem večja, čim večji so ti trije dejavniki. V zgornjem desnem kvadrantu so za organizacijo najbolj strateško pomembni procesi. To so najbolj dinamični in zapleteni procesi, ki razlikujejo organizacijo od ostalih njej podobnih ter določajo konkurenčno prednost. BPM je namenjen predvsem upravljanju tovrstnih procesov. Slika 7: Vrste poslovnih procesov in njihova delitev. Vir: Smith, 2002, str. 45. Hammer in Champy sta v svoji knjigi (Hammer, Champy, 1993 in 2001) prepoznala tri skupine organizacij, ki se lotevajo prenove poslovnih procesov 6 : 1. Organizacije v krizi. V tej skupini so organizacije, ki so zašle v hude težave in nimajo nobene izbire. Stroški teh organizacij so neprimerno večji kot pri konkurenci, poslovanje s strankami je porazno, doživljajo kritiko, njihovi proizvodi so povsem neuspešni. 2. Organizacije v pred-kriznem obdobju. Gre za organizacije, ki še niso v težavah, vendar vodstvo vidi težave na obzorju. Morda so trenutni finančni rezultati še zadovoljivi, a se v daljavi že kažejo problemi; prihajajo novi tekmeci, spreminjajo se zahteve trga, pojavljajo se spremembe v pravnem in gospodarskem okolju. 5 Komoditizacija (angl. Commoditisation): porast števila podobnih izdelkov na tržišču. Posledično to pomeni nižje cene izdelkov, manjši dobički proizvajalcev ter zmanjšana ali nikakršna konkurenčna prednost. 6 Hammer in Champy sta leta 1993 napisala knjigo Reengineering the Corporation: A Manifesto for Business Revolution, ki sta jo leta 2001 dopolnila ter uporabljala še vedno enak izraz: prenova poslovnih procesov. Zaradi tega lahko v tem odstavku razumemo, da imata BPR in BPM enak pomen. 17

30 3. Organizacije, ki so med najuspešnejšimi. V tej skupini so organizacije, ki nimajo sedanjih težav in tudi v prihodnosti jih ne vidijo, vendar je njihovo vodstvo ambiciozno in agresivno. Organizacije vidijo v prenovi poslovnega procesa priložnost za pridobivanje novih konkurenčnih prednosti. Cilji prenove (Kovačič et al., 2004, str ) temeljijo na težnji po učinkovitosti procesa in uspešnosti poslovanja oz. delovanja prenovljenih procesov. Učinkovitost procesa merimo skozi rezultat porabe virov (surovine, človeški viri, finančni viri ipd.), uporabljenih za pretvorbo vhodov v izhode. Ali je proces uspešen nam pove tržišče in prodajni rezultati izhoda procesa (izdelka ali storitve). Torej, pri uresničevanju ciljev poskušamo poiskati optimum treh omejujočih, medsebojno odvisnih, običajno nasprotujočih si temeljnih ciljev oz. kriterijev: časa, stroškov in kakovosti. Te tri soodvisne cilje lahko grafično ponazorimo s trikotnikom na sliki 8. Slika 8: Temeljni cilji prenove poslovanja. Vir: Kovačič et al., 2004, str. 64. Vsak krak trikotnika predstavlja enega od možnih ciljev. Npr: lahko proizvedemo običajni izdelek hitro in z majhnimi stroški, ne moremo pa proizvesti hitro in z majhnimi stroški zelo kakovostnega izdelka. V tem primeru so stroški omejitveni kriterij. Osnovna izhodišča in globalni cilji celovite prenove poslovnih procesov, pa najsi bo to korenita prenova (BPR) ali postopna prenova (BPM), so naslednji: Poenostavitev poslovnih procesov z odstranitvijo nepotrebnih aktivnosti. Skrajševanje poslovnega cikla oz. vseh poslovnih procesov v organizaciji, dvig odgovornosti in posledično znižanje stroškov poslovanja. Dvigovanje dodane vrednosti v vseh poslovnih procesih ter postopno dvigovanje kakovosti proizvodov in storitev organizacije. Zniževanje stroškov izvajanja procesov ob ohranjanju ustreznega razmerja do kakovosti in časa. Dvigovanje zanesljivosti ter doslednosti izvajanja procesov in s tem dvigovanje kakovosti proizvodov in storitev. Prenova procesov v smeri tesnejšega in bolj neposrednega povezovanja z dobavitelji in strankami. Usmerjanje v lastne, ključne zmožnosti in prenos izvajanja ostalih procesov, ki niso ključni ali kjer organizacija ni konkurenčna, izven organizacije. Hammer je v svoji knjigi The Agenda (Hammer, 2001) navedel zanimivo misel: Način kako shajati z neprestanimi spremembami je narediti skrajno prilagodljivo organizacijo, ki izniči časovna zaostajanja ter nikoli ne gleda v prihodnost. Deluje samo v sedanjosti ter zaznava in takoj odgovorja na spremembe. 18

31 To je velik strateški cilj, ki ga BPR nikoli ni mogel uresničiti. Uresniči pa ga lahko BPM z zagotavljanjem naslednje funkcionalnosti (Smith, Fingar, 2003, str. 96): BPM omogoča direktni prehod iz vizualizacije (modeliranja, simuliranja) v izvajanje procesa. BPMS je platforma, kjer se vrši to izvajanje in omogoča, da so poslovni procesi na voljo ljudem, partnerjem in različnim sistemom. Možnost spremembe procesa v izvajanju in v fazi snovanja. Procesi se lahko povezujejo in sodelujejo med sabo. Procesi v izvajanju ohranjajo svoje stanje, tako da se v izvajanju in kasneje v analizi lahko uporabi tako struktura procesa (na primer podatki) kot tudi stanje (na primer kje je proces obtičal). Možnost vključevanja poslovne inteligence ter zajem posebnih dogodkov in zmožnost hitrega odgovora na njih. Obstaja samo en osnovni razlog, da organizacija uvede BPM: izboljšanje učinkovitosti za doseganje konkurenčne prednosti ter za povečanje vrednosti izdelkov in vrednosti organizacije za delničarje. To je glavna prednost BPM. Seveda so še druge, ki so tudi zelo pomembne (BPMG, Spanyi, 2004): Jasno definirana organizacijska struktura in razdelitev vlog. Organizacijska strategija, vizija in poslanstvo izraženi v BPM terminologiji jasno določijo usmerjenost organizacije. Boljša razporeditev organizacijskih virov. S pravilnim merjenjem, izboljševanjem in upravljanjem poslovnih procesov dosežemo večjo urejenost in prilagodljivost organizacije v njenem vsakodnevnem delovanju. Skupina Gartner (Gartner, 1997) je objavila raziskavo z naslovom: Nine Reasons Why IS Organizations Do Not Do BPM. V tej raziskavi je prikazanih devet glavnih vzrokov zakaj organizacije ne uporabljajo modeliranja poslovnih procesov 7. Ti vzroki, gledani z očmi IT ljudi, so naslednji: 1. Poslovni oddelki ne bodo hoteli sodelovati. 2. Poskusili smo informacijska orodja, pomagajo obvladovati vse vidike informatizacije (angl. Computer Aided Software Engineering, CASE), vendar nam niso bila všeč. 3. Nimamo časa za to. 4. Poslovni oddelki nam povedo kaj naj programiramo, mi jih ne sprašujemo. 5. Sinhronizacija med poslovnimi in IT modeli nam ne uspeva. 6. Poslovanje se spreminja prehitro, da bi si ga uspelo in splačalo modelirati. 7. Ali ni dovolj modeliranje aplikacij v fazi razvoja? 8. Ali ni dovolj izdelava prototipa? 9. Z modeliranjem je več težav kot pa je vredno. Sedem let pozneje lahko pogledamo na takratno modeliranje poslovnih procesov kot na razvoj modeliranja in poskus zapolnjevanja praznine, ki jih je takratno modeliranje imelo. Poglejmo teh devet razlogov v BPM luči: 1. Poslovni oddelki ne bodo hoteli sodelovati. 7 Modeliranje poslovnih procesov je bilo takratno poimenovanje dandanašnjega managementa poslovnih procesov. 19

32 Mnogi so modeliranje poslovnih procesov videli kot IT iniciativo, ki bo zahtevala udeležbo poslovnih oddelkov kot podporo čedalje večji kompleksnosti procesov in IT podpore teh procesov. Dejansko nekateri oddelki niso hoteli sodelovati. Po drugi strani pa je BPM zamišljen kot iniciativa s poslovnega nivoja, ki zahteva udeležbo IT nivoja za transformacijo poslovnih modelov v procese primerne za izvajanje. 2. Poskusili smo CASE orodja, vendar nam niso bila všeč. Pomankljivosti orodij CASE so dobro znane in BPM jih odpravlja. Bila so vmesni korak, ki je avtomatiziral povezovanje v obstoječe programske komponente (objekte, komponente, vmesnike ipd.). BPMS je nov tip programske opreme, temelječ na procesnih modelih in ne na objektih. Zagotavlja osnovne elemente, ki so potrebni za izgradnjo kompleksne poslovne logike in računalništvo brez konvencionalnega razvoje programske opreme. 3. Nimamo časa za to. Modeliranje v IT svetu je bilo pogosto sprejeto kot neproduktiven korak v celotnem razvojnem ciklu programske opreme. Poleg tega so bili tudi časovni roki za izdelavo programske opreme čedalje bolj kratki. BPMS se pa lahko razume kot najhitrejša metodologija razvoja programske opreme narejena do sedaj. Procesni model je sistem in sistem je poslovanje. BPM lahko modelira poleg računalniško baziranih procesov tudi ročne procese in abstraktne procese. 4. Poslovni oddelki nam povedo kaj naj programiramo, mi jih ne sprašujemo. Modeliranje je bilo prevečkrat predstavljeno, da naj bi zgladilo nesoglasja in razkorak med poslovnimi oddelki in informatiko. Ta pristop je ignoriral dejstvo, da poslovni oddelki ponavadi vidijo v IT-ju samo stroškovna mesta. Tako je ponavadi kakršnakoli IT iniciativa našla gluha ušesa poslovnežev. BPM je podoben pristop, ki naj bi zgradil most med poslovnimi oddelki in IT-jem, vendar je baziran na strategiji sožitja. BPM ima skupen jezik za opis procesov in tako lahko na enostaven način pri zasnovi procesov sodeluje tudi IT s svojimi dolgoletnimi izkušnjami. 5. Sinhronizacija med poslovnimi in IT modeli nam ne uspeva. Modeliranje je v glavnem podpiralo razvoj modelov, ki so ponavadi bili specifikacije zahtev za razvoj programske opreme. Specifikacija zahtev je začetna faza razvoja, ki ponavadi sestoji iz analize, snovanja, programiranja, testiranja in implementacije. Ta proces razvoja programske opreme sam po sebi tvori razkorak med poslovnim in IT modelom. Posledica tega je, da je zaradi kompleksnosti skoraj nemogoče obdržati povezave med zahtevami in tehničnimi gradniki v sinhronem stanju. BPM je baziran na arhitekturi, ki zagotavlja en model za vse sodelujoče (vsaka vloga ima svoj pogled na model) in je ohranjen skozi celotni življenjski cikel procesa. 6. Poslovanje se spreminja prehitro, da bi se ga uspelo in splačalo modelirati. Modeliranje ni moglo zajemati poslovnih sprememb v realnem času zaradi dveh problemov. Prvi je bil nesposobnost sinhronizacije med poslovnim in IT modelom. Drugi problem pa je predstavljal poslovni pristop k modeliranju, ki je moral zajeti celoten proces in s tem postal prevelik za uporabo in razumevanje. BPM ima univerzalen model poslovnega procesa za vse udeležence in je kot tak lažje razumljiv in hitreje spremenljiv. Poleg tega BPM ne zahteva modeliranje popolnega procesa, temveč se lahko osredotoči na dele procesa, ki se dajo najprej izboljšati, in v smislu učinkovitosti in prihrankov prinesejo največ. 20

33 7. Ali ni dovolj modeliranje aplikacij v fazi razvoja? Ker je bilo modeliranje predstavljeno kot IT iniciativa, je bilo v konfliktu z ostalimi iniciativami, ki so bolj ustrezale IT zahtevam kot na primer poenoten jezik modeliranja (angl. Unified Modeling Language, UML). Nasprotno je BPM viden kot iniciativa s strani poslovnih nivojev, ki dopolnjuje različne metodologije, ki so se izkazale za uspešne (kot je na primer UML, ekstremno programiranje, SOA ipd.). 8. Ali ni dovolj izdelava prototipa? Ker je bilo modeliranje prodano IT oddelku namesto poslovnih oddelkom, je bil glavni koncept poslovnih procesov zgrešen in uporabljen za prikaz procesov za IT (na primer za razvoj aplikacije). To je vodilo do zaključka, da je modeliranje samo drugo ime za izdelavo prototipa aplikacije. Če to pogledamo v luči BPM, vidimo, da so razni detajlni diagrami prisotni v tudi BPM metodologiji. 9. Z modeliranjem je več težav kot pa je vredno. Zaradi vseh zgoraj naštetih razlogov je veliko organizacij prišlo do zaključka, da je z modeliranjem poslovnih procesov resnično več težav, kot pa je vredno. Vendar se zadnje čase ta pogled spreminja, prav tako pa tudi proizvajalci programske opreme za modeliranje in management poslovnih procesov ne ciljajo več toliko na tehnične (IT) ljudi, temveč na poslovne. Tveganja, s katerimi se organizacije srečujejo pri projektih uvajanja BPM rešitev so odvisna od naslednjih ključnih dejavnikov uspeha (Kovačič, 2004 in Bosilj-Vukšić, Kovačič, 2004): Motivacije - vodstvo organizacije mora zaupati in verjeti, da le celovita prenova poslovanja ohrani položaj organizacije v okolju, prinaša prednost pred konkurenco ali ji odpira nove poslovne priložnosti (nove tržne vrzeli ipd.). Vodenja projekta - odgovornost za vodenje in uspeh projekta mora prevzeti vodja, ki je član najožjega vodstva in s svojim ugledom v organizaciji zagotavlja drugim udeležencem projekta ustrezno zaupanje v uspeh. Zaupanja pri srednjem vodilnem kadru - navadno si vodstvo projekta razmeroma hitro pridobi zaupanje pri izvajalcih, medtem ko srednji vodilni kader organizacije zaradi bojazni, da bo ob spremembah poslovanja izgubil pridobljeni položaj, že tradicionalno ni naklonjen korenitim premikom na tem področju. Vizije - na novo opredeljeni strateški cilji morajo biti predstavljeni v obliki, ki je razumljiva in sprejemljiva za vse udeležence projekta. Usmeritve - projektne aktivnosti in viri, ki so potrebni za izvedbo sprememb, morajo biti usmerjeni zlasti v spremembe k najpomembnejšim ciljem organizacije. Opredelitve vlog in odgovornosti - vloge udeležencev projekta morajo biti opredeljene dosledno in podrobno pred izvedbo prenove poslovanja in po njej. Merljivih rezultatov - rezultati prenove morajo biti konkretni, kot na primer na novo opredeljeni strateški cilji organizacije, na novo dorečeni poteki poslovnih postopkov, model poslovnih procesov in podatkov, organiziranosti ipd. Tehnološke podpore - pri tem gre za uporabo metod in orodij, potrebnih za izvedbo prenove ter za izgradnjo informacijskega sistema, namenjenega informatizaciji prenovljenega poslovanja. Slednje pomeni skupino tveganih in največkrat neuspešno opravljenih aktivnosti. 21

34 Strokovnega usmerjanja - svetovalno delo strokovnjakov s tega področja ne sme biti le nadzorno, temveč dejavno, pomeniti mora neposredno udeležbo na projektu. Prevzemanja tveganja - vodstvo projekta se mora zavedati visoke stopnje tveganosti projekta in biti pripravljeno nase prevzeti tudi vse morebitne posledice Zgodovinski vidik managementa poslovnih procesov Prvo obdobje Ob koncu 18. in začetku 19. stoletja se je predvsem v Evropi in Ameriki začela in razširila industrijska revolucija, ki je pripeljala do podjetja kot temeljne oblike gospodarskega delovanja. Sprva je bil poudarek na delitvi dela in rasti produktivnosti, pozneje pa tudi na usklajevanju pri izvajanju dela. Ob koncu 19. stoletja lastniki in managerji obvladujejo delovanje podjetij predvsem na podlagi izkušenj. Delavci sami urejajo svoje delo, določajo postopke ter intenzivnost dela. Med njimi in managerji obstajajo nasprotovanja in namesto sodelovanja vsaka stran poskuša pridobiti na račun druge. Delavci delajo počasi, saj jim hitrejše delo ne bi prineslo višjih mezd. Managerji pa poskušajo s priganjanjem povečati hitrost dela. Na začetku 20. stoletja je Friedrich Winslow Taylor postavil temelje znanstvenega managementa. Taylor je razmišljal predvsem v dveh smereh: prvič o iskanju tehničnih možnosti, povezanih z delitvijo dela in za povečanje učinkovitosti dela, in drugič o ureditvi odnosov med delavci in managerji, povezanih tudi z nagrajevanjem delavcev (Rozman, 1993). Svoje ugotovitve je Taylor strnil v štiri načela uspešnega managementa, po katerih naj bi se podjetja ravnala 8 : 1. Manager mora razviti resnično znanost za vsak element dela. Nenehno naj izpopolnjuje orodja, standardizira postopke in delovne razmere. 2. Manager mora izbrati, poučiti in razvijati delavce, da bodo zahtevano delo ustrezno opravili. Delavci ne smejo delati po svoje. 3. Managerji morajo odkrito in zaupno sodelovati z delavci in zagotavljati take razmere, da bo delo teklo v skladu z določenimi ugotovitvami in pravili. 4. Med managerji in delavci velja delitev dela in odgovornosti. Management opravlja svoj del dela, ki se nanaša na planiranje, organiziranje, vodenje in nadzor dela. Delavci izvajajo določene naloge v skladu z navodili managerjev. Taylorju je sledilo še veliko znanstvenikov, ki so proučevali management (na primer Gilbreth, Gantt ipd.). To vrsto proučevanja so poimenovali Taylorizem. Zanj so značilne tri glavne komponente: Proizvodni procesi so bili sistematično analizirani do posameznih gibov. Vsako opravilo je bilo, kolikor se je dalo, enostavno. Povečala se je specializiranost delavcev in s tem njihova učinkovitost. Enostavnost opravil je dovoljevala, da jih opravlja manj izkušena, cenejša delovna sila. Managerji so dobili popolno kontrolo nad delovnimi mesti. Postali so odgovorni za koordinacijo proizvodnje. 8 Taylor je objavil svoje delo z naslovom Priciples of Scientific Management leta

35 Stroškovna analiza bazirana na študiji časa in gibov, ki so potrebni za neko delovno nalogo. Taylorizem je predstavljal prvo obdobje managementa poslovnih procesov. Procesi so bili implicitni ter niso bili avtomatizirani. Drugo obdobje Drugo obdobje managementa poslovnih procesov se je pričelo s Porterjevo vrednostno verigo v zgodnjih 80-tih letih prejšnjega stoletja, nadaljevalo preko Rummler-Branch metodologije, prenove poslovnih procesov, ERP in WfM sistemov ter raznih iniciativ za management kakovosti. Končalo se je nekako okoli leta 2000 in s pojavom napake drugega tisočletja (angl. Y2K Bug). Na sliki 9 je zajetih nekaj glavnih metodologij, ki so se pojavljale v drugem obdobju managementa poslovnih procesov. Razvrščene so glede na področje, ki ga pokrivajo ter glede na čas kdaj približno so se pojavile in kdaj približno so se začele opuščati (Harmon, 2003, str ). Slika 9: Glavne tehnologije ter njihov vpliv na spreminjanje in prenavljanje poslovnih procesov. Vir: Prirejeno po Harmon, 2003, str. 36. Porterjeva vrednostna veriga Michael Porter je bil s svojima knjigama Competitive Strategy: Techniques for Analyzing Industries and Competitors (Porter, 1980) in Competitive Advantage: Creating and Sustaining Superior Performance (Porter, 1985) eden izmed prvih, ki je poudarjal pomembnost poslovnih procesov v organizaciji. Organizacijo je orisal kot verigo aktivnosti, ki ustvarjajo dodano vrednost oz. dobiček, in jo poimenoval 23

36 vrednostna veriga (angl. Value Chain). Splošne, primarne aktivnosti, iz katerih je sestavljena vrednostna veriga, so naslednje: logistika, proizvajanje, marketing, prodaja, dostava in po-prodajne aktivnosti. Vsaka od teh aktivnosti je vitalnega pomena za razvoj konkurenčne prednosti (slika 10): vhodna logistika - vključuje sprejem, skladiščenje in kontrolo vhodnih materialov, proizvajanje - aktivnost, ki preobrazi vhodne parametre v končni izdelek. Je aktivnost v kateri se ustvarja dodana vrednost, izhodna logistika - aktivnosti potrebne za dostavo končanega izdelka do kupcev. Vključuje skladiščenje, sprejemanje naročil ipd., marketing in prodaja - skrbijo, da bo izdelek kupljen. Vključujejo promocijo, cenovno politiko ipd., dodatne storitve - po-prodajne aktivnosti, ki skrbijo za zvišanje vrednosti izdelka kot so na primer: podpora uporabnikom, servisiranje izdelka ipd.. Slika 10: Porterjeva vrednostna veriga. Vir: Porter, 1985, str. 37 (prirejeno po Harmon, 2004, str. 2 in Harmon, 2003, str. 21). Poleg osnovnih je Porter definiral še generične, podporne aktivnosti, ki pomagajo osnovnim pri izvajanju. S temi aktivnostmi, ki včasih zgledajo kot odvečne, je nekaterim organizacijam uspelo, na primer z uporabo informacijskih sistemov, razviti konkurenčno prednost. Te podporne aktivnosti so naslednje: nabava - nakupovanje materiala in ostalih vhodnih parametrov, ki se uporabljajo pri ustvarjanju vrednosti, tehnološki razvoj - vključuje raziskave, študije, avtomatizacijo, informacijsko infrastrukturo in ostale aktivnosti, ki sodelujejo pri ustvarjanju vrednosti, management človeških virov postaja čedalje zahtevnejša aktivnost, saj je potrebno delavce znati motivirati, jih pravilno nagraditi, ter usposabljati za uporabo na primer novih tehnologij, infrastruktura organizacije - vključuje računovodstvo in denarno gospodarstvo ter management organizacije. Zajete so na primer pravna služba, management kakovosti ipd.. 24

37 Rummler-Branch metodologija Geary Rummler in Alan Branch sta objavila knjigo Improving Performance: How to Manage the White Space on the Organization Chart (Rummler, Branch, 1990), kjer za razliko od mnogih drugih teoretikov poslovnih procesov ne poudarjata informacijske infrastrukture, temveč se osredotočita na analizo procesov, planiranje delovnih nalog in management implementiranih procesov. Navajata, da pri procesih nastane veliko težav in napak, kadar proces prehaja iz oddelka v oddelek. Edina pot, ki naj bi preprečila te težave in napake je management takšnega procesa kot celote. To je sistematičen, izčrpen pristop k problematiki spreminjanja poslovnih procesov, narejen za poslovne ljudi. Razvila sta metodologijo, ki v enem diagramu (slika 11) prikaže kako so različni nivoji (organizacijski, procesni ter nivo aktivnosti) povezani s tremi različnimi pogledi (cilji in merili, snovanjem in izvedbo ter managementom). Diagram določa devet različnih področij, ki jih mora upoštevati vsakdo, ki želi spreminjati proces. Slika 11: Rummler-Branch diagram nivojev in pogledov organizacije. Vir: Harmon, 2003, str. 31. Prenova poslovnih procesov Prenova poslovnih procesov (angl. Business Process Reengineering, BPR) se je pričela leta 1990 z dvema publikacijama. Prvo, Reengineering Work: Don't Automate, Obliterate, je objavil Michael Hammer leta 1990 v reviji Harvard Business Review (Hammer in Champy, 1993). Drugo, The New Industrial Engineering: Information Technology and Business Process Redesign, sta objavila Thomas Davenport in James Short leta 1990 (Davenport, Short, 1990). Olja na ogenj prenove poslovnih procesov sta leta 1993 dolili še dve knjigi. Thomas Davenport je napisal knjigo Process Innovation: Reengineering Work Through Information Technology (Davenport, 1993). Michael Hammer in James Champy sta napisala knjigo Reengineering the Corporation: A Manifesto for Business Revolution (Hammer, Champy, 1993). Trije BPR guruji tistega časa (Hammer, Davenport in Champy) so bili mnenja, da morajo organizacije kadar razmišljajo o prenovi poslovnih procesov, razmišljati v dveh smereh: V smeri prenove celovitih poslovnih procesov, ki se raztezajo od naročila do dostave izdelka. O uporabi informacijskih tehnologij, ki bodo pomagale povezati te celovite poslovne procese. Prenova celovitih poslovnih procesov je prenova velikih, obsežnih ter kompleksnih procesov, kot je na primer Portejeva vrednostna veriga. Tipično za veliko organizacijo 5 10 takšnih procesov. Če je organizacija sledila temu nasvetu, je bila dokaj prepričana, da je zajela vse, kar spada k procesu. Iz tega 25

38 sledi večja verjetnost pravilne identifikacije pomanjkljivosti in s tem tudi večjega izboljšanja procesa. Slaba stran tega pristopa je, da takšen velik proces zajema desetine in stotine pod-procesov, udeležencev procesa ter aplikacij, kar močno poveča kompleksnost procesa ter vložek truda za prenovo. Davenport je trdil, da je informacijska tehnologija v 80-tih letih prejšnjega stoletja doživela razcvet, ter da je sedaj sposobna učinkovito podpirati poslovne procese. Hammer se je izražal bolj radikalno. Trdil je, da so bili poslovni procesi znotraj oddelkov samo avtomatizirani, ne pa tudi prenovljeni ter da so bili poslovni procesi znotraj oddelka izboljšani na račun večje neučinkovitosti celotnega procesa. Trdil je, da je potreben popolnoma nov pogled na poslovne procese ter da je v večini primerov potrebno stare poslovne procese zavreči in jih nadomestiti s popolnoma novimi. Novi poslovni procesi naj bi bili na novo narejeni s pomočjo informacijske tehnologe. Hammer je obljubljal ogromne prihranke in izboljšave organizacijam, ki bodo sposobne prenesti in preživeti proces prenove poslovnih procesov. Več o prenovi poslovnih procesov v poglavju Prenova prenove poslovnih procesov. Izboljševanje poslovnih procesov Nekateri BPR projekti so v sredini 1990-tih let bili uspešni ter prinesli organizacijam velike izboljšave, prihranke in dobičke. Vendar je bilo veliko več kot uspešnih neuspešnih BPR projektov, ki so proti koncu stoletja razblinili prepričanje o koreniti prenovi poslovnih procesov. Termin BPR in s tem tudi izraz downsizing, ki pomeni delati manj z manj, sta s tem postala nepriljubljena. Kot alternativno poimenovanje je večina podjetij začela uporabljati izraza izboljševanje poslovnih procesov (angl. Business Process Improvement, BPI) in redesign poslovnih procesov (angl. Business Process Redesign, BPR) 9. Sistem za management delovnega toka (WfMS) in celovite programske rešitve (ERP) Poslovni proces in aktivnosti se ponavadi ponavljajo in sledijo točno določenemu zaporedju. Podatki prehajajo iz aktivnosti v aktivnost in sestavljajo tako imenovani podatkovni tok. Poleg tega je potreben še kontrolni tok, ki na podlagi pravil krmili prehode podatkov iz ene aktivnosti v drugo. Na podlagi določenih pravil v kontrolnem toku, se lahko na primer neka aktivnost preskoči zaradi rezultata prejšnje aktivnosti. Sredi 90-tih let prejšnjega stoletja so začele nekatere organizacije uporabljati WfMS, programsko opremo za management delovnega toka. Z uporabo WfMS se izvajanje procesa kar najbolj avtomatizira. A pojavi se problem povezovanja aplikacij med oddelki, ki glede na tradicijo niso komunicirali drug z drugim. Hkrati s tem so ERP proizvajalci, na primer SAP, PeopleSoft, Baan, Oracle ipd., začeli organizirati različne programske module tako, da jih je bilo možno sestavljati v poslovne procese. Organizacije so lahko izbirale katere module bodo kupile in na kakšen način jih bo WfMS znotraj ERP sistemov povezal. Ob tem so bile omejene na module, ki jih je določen proizvajalec ponujal. Če je imela organizacija neko svojo programsko rešitev, jo je bilo s stališča tehnologije in koncepta zelo težko in drago povezati z ERP sistemom. Eden izmed velikih zagovornikov ERP sistemov je bil tudi Davenport (Davenport, 1993, str. 193 in Davenport, Harris, Cantrell, 2004, str. 16). 9 Slovenski prevod Business Process Reengineering in Business Process Redesign je enak in sicer se glasi prenova poslovnih procesov. Zato sem izjemoma, samo v tem poglavju, uporabil izraz redesign poslovnih procesov, da bi ga razlikovali od reinžineringa poslovnih procesov. 26

39 Inženiring namenske programske opreme Dva popularna pristopa k avtomatizaciji poslovnih procesov s stališča informacijskih tehnologij smo že omenili (WfMS in ERP). Seveda je moč z razvojnimi orodji razviti kakršnokoli programsko opremo, ki bo zadostila nekemu poslovnemu procesu. Inženiring programske opreme je razvoj programske opreme na sistematičen, učinkovit in konsistenten način. Nekatera podjetja so za razvoj programske opreme naredila orodja, ki generirajo programsko kodo iz programskih modelov. Eno izmed takih orodij je na primer CASE orodje Oracle Designer (Geršak, 1997, str. 30). Bolj, ko je sprememba poslovnega procesa kompleksna in pomembna, večja je verjetnost, da bo organizacija sama morala razviti svojo programsko opremo. Kadarkoli se to zgodi je zelo pomembno, da se uporabljajo orodja in jeziki, ki enoznačno določajo proces in s tem dopuščajo tako tehničnim kot tudi poslovnim ljudem različne poglede na isti proces. Management kakovosti: TQM, ISO9000 in Šest sigma Management kakovosti se ukvarja predvsem s kontrolo kakovosti izhodov iz procesa. Približno od leta 1980 naprej so se pojavljale iniciative za povečanje kakovosti kot so statistična kontrola procesa (angl. Statistical Process Control, SPC), JIT proizvodnja (angl. Just-in-Time Manufacturing, JIT) in celovit management kakovosti (angl. Total Quality Management, TQM). Vsaka od teh iniciativ je prispevala k učinkovitosti in višji kakovosti procesov v organizacijah. Mednarodni standard kakovosti ISO 9000 se je v praksi zelo uveljavil. Predpisuje aktivnosti, ki jih organizacija mora izvesti ter izvajati, da bi postala in ostala ISO 9000 certificirana. Nekaj let nazaj je stopil v veljavo nov standard, ISO 9000:2000, ki nekako usmerja organizacije, da razmišljajo v smeri poslovnih procesov. V obeh primerih je poudarek predvsem na dokumentiranju in ne toliko na sami izvedbi zvišanja kakovosti, kar organizacije v bistvu resnično potrebujejo. V sredini 90-tih let prejšnjega stoletja se je pojavil podoben pristop imenovan šest sigma (angl. Six Sigma). Razvit je bil v podjetju Motorola. Metodologija šest sigma se je postopoma razvijala in dopolnjevala, tako da bi lahko danes govorili vsaj o treh različnih odtenkih te metodologije: management, ponovno snovanje in izboljševanje. Vendar, kakorkoli že gledamo, dejstvo je, da so šest sigma projekti osredotočeni na izboljševanje procesov, ne pa toliko na prenovo procesov na nivoju celotne organizacije. Glavni doprinos te metodologije je razumevanje potrebnega načina merjenja uspešnosti poslovnega procesa; namreč glede na zadovoljstvo uporabnikov izdelka ali storitve, ki je produkt tega procesa. Več o tem v poglavju Management kakovosti na strani 32. Internet in internetne tehnologije Navdušenje nad BPR se je polagoma umirjalo, internet pa je, poleg WfMS in ERP tehnologij, ponujal veliko tega, kar so BPR guruji obljubljali (Hammer, Davenport ipd.). Informacijska tehnologija še ni bila zrela oz. je bila še predraga (na primer EDI). Takrat, nekako sredi 90-tih let prejšnjega stoletja, se je z uporabo grafičnih brskalnikov razmahnila uporaba svetovnega spleta, elektronske pošte, elektronskih oglasnih desk in drugih internetnih storitev, ki so omogočale enostavno povezovanje organizacij, dobaviteljev in kupcev. Praktično čez noč so podjetja naredila svoje spletne strani, na katerih so lahko kupci kupovali ali poizvedovali o izdelkih in storitvah. Glede na konvencionalne poti promocije in prodaje je internet 27

40 organizacijam pomenil velik prihranek denarja. Hkrati se je pojavil tudi strah pred programsko napako drugega tisočletja. Mnogo podjetij se je ukvarjalo s to napako in ni imelo časa, da bi se ukvarjalo z izboljševanjem svojih procesov, ki so jih ponujale internetne tehnologije. V novem tisočletju organizacije pospešeno začenjajo uporabljati to tehnologijo. Tretje obdobje - Management poslovnih procesov Po letu 2000 se je v poslovnem svetu in svetu informatike pojavil nov termin management poslovnih procesov. BPM ni samo naslednik BPR, temveč združuje poslovni svet s svetom informacijskih tehnologij. Prvič v zgodovini lahko oba svetova sodelujeta na istem poslovnem procesu. S konstantnim in hitrim razvojem informacijskih tehnologij so le-te postale zmožne upravljati človeško delo in poslovne sisteme istočasno. To istočasni upravljanje informacij in človeškega dela so ljudje poslovnih in informacijskih sfer poimenovali BPM: gre za sposobnost modeliranja, izvrševanja in optimalizacije procesa v realnem času. To je obdobje, o katerem govori to magistrsko delo Prenova prenove poslovnih procesov Prenovo poslovnih procesov sta Hammer in Champy (Hammer, Champy, 1993) opredelila kot temeljni vnovični premislek o poslovnih procesih in o njihovem korenitem preoblikovanju z namenom, da bi tako dosegli velike izboljšave ključnih kazalcev učinkovitosti kot so stroški, hitrost ter kakovost izdelkov in storitev. Avtorja sta nadalje opredelila prenovo poslovnih procesov s štirimi ključnimi pojmi (Peruško, 2003): 1. Temeljni (angl. Fundamental). Pri prenovi poslovnega procesa si moramo zastavljati vprašanja o svojem delu in načinu dela: Zakaj delamo to, kar delamo?, Zakaj tako delamo?. Zastavljena vprašanja prisilijo ljudi, da razmišljajo o nenapisanih pravilih in pravilih, ki se skrivajo v načinu vodenja poslovanja. Pogosto se izkaže, da so pravila zastarela, napačna in neustrezna. Prenova se začne brez predpostavk. Moramo ugotoviti, kaj naj podjetje naredi in kako bo to naredilo. Pozabiti je treba na obstoječe stanje in misliti na to, kako bi moralo biti. 2. Korenit (angl. Radical). Proces želimo raziskati do temeljev. Ne želimo le površno spreminjati tistega, kar že imamo, ampak želimo oblikovati povsem nove procese in načine opravljanja dela. 3. Dramatičen (angl. Dramatic). Ne gre le za obrobne in postopne izboljšave, ampak za preskok. Vendar pa mora podjetje takrat, kadar želi malenkostno izboljšati uspešnost poslovanja (na primer le za deset odstotkov), iskati rešitve drugje in z drugimi koncepti, ker sklepamo, da korenite prenove ne potrebuje. 4. Proces (angl. Process). Proces je pri konceptu prenove poslovnih procesov najpomembnejša beseda, ki pa večini managerjev povzroča težave. Veliko jih namreč ni procesno usmerjenih, navadno se osredotočijo na posamezne naloge in pri tem izgubljajo pregled nad celotnim procesom in širšimi cilji. Pri prenovi poslovnih procesov je moč prepoznati štiri ključne prvine, ki tvorijo jedro prenove poslovnega procesa. Te so naslednje: Prenova prinaša radikalne ali vsaj zelo pomembne spremembe. 28

41 Enota prenove je celovit poslovni proces, ki se na primer razteza od naročila do dostave izdelka, kot nasprotje poslovnim procesom po oddelkih. Prenova skuša doseči pomembne cilje ali dramatične napredke v uspešnosti poslovanja organizacije. Informacijska tehnologija je ključni pospeševalec prenove Cilji in problemi prenove poslovnih procesov Najpomembnejši cilji prenove poslovnih procesov so bili naslednji: povečanje učinkovitosti proizvodnje, zmanjšanje stroškov ter povečanje zaslužka, zvišanje kakovosti izdelkov in storitev, povečanje zadovoljstva kupcev, povečanje konkurenčnosti ter boljši razvoj prodajnih storitev. Prenovljen proces naj bo preprostejši, prožnejši, produktivnejši, prilagodljivejši ter časovno hitreje izvedljiv. Seveda ob tem upoštevamo povečano zadovoljstvo kupcev zaradi kakovostnejšega izdelka ali storitve, ki je dobavljena v dogovorjenem časovnem roku. Hkrati to pomeni za organizacijo večjo dobičkonosnost in konkurenčnost. Vendar so ljudje, ki so se ukvarjali s prenovo poslovnih procesov, ugotavljali, da projekti prenove trajajo predolgo, da so kompleksni, zelo intenzivni in potrebujejo zelo veliko človeških in materialnih virov. Eden izmed ključnih problemov BPR je prevelika radikalnost spremembe poslovnega procesa. Poslovni proces je bilo potrebno izrezati iz telesa organizacije in nadomestiti z novim. Vendar morajo obstoječi, delujoči zaledni (legacy) sistemi delovati, medtem ko kirurgi prenove organe procesa nadomeščajo z novimi in drugačnimi. Nov proces bo od starega verjetno drastično drugačen, vendar bo še vedno uporabljal vsaj del elementov starega procesa (na primer neko aplikacijo). Pojavi se problem preklopa na nov proces, s tem povezano izobraževanje zaposlenih ipd. Hammer in Champy sta povezovala BPR z duhovnim popotovanjem, z jadranjem v neznano. Trdila sta, da bo prenova uspešna samo v primeru, če jo bodo vodili ljudje, ki se ne ustrašijo neznanega in negotovosti. Z BPR se je ponavadi prenavljal istočasno samo en proces, ki se je raztezal čez več oddelkov in funkcij organizacije. Zelo težko je bilo doseči sinergijo ljudi na takem projektu, še posebej, ker so ljudje imeli občutek, da ne delajo dovolj dobro, poleg tega pa so se bali tudi downsizing-a, ki se je pogosto skrival za BPR projektom. S takšnim pristopom vodstva pri uvedbi BPR projekta v organizacijo je le-ta v zelo kratkem času izgubila lojalnost zaposlenih in človeški kapital. Naj navedem samo nekaj izjav Michaela Hammerja (Smith, Fingar, 2003, str. 103) iz leta 1993, ki jih je navedel na različnih konferencah in revijah: Na tem potovanju bomo nosili ranjence in streljali na dezerterje. Pobuda za prenovo mora priti s strani nekoga, ki ima dovolj visoko funkcijo v organizaciji, da lahko lomi kosti. 29

42 Če je vodstvo resnično odločeno za prenovo, vas bodo ustrelili, če jo boste poskusili preprečiti. Verjetno največji problem BPR je bil BPR sam. BPR je teorija drastičnih sprememb, ki je bližje kot teoriji evolucije, teoriji velikega poka. Hammer in Champy sta trdila, da je za uspešno izvedbo prenove potrebno več kot leto ter sto odstotna udeleženost članov tima. To pomeni, da člani BPR tima opustijo trenutne zadolžitve in se popolnoma vključijo v aktivnosti prenove. Da bi organizacija dosegla nov, bleščeč, prenovljen proces, sta bila oba odločena vse, kar je bilo povezano s procesom, žrtvovati: obstoječo delovno organizacijo, organizacijsko strukturo in sisteme managementa. Davenport ni bil tako ekstremen v svoji knjigi Process Innovation (Davenport, 1993), vendar se je strinjal s Hammerjem in Champyem, da je za BPR potreben pristop od zgoraj navzdol, torej z nivoja managementa, ki daje podporo in usmeritve projektu. Pravilno je ugotovil, da je velika radikalnost sprememb za organizacijo najtežja. Iz njegove knjige se da razbrati, da bi bilo potrebno nekako kombinirati radikalnost sprememb ter postopno spreminjanje procesa. Daveport ugotavlja, da je prenova bolj umetnost kot znanost, ter da beseda reinžinerstvo zavaja, saj da slutiti, da ima BPR znanstvene temelje. Vendar BPR nima nikakršnih znanstvenih osnov, izdelane metodologije za razvoj novih poslovnih procesov ter nikakršne priprave za njihovo simulacijo pred produkcijo. Zaradi teh razlogov so ljudje morali začeti BPR s praznim listom papirja. Ker ni bilo ustrezne BPR metodologije, so ljudje izdelovali poslovne procese, ki so bili neenaki po kakovosti in včasih neuporabni za tisto, čemur so bili namenjeni. Iz teh razlogov so nekatere organizacije in svetovalne hiše razvijale svoje BPR metodologije, ki so dajale več poudarka merljivosti, povratnim informacijam ter kontroli procesov. Ko so bili po BPR metodologiji prenovljeni poslovni procesi dani v izvajanje, navkljub tem dodatkom k originalni BPR viziji, le-ti niso bili nič bolj sposobni upravljanja in prilagajanja kot njihovi predhodniki. Novi procesi so bili prav tako globoko zakoreninjeni in odvisni od delovnih navad uslužbencev in mej informacijskega sistema. Odgovor na nezmožnost prilagajanja aplikacij je bila WF tehnologija, ki je poslovno logiko izluščila iz aplikacij in kot tako jo je bilo moč spreminjati na poslovnem nivoju (Smith, Fingar, 2003, str. 106). Čeprav je BPR po letu 1995 izgubljal na veljavi, predvsem zaradi drastičnosti sprememb, ki jih je povzročil v organizaciji, zaradi downsizing-a, ki se je pogosto skrival za besedo BPR ter zaradi razmaha interneta, je vseeno pokazal, da so spremembe poslovnih procesov in poslovanja potrebne. Največji spremembi, ki ju je bilo moč opaziti, sta vsekakor potreba po zmanjšanju ročnega dela in povezava različnih oddelkov znotraj organizacije v smislu medsebojnega sodelovanja. Če na kratko povzamemo probleme, s katerimi se je srečeval BPR, so le-ti naslednji: 1. Transformacija Big Bang ima veliko verjetnost neuspeha. 2. Spremembe obnašanja procesa so težje v praksi kot na papirju. 3. Sistemi (v smislu sistemov IT in aplikacij) so v praksi težje zamenljivi in spremenljivi kot na papirju Primerjava prenove in managementa poslovnih procesov Guruji BPR so priznali nekaj napak v BPR teoriji v publikacijah, ki so sledile v letih po prelomu tisočletja. Eden izmed primerov je članek Michaela Hammerja How to Sell Change (Hammer, 2001a). Vse prepogosto je bila v njihovih očeh za neuspeh BPR kriva organizacija sama, ker ni dosledno upoštevala 30

43 načel BPR. V knjigi Reengineering The Corporation sta avtorja v poglavju 14 (Hammer, Champy, 1993) navedla skoraj dvajset razlogov za neuspeh. Nekaj teh razlogov lahko danes pogledamo v luči BPM in jih komentiramo (tabela 3). Tabela 3: Razlogi za neuspeh BPR in BPM pogled na njih. Vzrok za BPR neuspeh popravljanje procesa namesto njegovega ponovnega definiranja osredotočenost na proces ni bila dovolj velika. snovanje procesa ni bil pomembno zadovoljstvo z manjšimi uspehi glede na zastavljene cilje vnaprej postavljene omejitve pri BPR management organizacije ni dovolil, da bi se BPR sploh pričel vodja tima, ki ne razume BPR istočasno prenavljati več kot en celovit proces nezmožnost razlikovanja enkratnosti BPR od ostalih programov izboljševanja procesov BPM pogled jasno definirana pot in krmiljena življenjska doba procesa bi morali peljati od začetnih majhnih k radikalnim spremembam procesi predstavljajo samo en pogled na poslovanje. Vodje morajo imeti orodja za upravljanje procesov, ki jih razumejo z orodji za BPM naj bi BPM postal rutina s postopnim izboljševanjem procesa se učinkovitost le-tega znatno povečuje. Radikalne spremembe so redko zaželjene, še posebej, ko gre organizaciji slabo v ekonomskem smislu BPM lahko upošteva vse omejitve, ki jih management želi uveljaviti, ker so oni tisti, ki vodijo organizacijo BPM je naravni del poslovanja ne bi smel biti zastrašujoč, njegovi rezultati bi morali biti merljivi in predvidljivi BPM orodja in metode naj bi bili intuitivni za uporabo. BPMS je okolje v katerem naj bi se lahko simultano upravljalo na stotine procesov BPM ni nova teorija o managementu, ampak pomaga implementirati obstoječo strategijo organizacije Vir: Smith, Fingar, 2003, tabela 5.1, str Iz tabele 3 lahko vidimo, da tam, kjer BPR pravi, da je organizacija naredila napako in doživela neuspeh, BPM vidi to kot poslovno zahtevo in potrebo, ki ji BPM lahko ugodi. Z BPM poslovni ljudje (ne več tehnični ljudje) dobijo orodja s katerimi lahko modelirajo, izboljšujejo in dajo proces v izvajanje. BPM negira in postavlja na glavo mnogo trditev oz dejavnikov, ki veljajo za tradicionalni BPR. Ti dejavniki, ki opredeljujejo in razlikujejo BPR in BPM, so v tabeli 4. Tabela 4: Primerjava BPR in BPM. Dejavniki BPR BPM raven sprememb korenite, procesi celoten poslovni cikel razumevanje stanja kot-je in željenega stanja naj-bo procesa stari procesi, popolnoma novi procesi - nepovezanost nezmožnost izvedbe BPM ali zmožnost izvedbe BPM izhodiščna točka neobremenjeno s preteklostjo (napakami,itd) novi ali obstoječi procesi pogostnost sprememb enkratne ali občasne enkratne, občasne, stalne ali razvojne čas izvajanja dolg v realnem času izvajanje prelomno, hipna in korenita prenova ( Big Bang ) postopno sodelovanje in izvedba od vrha navzdol od vrha navzdol in od spodaj navzgor število procesov en temeljni proces naenkrat vzporedno več in med več procesi področje obravnave široko, medfunkcijsko celovito upravljanje s procesi organizacije usmeritev bodočnost preteklost, sedanjost in bodočnost tveganje visoko nizko poglavitni pospeševalec informacijska tehnologija procesna tehnologija orodja modeliranje procesov različna izvajalci prenove splošni poslovni poznavalci specialisti za prenovo in vsi zaposleni izvedba sprememb proces proces in poslovna praksa Vir: Smith, Fingar, 2003, str. 118 (BPR dejavniki povzeti po Davenport, 1993). 31

44 Način poslovanja organizacij je normalno usmerjen k doseganju in ohranjanju konkurenčne prednosti. Ko so japonska proizvodna podjetja v 80-tih letih prejšnjega stoletja premagala ameriška in druga podjetja v Evropi, so le-ta ugotovila, da se jim je konkurenčna prednost izmuznila iz rok. Šok in bolečina sta bili tako veliki, da so se te organizacije navkljub napovedanim drastičnim spremembam oprijele koncepta BPR. IT infrastruktura v tem času na žalost še ni dozorela do te stopnje, da bi bila sposobna podpreti koncept BPR. Tudi zaradi tega je BPR po letu 1995 dobil prizvok nečesa slabega, rigoroznega, nečesa česar nima smisla uvajati, ker je že vnaprej obsojeno na neuspeh. BPR nam je dal lekcijo, da je potrebno spremembe poslovanja uvajati na drugačne načine. In ravno tukaj se začne tretje obdobje BPM. Na BPM lahko v ožjem kontekstu gledamo tudi kot na prenovo prenove poslovnih procesov Management kakovosti Management kakovosti je metodologija za izboljševanje poslovnih učinkov. Glavne metodologije za management kakovosti so dandanes ISO 9000:2000, celovit management kakovosti (angl. Total Quality Management, TQM) in metodologija šest sigma. Mednarodna standarda kakovosti ISO 9000 in ISO 9000:2000 predpisujeta aktivnosti, ki jih organizacija mora izvesti in izvajati, da bi postala in ostala ISO certificirana. Poudarek je predvsem na dokumentiranju in ne toliko na sami izvedbi zvišanja kakovosti. ISO 9000:2000 je novejši standard in usmerja organizacije v premišljevanje o poslovnih procesih. Standarda sta primerna kot prva, začetna, dokumentacijska stopnja k managementu kakovosti. TQM in šest sigma metodologiji (v širšem smislu) obsegata celotno poslovanje. V nadaljevanju na kratko poglejmo kaj sta obe metodologiji in njuno primerjavo Celovit management kakovosti Celovit management kakovosti je med najbolj priljubljenimi pristopi nenehnega izboljševanja. Gre za celovit organizacijski pristop, za nenehno izboljševanje kakovosti vseh organizacijskih procesov, izdelkov in storitev. Temelji na predpostavki, da je izboljševanje kakovosti ključni dejavnik doseganja učinkovitosti in uspešnosti podjetja. TQM ima naslednje značilnosti: 1. Taktika nič napak : kakršne koli napake v procesu so izključene preden gre izdelek v prodajo. 2. Nenehno izboljševanje: sestanki ljudi, ki sodelujejo v procesu, kjer se pogovarja o problemih, možnostih odprave ter izboljšav procesa ter statistična kontrola kakovosti in procesa. 3. Sodelovanje in razvoj zaposlenih in sodelovanja: organizacijska odgovornost in pripadnost. 4. Kakovost, ki jo narekuje kupec: upoštevajo se povratne informacije strank z raziskavami tržišča glede zadovoljstva uporabe ter za identifikacijo novih izdelkov. Za očeta TQM velja Edwards Deming (Harmon, 2003, str. 180), ki so ga Združene države Amerike po II. svetovni vojni poslale na Japonsko, da bi pomagal japonskim podjetjem izboljšati poslovne procese. V ZDA so podjetja tradicionalno merila kakovost s kontrolo končanih vzorčnih izdelkov. Deming je prepričal japonska podjetja, da je kontrola kakovosti potrebna na vsakem koraku v delovnem procesu. Izhajajoč iz 32

45 tega, so se japonski dobavitelji naučili koordinirati urnike dobave z podjetji, kamor so dobavljali, kar je pripeljalo do JIT proizvodnje in posledično tudi do vitke proizvodnje (angl. Lean Manufacturing). Eno izmed najbolj uveljavljenih orodij TQM je Demingov krog oz. krog načrtovati-narediti-preveriti-delovati (angl. Plan-Do-Check-Act Cycle, PDCA), ki predstavlja sistematično orodje za nenehno izboljševanje. Osnovni elementi PDCA kroga so prikazani na sliki 12. Slika 12: Demingov PDCA krog nenehnega izboljševanja poslovnih procesov. Vir: Peruško, 2003, str Metodologija šest sigma Na začetku 90-tih let prejšnjega stoletja se je pojavila metodologija o managementu kakovosti, imenovana šest sigma. Razvita je bila v podjetju Motorola. Kmalu za njo je tudi General Electric začel s projektom in dosegel dobre rezultate. Danes jo uporablja veliko število organizacij, predvsem v ZDA, vendar se ta metodologija seli tudi v Evropo. Slika 13: Gausova krivulja in standardna deviacija. Vir: Harmon, 2003, str

46 Metodologija šest sigma mnogim organizacijam pomeni merjenje kakovosti izhodov, pa najsi bo izhod proizvod ali storitev. Stopnja napake, ki jo metodologija zagovarja, naj bi bila največ 3,4 izhodov z napako na milijon izdelanih oz. +/- šest standardnih deviacij. 18. črka grške abecede, sigma (σ), je simbol za standardno deviacijo, ki je merilo variance. Slika 13 prikazuje Gausovo krivuljo in pojasnjuje varianco. Šest sigma je pristop organizacije do kupca s spoznanjem, da so napake v izdelkih zelo drage. Manj napak pomeni nižje stroške in večjo lojalnost kupcev. Zato je osnovni cilj metodologije uvedba strategije, ki se da meriti. Strategija se osredotoča na izboljševanju procesov in zmanjševanje variance (števila napak izhodov). Zato sta na voljo dve šest sigma pod-metodologiji: DMAIC in DMADV. Slika 14: DMAIC metodologija izvedbe šest sigma projektov. Vir: Povzeto po Pyzdek, 2003, str. XVI. DMADV, ki po angleško pomeni: define, measure, analyze, design, verify (slov. definirati, meriti, analizirati, snovati, preveriti), je namenjena za razvoj novih procesov oz. izdelkov s šest sigma kakovostno ravnjo. Prav tako se lahko ta metoda uporabi, kadar obstoječ proces potrebuje korenito spremembo, postopne izboljšave pa ne dajo dovolj hitrih rezultatov. DMAIC kratica pomeni po angleško: define, measure, analyze, improve, control (slov. definirati, meriti, analizirati, izboljšati, kontrolirati). DMAIC se uporablja za postopno izboljševanje obstoječih procesov, ki ne 34

47 dosegajo predpisane kakovosti izhodov. Velika večina projektov se izvaja po metodi DMAIC, ki je prikazana na sliki 14, stran 34. To metodologijo izvajajo svetovalci, poimenovani na tri načine: črni pasovi (angl. Six Sigma Black Belts), zeleni pasovi (angl. Six Sigma Green Belts) in mojstri črnih pasov (angl. Six Sigma Master Black Belt). Mojstri črnih pasov so ponavadi vodje uvajanja metodologije v organizacijo. Metodologija šest sigma se je s časoma razvijala in dopolnjevala tako, da bi lahko danes govorili vsaj o treh različnih odtenkih te metodologije: managementa, ponovnega snovanja in izboljševanja. Vendar, ne glede na to gledanje obstaja dejstvo, da so šest sigma projekti v večji meri osredotočeni na izboljševanje posameznih procesov, kot pa na prenovo celovitih procesov na ravni celotne organizacije. Glavni doprinos te metodologije je razumevanje kako merjenja uspešnosti poslovnega procesa; glede na zadovoljstvo uporabnikov izdelka ali storitve, ki je izhod tega procesa Primerjava metodologij celovitega managementa kakovosti in šest sigma Šest sigma je nabor znanih orodij, ki jih lahko najdemo tudi v TQM. Je uporaba teh orodij na izbranih projektih, ki so strateškega pomena za vodstvo organizacije. Šest sigma metodologija prinaša dobre rezultate kadar je sestavni del strateškega plana organizacije z osredotočanjem na zadovoljstvo kupcev. Zato ti projekti ponavadi zaobjemajo poslovne procese, ki se raztezajo tudi čez meje poslovnih enot in celo meje podjetja, kar je ponavadi neobičajno za TQM projekte. V tabeli 5 je primerjava med TQM in šest sigma metodologijama. Tabela 5: Primerjava TQM in metodologije šest sigma. Poslovanje Cilji Vodenje Uporaba Spremembe Organizacija Osredotočanje TQM Pogosto ni del poslovne strategije. Vodstvo organizacije ponavadi ni vključeno in ni prave odgovornosti za projekt. Izboljšati vse. Ponavadi ne cilja na proces. Pogosto brez fokusa. Z močno podporo vodstva je ponavadi uspešna, čeprav nekateri mislijo, da je modna muha. Naučiti se uporabljati čimveč orodij. Čimvečja uporaba teh orodij. Ni toliko skrbi glede stroškov in rezultatov. Znotraj oddelkov. Postopne. Redko izhajajo iz kupčevih želja in kritik. Ni časovne omejitve projekta. Svoj oddelek. Sestavljen iz ekspertov za kakovost. Delovno mesto eksperta je lahko kariera ali pa delovno mesto, ki ni spoštovano, na primer pred upokojitvijo uslužbenca. Proizvodnja, produkti. Skoraj nič na storitve, logistiko ali trženje. Šest sigma Strategija vodstva oddelka oz. organizacije. Vodstvo je močno vključeno. Projekti pazljivo izbrani in managerji so odgovorni. 3,4 napak na milijon izdelkov. Točno opredeljen cilj. Vodstvo definira področje in obseg. Uspešna tam, kjer je iniciativa vodstva organizacije. Vodje imajo aktivno vlogo v vseh fazah. Od projektov se zahteva, da dosežejo cilj. Uporaba samo potrebnih orodij. Pričakujejo se velike izboljšave. Najboljši rezultati, če je osredotočanje na kupca. Osredotočanje na poslovni proces in s tem na sodelovanje med oddelki. Časovna omejitev projekta. Črni pasovi so razporejeni po poslovnih enotah in poročajo vodstvu. Ko končajo s projektom se Črni pasovi vrnejo na svoje običajno delovno mesto. Vsi poslovni procesi. Vir: Adams, Wilson, Reiger,

48 Od identificiranja do managementa poslovnega procesa BPM obsega osem obsežnih področij (opisano tudi v točki C. poglavja Opredelitev managementa poslovnih procesov). Ta področja so naslednja: 1. identificiranje, 2. snovanje, 3. postavitev, 4. izvajanje, 5. interakcija, 6. delovanje in vzdrževanje, 7. optimalizacija in 8. analiza poslovnih procesov. Vseh osem področij tvori življenjski cikel poslovnega procesa od identificiranja, preko izvajanja in analize do povratne zanke, ki jo predstavlja optimalizacija procesa, kar je prikazano na sliki 15. Identificiranje poslovnega procesa Slika 15: Življenjska doba poslovnega procesa. Vir: Smith, Fingar, 2003, str. 90. Z identificiranjem ugotavljamo kako se stvari v organizaciji sploh izvajajo. Identificiranje poenoti razumevanje sistemov in aktivnosti, ki so vključeni v proces. V tej fazi se zajamejo oz. opišejo tokovi dogodkov, informacij in podatkov iz perspektive celotnega sistema (vsi soudeleženi v procesu, soudeleženi 36

49 IT sistemi in aplikacije ter vsi pod-procesi), in sicer za stroj (računalnik) berljivi obliki. Identificiranje pomeni, da se procesi, ki so implicitno vsebovani v delovnih vzorcih ali zapečeni v IT sistemih izluščijo in naredijo v digitalni obliki eksplicitno. Identificiranje je lahko ročno, avtomatsko ali kombinacija obeh. Ker je ročna identifikacija procesa naporna, draga in časovno obsežna, so v nastajanju orodja, ki bodo avtomatizirala ali vsaj olajšala le-to. Identificiranje procesa pomeni, da do podrobnosti vemo kako proces deluje interno in eksterno. Poleg tega vključi vse, ki sodelujejo v procesu, v fazo snovanja. Snovanje poslovnega procesa Pomeni modeliranje, manipuliranje, simuliranje ter ponovno snovanje procesa, ko organizacija ugotovi kaj je in kaj ni mogoče doseči, oziroma meje procesa. Ukvarja se z aktivnostmi, pravili, udeleženci, interakcijami in povezavami. Pomeni izdelavo poslovnega procesa, njegovih gabaritov, omejitev in ciljev, tako da analitiki lahko hitro preuredijo proces kot odziv na konkurenco ali poslovno priložnost. Sestavljanje in razstavljanje, kombiniranje, preurejanje in transformacija so aktivnosti te faze. Organizacija prenavlja sisteme in vmesnike znotraj sebe in tudi eksterno, na primer s svojimi dobavitelji. Shramba podatkov (angl. Repository) procesa podpira ponovno uporabo, adaptacijo, management sprememb, nadzor in vsebuje primere procesov. Za odkrivanje alternativ se uporablja simulacija. Več o simulaciji na strani 40 v poglavju Simulacija poslovnih procesov. Prenašanje modela poslovnega procesa v izvajalno okolje Postavitev pomeni dati nov proces v izvajanje ter na razpolago vsem udeležencem, vključno z ljudmi, aplikacijami in ostalimi procesi in pod-procesi. Z BPM orodji je zelo enostavno prenesti proces v izvajalno okolje z nič ali skoraj nič programiranja. Odvisno od samega poslovnega procesa je večina aktivnosti avtomatizirana. Aplikacije in vmesniki, ki se zavedajo procesov in ne vsebujejo neke dinamične poslovne logike, se lahko namestijo in povežejo že vnaprej. Prav tako se lahko procesi in njihove aktivnosti med sabo povežejo z vmesniki. V času prenašanja modela v izvajalno okolje se lahko razdeli izvajanje dela različnim udeležencem. Prav tako je možno distribuirati izvajanje procesa na različne BPMS. Natančno planiranje resursov, management sprememb in prilagajanje procesov so v tej fazi absolutno potrebni. Izvajanje in interakcija poslovnega procesa Poslovni proces teče. Uporabljajo ga vsi udeleženci (ljudje, druge organizacije, sistemi, ostali procesi ipd.). Kadar so udeleženci ljudje, ki recimo uporabljajo aplikacije oz. vnosne maske, se pojavi ročna interakcija s procesom. Izvajanje takega procesa je naloga BPMS, ki mora upravljati stanja procesov. Ko udeleženci izvajajo različne aktivnosti, mora izvajati distribuirane transakcije, ki se raztezajo med novimi in obstoječimi (zalednimi) aplikacijami. BPMS ščiti poslovnega uporabnika pred zapletenostjo tehnologij na nižjih nivojih in skrbi, da se procesi izvajajo pravilno. Podatki, ki se generirajo med izvajanjem, se shranjujejo z namem, da lahko ljudje ali aplikacije poizvedujejo o stanju primera procesa ali o strukturi podatkov primera procesa. Procesi so obstojni, prav tako kot podatki v podatkovni bazi, in se lahko shranjujejo, arhivirajo ipd.. Nadzorovanje poslovnega procesa in BPMS Pomeni nadzorovanje in vzdrževanje s tehnične strani, to je s strani BPMS, in s procesov, ki tečejo na njem. BPMS vključuje module, ki so potrebni, da se procesi lahko nemoteno izvajajo, na primer nadgradnja 37

50 procesov in sistema v času delovanja, kompenzacija transakcij, spreminjanje izvajalcev procesa (dodaja udeleženca, odvzem pravic ipd.), dinamično dodeljevanje virov in razreševanje posebnih situacij ter napak. Optimaliziranje poslovnega procesa Pomeni neprestano izboljševanje procesa. Pomeni povratno zanko med snovanjem in analizo procesa. Primerjava rezultatov analize s tistimi iz simulacije modela procesa pokaže na primer kje so ozka grla procesa, katera aktivnost ima najvišje stroške ipd.. BMPS mora avtomatsko zaznati ozka grla, mrtve zanke in ostala nekonsistentna stanja v procesu. Optimalizacija je lahko ročna ali avtomatska. Avtomatska optimalizacija je na primer dodajanje virov za izvajanje, prehod iz zaporednega izvajanja aktivnosti v vzporedno, odstranitev redundanc ipd.. Optimalizacija je močno povezana z rezultati analize. Analiziranje poslovnega procesa Pomeni merjenje učinkovitosti procesa ter na podlagi rezultatov meritev odločanje o nadaljnji strategiji izboljševanja procesa. Rezultati meritev se primerjajo s cilji, ki so bili procesu določeni na začetku. Analiza nam da vpogled na časovno, stroškovno in zmogljivostno obnašanje celotnega poslovnega procesa. Spremembe procesa se lahko naredijo samo na posamezni aktivnosti, procesu ali pa celo na sami šabloni procesa. Prav tako kot v fazi snovanja, imamo tudi tukaj možnosti Kaj-če? (angl. What If?) analiz. S tem nivojem kontrole nad procesi le-ti dosežejo večjo odzivnost ter višjo stopnjo in večjo hitrost prilagajanja Metode spremljanja in analize poslovnih procesov Dve metodi izboljševanja poslovnih procesov na podlagi doseganja čimvečje kakovosti izdelka ali storitve (TQM in šest sigma) smo pogledali v poglavju Management kakovosti na strani 32. Metode spremljanja in analiziranja poslovnih procesov za poslovne ljudi pa še nismo omenili. Glavne tovrstne metode so naslednje: Metoda primerjave s konkurenco (angl. Benchmarking). Benchmarking je sredstvo ocene in spremembe poslovanja ter sredstvo učenja. Cilj benchmarkinga je ocena in merjenje lastne pozicije glede na konkurenco ter primerjava z najboljšimi v dejavnosti (včasih tudi izven nje) (Vukšić, Kovačič, 2004, str. 43.). Metoda uravnoteženih kazalnikov (angl. Balanced Scorecard, BSC) (Peruško, 2003, str. 83). BSC metoda vključuje štiri vidike uspešnosti poslovanja organizacije, ki izhajajo iz vizije in strategije podjetja ter so pri merjenju uspešnosti pomemben povezovalni element med njima. Podjetje ima vizijo o bodočem poslovanju, ki jo uresničuje z izbrano strategijo. Uravnoteženi kazalniki pomagajo prevesti strategijo podjetja v konsistenten splet kazalcev, s katerimi preverjamo uspešnost izvajanja strategije. Ti kazalci oz. vidiki uspešnosti so naslednji: - finančni vidik oz. vidik lastnikov organizacije, - vidik kupca (kazalci, s katerimi management spremlja, kako poslovanje podjetja vrednoti kupec), - vidik notranjih poslovnih procesov (kazalci za strateške poslovne procese, ki morajo biti najučinkovitejši, če želi organizacija zadovoljiti kupce in lastnike), - vidik učenja in rasti (ti kazalci odražajo sposobnost zaposlenih, kakovost sistemov in organizacijskih postopkov v podjetju, ki so osnova za organizacijsko učenje in rast). 38

51 Metoda analize stroškov aktivnosti (angl. Activity Based Costing, ABC) (Harmon, 2003, str. 458). Kot posledica Portejevega modela vrednostne verige se je pojavil nov pristop v kalkulaciji stroškov proizvajanja izdelka ali storitve. Imenuje se ABC. ABC se začne z ugotavljanjem stroškov posameznih aktivnosti. Stroški aktivnosti, ki sestavljajo proces, se seštejejo. Seštevek predstavlja dejanski strošek procesa, ki se odšteje od prodajnih rezultatov (zaslužka z izdelkom ali storitvijo). Razlika predstavlja dobiček Metode modeliranja poslovnih procesov Razvitih je bilo veliko metod, ki se uporabljajo za statično ali dinamično modeliranje poslovnih procesov. Ravno zaradi tako velikega števila teh metod je pri izbiri orodja za modeliranje potrebno paziti na metodo modeliranja na kateri temelji to orodje. Potrebno je paziti predvsem na: možnost enostavnega kreiranja in rokovanja ob pomoči ustreznega orodja (programske opreme), razumljivost in preglednost grafičnega prikaza in intuitivnost simbolov orodja za opis procesa, možnost strukturiranega in modularnega prikaza, možnost definicije hierarhične strukture, formalizem, ki je pomemben za prevod modela procesa v izvajalno okolje. Tabela 6: Različni vidiki in metode modeliranja poslovnih procesov. Vidik Osredotočenost na Ime metode podatkovni entitete (dokumenti, podatki), njihova struktura in povezanost, katere aktivnosti je potrebno opraviti, funkcijski katere aktivnosti se izvajajo, (kaj, kateri) kateri podatki vstopajo/izstopajo v/iz aktivnosti, organizacijski (kje, kdo) procesni (kdaj, kako) kje se aktivnosti izvajajo, kdo jih izvaja, kateri so mehanizmi komunikacije, kako se podatki shranjujejo, kateri so sprožilniki aktivnosti, sledenje izvajanju aktivnosti: niz, ponavljanje, odločitev, pogoj, kdaj se aktivnost izvaja, koliko časa traja aktivnost. diagram toka podatkov (angl. Data Flow Diagram, DFD), entitetno-relacijski diagram (angl. Entity-Relationship,ER), SADT diagram (angl. Structured Analysis and Design Techniques), IDEF0 diagram, IDEF3 diagram, UML diagram primerov uporabe, UML diagram sodelovanja, organizacijski graf, eepc diagrami (angl.extended Event Process Chain), UML diagrami aktivnosti, Petrijeve mreže (angl. Petri Nets), procesni račun (angl. Process Calculus, Pi-calculus,Join Calculus). Vir: Prirejeno po Vukšić, Kovačič, 2004, str. 80. Pri modeliranju je potrebno zaobjeti poleg samega prikaza poslovnega procesa tudi podatke, funkcije in organizacijsko strukturo. Skladno s to zahtevo se metode za modeliranje delijo na štiri vidike (tabela 6): podatkovni (podatki, informacije), funkcijski (aktivnost, enota dela), organizacijski (oddelki, udeleženci, vloge), procesno modeliranje (povezovanje podatkovnega, funkcijskega in organizacijskega vidika). DFD in ER diagrami se uporabljajo pri razvoju informacijskih sistemov. IDEF diagrami se uporabljajo kot standardna metoda za modeliranje podatkov predvsem v ZDA. eepc so osnova za največ uporabljeno 39

52 orodje za modeliranje poslovnih procesov ARIS. UML diagrami so integrirani v orodje za modeliranje in razvoj programske opreme IBM Rational. Petrijeve mreže in procesni račun sta metodi, ki imata matematično ozadje. V bistvu sta si največja konkurenta pri nastajanju jezika za modeliranje in njegovo uporabo v BPM paradigmi (Vukšić, Kovačič, 2004) Simulacija poslovnih procesov Dinamična simulacija predstavlja pomoč pri modeliranju in spreminjanju poslovnih procesov. Za simulacije poslovnih procesov se uporablja diskretna dinamična simulacija, ki opisuje nezvezne spremembe stanja poslovnega procesa skozi čas. Spremembe stanja so posledica interakcij aktivnosti procesa. Obstaja več razlogov za uporabo simulacije pri modeliranju poslovnih procesov. Le-ti so naslednji: diskretna dinamična simulacija prikazuje dinamiko procesa skozi čas (na primer čas izrabe vira, čas trajanja aktivnosti, čas čakanja na obdelavo, paralelno izvajanje aktivnosti ipd.), možnost spreminjanja vhodnih parametrov pri simulaciji poslovnega procesa. To omogoča eksperimentiranje z modelom, analizo in primerjavo različnih možnih scenarijev procesa, kar nam pomaga pri izbiri naj-bo modela, omogoča predvidevanje učinka izboljšav procesa ter zaznavo ozkih grl procesa, programske opreme za simulacije je na razpolago. Omogoča vizualizacijo in animacijo procesa. Programska oprema za simulacijo temelji na eni ali večih metodah modeliranja. Vsaka metoda modeliranja ima svoje simbole (notacijo), ki so prilagojeni simulacijskemu modeliranju (aktivnost, dogodek, vir ipd.). Njihovo sestavljanje v diagramu predstavlja proces. Metode modeliranja v diskretni simulaciji procesov se delijo na (Vukšić, Kovačič, 2004): 1. nevtralne glede na strategijo simulacije (različne variante Petrijevih mrež, diagrami cikla aktivnosti (angl. Diagram Cycle Activity) in diagrami aktivnosti (angl. Activity Diagram)), 2. orientirane na simulacijsko strategijo (najbolj poznani so grafi dogajanj), 3. metode, ki uporabljajo simulacijske jezike (blok diagrami v GPSS (General Purpose Simulation System) programskem jeziku), 4. ter ostale metode simulacije (na primer modeliranje IT sistemov, uporaba umetne inteligence ipd.). Organizacije za standardizacijo so na podlagi predvsem Petrijevih mrež ter procesnih računov naredile standarde za modeliranje in simuliranje poslovnih procesov (več v poglavju 2.2. Standardi za management poslovnih procesov). Izdelovalci programske opreme za modeliranje upoštevajo te standarde ter jih vključujejo v svoja orodja. Da dosežejo univerzalnost orodja, ponavadi proizvajalci vključujejo v svoja orodja za modeliranje vse štiri vidike modeliranja Prihodnost managementa poslovnih procesov Andrew Spanyi meni, da so bile organizacije mnogo let vodene v smislu tradicionalnega funkcijskega modela, kjer je bila pomembna funkcijska odličnost. Vodstva organizacij končno spoznavajo, da je BPM bistvena komponenta za doseganje konkurenčne prednosti. BPM je trenutno v fazi prehoda in se srečuje z 40

53 različnimi težavami oz. izzivi kot so: spremembe miselnega modela, kulturne spremembe, spremembe metodologij in tehnologij. Te težave oz. izzive bomo morali premostiti, da bo BPM resnično lahko pomagal organizacijam dosegati in ohranjati konkurenčno prednost (BPMG, Spanyi, 2004). Smith s svojimi sodelavci (Smith et al., 2002, str. 45.) ugotavlja, da BPM ni nova ideja. Management poslovnih procesov je evolucija predhodnih metodologij. Organizacije so vedno identificirale, snovale, izvajale, optimalizirale in analizirale poslovne procese, seveda z različno stopnjo uspešnosti. Vendar se je v zadnjih desetih letih drastično spremenil način izvedbe teh aktivnosti. V tabeli 7 so prikazane štiri stopnje managementa poslovnih procesov, ki so se pojavljale v zadnjih 15-tih letih in sicer iz treh različnih vidikov: poslovnega, tehnološkega in organizacijskega. Dalje Smith (Smith et al., 2002, str. 56) pojasnjuje, da proizvajalci ERP sistemov in različnih poslovnih aplikacij, ki nikoli niso mislili, da bodo morali kdaj sodelovati, sedaj iščejo poti sodelovanja ter možnosti arhitektur in strategij razvoja novih aplikacij, ki se bodo zavedale procesov. Organizacije sedaj vedo, da niti eden ponudnik poslovne programske opreme ne premore celotnega nabora, ki bi pokril vse potrebe neke organizacije po poslovnih aplikacijah. Stranke in proizvajalci sedaj povezujejo poslovne aplikacije na nivoju poslovnih procesov in s tem dosegajo njihovo prilagodljivost. Uporabljajoč BPM pristop lahko procese skrite v aplikacijah osvetlijo in naredijo nedvoumne. BPM ni nadomestilo za ERP ali WfM sisteme, je pa glasnik nove arhitekture (tako v poslovnem kot tudi v tehnološkem smislu), kjer bodo aplikacije in infrastruktura upravljane v smislu celovitih poslovnih procesov. ERP rešitev prihodnosti bo zgrajena na BPM odprtih standardih in se bo popolnoma zavedala procesov. Champy v svoji knjigi X-Engineering The Corporation: Reinventing Your Business In The Digital Age ugotavlja, da podjetja potrebujejo več kot le BPR. BPR se je osredotočil na prenovo procesov znotraj organizacije, sedaj pa je nastopil čas prenove procesov med organizacijami. Ta čas prenove procesov je poimenoval X-inženiring (angl. X-engineering, XE). Z XE organizacije ne avtomatizirajo starih procesov, temveč naredijo nove ob izdatni pomoči IT tehnologij. XE je, tako kot njegov predhodnik BPR, iniciativa, ki bo trajala dolgo časa. Champy opozarja, da XE za poslovanje ni dokončni odgovor, temveč je samo eden izmed inovacij na tem področju. Nadalje pravi, da XE procesi pomagajo poslovanju z uvajanjem IT tehnologij, ki podpirajo in izboljšujejo človeški potencial, in s tem je delo, ki ga ljudje opravljajo, manj naporno in v večje veselje (Champy, 2002). Kovačič v članku Business Renovation: Business Rules (Still) the Missing Link (Kovačič, 2004a) ugotavlja, da se poslovna pravila (angl. Business Rules) stalno spreminjajo, IT tehnologija pa še vedno ni v stanju hitro, zadovoljivo in učinkovito implementirati teh pravil 10. Ugotavlja, da se poslovni modeli procesov in IT modeli managementa poslovnega toka (WF) procesov stikajo in prekrivajo na nivoju aktivnosti, vendar je razlika v semantiki pri obeh modelih prevelika za uspešen prenos poslovnega modela v IT model. Da se razreši ta problem, Kovačič predlaga enoten način modeliranja za vse nivoje modeliranja (vrednostna veriga, poslovni procesi, aktivnosti ter programska oprema) z uporabo metodologije poslovnih pravil, ter uvaja meta-model poslovnih aktivnosti kot vezni člen za povezavo poslovnih in IT modelov na nivoju aktivnosti. Ta model predstavlja metodologijo modeliranja za izvabljanje, specifikacijo in prečiščevanje poslovnih pravil. 10 Več o poslovnih pravilih je napisal Ronald Ross (Ross, 2003) v knjigi Principles of the Business Rules Approach. 41

54 1. BPR (preteklost) Poslovni pogled Pred dobrim desetletjem je BPR obljubljal dramatične izboljšave, vendar je bilo potrebnih preveč naporov in ročnega dela. Tam, kjer je BPR bil uspešen, je sicer izboljšal proces(e), vendar mu ni uspelo zagotoviti dovolj velike okretnosti in prilagodljivosti procesa. Tehnološki pogled Informacijska tehnologija tistega časa ni bila sposobna zajeti in izvajati celotno zapletenost poslovnih procesov v obliki, ki bi bila enostavna za spreminjanje, izvajanje in preurejanje. Tabela 7: Preteklost, sedanjost in prihodnost BPM. 2. ERP in Workflow (bližnja preteklost) ERP sistemi so bili prodani vodstvu z obrazložitvijo, da ne bo več potrebno skrbeti za informatiko. Na začetku, pri uvajanju, so zelo prilagodljivi, po uvajanju postanejo togi. WfMS so bili odgovor na to. Poslovna logika iz aplikacij 11 se v obliki poslovnih pravil izvaja na WfMS. ERP model je zapekel poslovne procese v programsko opremo, vendar z omejeno sposobnostjo spreminjanja. Tudi WfMS ni bil čisto pravi odgovor na te težave, vendar je trenutno BPM izvajalno okolje za procese. Pogled uvajanja in organizacije BPR ni imel točno določene Identificiranje je bilo naporno metodologije. Zato sta se na ročno opravilo, ki je vodilo primer identificiranje in do dokumentacije procesa. snovanje pričela s Postavitev aplikacij v sestankom tima s praznim izvajanje je pomenilo listom papirja. Postavitev v ogromno delo v smislu časa izvajanje in izvajanje samo in stroškov, ter veliko je bilo sestavljeno iz pravil in tveganje v primeru zmote. procedur, ki jim je bilo Vzdrževanje in optimalizacija potrebno slediti. Vzdrževanje sta bili omejeni. WfMS je bilo izvedeno samo v tehnologija, ki je to malo primeru neuspeha, omilila, je bila tudi vključena optimalizacija in analiza sta v ERP sisteme. bili večinoma na seznamu želja. 3. Proces kot urejeni podatki (sedanjost) Orodja zajemajo in upravljajo procese in podatke. Omogočajo pogled na isti proces iz različnih zornih kotov, procesi se z lahkoto popravljajo in dopolnjujejo. Omogočajo enostavno implementacijo in zbiranje podatkov za poznejše analize. Orodja, ki so trenutno na voljo, še ne morejo direktno prenesti modela procesa v izvajalno okolje. Potrebni so še ročni posegi. Modeli procesov še niso izraženi v standardih, zato so uporabni samo v orodjih samih. Predvsem je problem v tehnoloških standardih, ki so še v nastajanju in zato pomanjkljivi. V fazi identificiranja je sedaj možno pogledati na definicijo procesa iz različnih zornih kotov v smislu poslovnih funkcij (vodstvo, analitik, IT tehnolog ipd.). Vseeno zaenkrat še vedno ni mogoče proces prevesti direktno v delujoč sistem. Optimalizacija in vzdrževanje je izvedeno predvsem vizualno s pregledom snovanja procesa, kar tudi pomeni, da imamo še vedno nekako dva modela procesa (poslovni in tehnološki). Tehnološki je izpeljanka poslovnega. Težko ga je držati v sinhronem stanju s poslovnim. 4. Proces kot programska koda za direktno izvajanje (prihodnost) Standard za opis procesov in sistemov za management procesov, s katerim se bo lahko razvilo proces in ga direktno izvajalo brez programiranja s t.i. Top-down pristopom. Tehnologija, potrebna za integracijo sistemov, bo vključena. Orodja za identificiranje in snovanje procesov ne pomenijo veliko, če niso omogočena za prenos modelov v izvajalno okolje. V prihodnosti bodo proizvajalci programske opreme razvijali orodja, ki bodo omogočala digitalno upravljanje z vsemi osmimi lastnostmi BPM 12. Identificiranje bo opisalo proces v standardnem digitalnem formatu, ki bo shranjen v shrambi podatkov sistema za management. Snovanje bo uporabljalo te aktivnosti za simulacijo in spreminjanje modela. Sama postavitev v izvajanje je zelo enostavna. Vse te aktivnosti se lahko izvajajo vzporedno in pospešijo dajanje procesa v izvajanje, ki se lahko uglašuje v živo. Procesi sami vključujejo mere in informacije o optimalizacijah in izboljšavah. Analize bodo obsegale cel proces in na ta način zaprle krog med snovanjem in izvajanjem. Vir: Povzeto po Smith et al., 2002, str. 46. Nadzorovanje poslovnih aktivnosti (angl. Business Activity Monitoring, BAM) daje organizaciji vpogled v njeno poslovanje v realnem času. Zajema podatke ter nadzoruje izvajanje poslovnih procesov. Iz teh surovih podatkov potem izlušči pomembne informacije, kot na primer novi trendi ali zaznavanje anomalij v 11 Tudi ERP je aplikacija oz. skupek aplikacij. 12 Poglavje Od identificiranja do managementa poslovnega procesa. 42

55 poslovnih procesih. BAM sistem v realnem času obvesti poslovne ljudi ter jim nudi dovolj informacij za reakcijo. Cilj BAM sistemov je spremljanje kritičnih poslovnih indikatorjev in indikatorjev učinka v realnem času, z namenom izboljšanja učinkovitosti in povečanja hitrosti poslovnega delovanja (Hayes, 2005). Čeprav sta BPM in BPMS naslednika različnih metodologij in tehnologij, kot sta na primer BPR in ERP, je BPM še vedno relativno mlada metodologija, ki se bo v prihodnje razvijala in dopolnjevala. BPM tehnologija se bo v naslednjih letih razvijala in dopolnjevala na naslednjih področjih: 1. tehnološki standardi za modeliranje in izvajanje, 2. enostaven prenos modela poslovnega procesa v izvajalno okolje, 3. aplikacije, ki se bodo zavedale procesov, 4. nadzor poslovnih aktivnosti, 5. enostavnost uporabe poslovnih pravil, 6. boljša orodja za identificiranje poslovnih procesov, ki jih bodo lahko uporabljali poslovni ljudje, 7. boljša orodja za grafično snovanje, simulacijo ter nadzor poslovnih procesov, 8. BPM sistemi, ki bodo enostavni za implementacijo, integracijo z zalednimi aplikacijami ter stroškovno ustrezni. Na koncu poglavja o prihodnosti BPM poglejmo še mnenja ljudi, ki jih je moč najti na svetovnem spletu: BPM je samo dim, tako kot je bil BPR, ki ga bodo poslovni svetovalci in zastareli proizvajalci programske opreme izrabili in naplahtali nič hudega sluteče stranke! BPM je volk v novi preobleki. To je samo prebarvani BPR! Če mislite delati iste stvari večno na isti način, potem bo vaša organizacija zaostala in postala neučinkovita. Načini poslovanja se spreminjajo. Organizacija mora biti dovolj okretna, da se zna spreminjati z njimi. V nasprotnem primeru je na stranskem tiru in napredek gre mimo nje. BPM je samo lepo ime za to, kar se v poslovanju dogaja vsak dan. Iz pepela prenove poslovnih procesov se je dvignil feniks managementa poslovnih procesov. Hammerjev koncept prenove je veljaven. So primeri poslovnih procesov, ki imajo podškovan dedni zapis. Najboljša metoda je iztrgati ter zavreči te procese in jih nadomestiti s popolnoma novimi. Nato je bil Hammerjev koncept izrabljen s strani lačnih po oblasti in kratkovidnih, ki so povzročili nenadomestljivo škodo organizacijam in posameznikom. Nevarnost managementa poslovnih procesov je, da bo sledil podobni poti Standardi za management poslovnih procesov Obstaja veliko neprofitnih organizacij, ki se neposredno ukvarjajo s standardizacijo postopkov, metodologij in tehnologij za BPM. Naštejmo samo najvažnejše: BPMI - Business Process Management Initiative, WfMC Workflow Management Coalition, OASIS - Organization for the Advancement of Structured Information, OMG Object Management Group, W3C World Wide Web Consortium. 43

56 Različnost in številčnost tehnik in metodologij BPM predstavlja za uporabnike ogromen problem. Čeprav se je standardizacija teh tehnik in metodologij začela že pred več kot desetimi leti 13, še vedno obstaja za management poslovnih procesov potreba po vsestransko sprejetih standardih. S sprejetjem in uporabo takih standardov bi izginili problemi kot so prenosa modelov med različnimi orodji različnih proizvajalcev, prenosa modela iz modeliranja v izvrševanje, problem različnih pogledov za različne vloge (poslovnega analitika in sistemskega inženirja) ipd.. Če pogledamo modeliranje poslovnih procesov kot enega od začetnih korakov uvedbe BPM v organizacijo, na tržišču trenutno obstaja vsaj 15 različnih standardov, ki opisujejo modeliranje in sam BPM na vsaj štirih področjih (Medling, Neumann, Nuettgents, 2004): Kompozicija - definicija interne implementacije za izvajanje poslovnega procesa, na primer kompozicija spletnih storitev. Koreografija - definira eksterno obnašanje poslovnega procesa; koreografija spletnih storitev na primer definira pravilno časovno zaporedje in zaporedje sporočil, ki se izmenjujejo v poslovnem procesu. Poslovna analiza - prikaz delovanja in učinkov procesa managerjem. Prikaz je lahko na podlagi izračunanih statistik tekstoven ali grafičen. Formalna analiza - preverjanje veljavnosti, pravilnega opisa in kakovosti procesa. Tabela 8: Primerjava BPM standardov. Koncept BPDM BPEL4WS BPML BPMN BPSS EPML OWL-S PNML UML Act.D WS-CDL WSCI WSCL WSFL XLANG XPDL I/O enote dela? Naslov enote dela? Atributi kakovosti? Protokol enote dela? Kontrolni tok? Rokovanje s podatki? Identiteta izvajanja? Vloge? Dogodki? Izjeme? Transakcije? Grafična pozicija? Statistični podatki? Legenda: +... vključuje, -... ne vključuje,?... še v nastajanju Vir: Medling, Neumann, Nuettgents, 2004, str. 7. Nekateri od teh standardov drug drugega dopolnjujejo, povečini pa se prekrivajo. Medling, Neumann in Nuettgents so na podlagi teh standardov definirali meta-model ter naredili primerjavo teh standardov z njim. 13 Primer je IBM-ov Flow Definition Language (FDL), ki je predhodnik standarda Web Services Description Language (WSDL) ter standarda Business Process Execution Language for Web Services (BPEL4WS). Zaradi popolnosti dodajmo še, da je 44

57 Ta meta-model je sestavljen iz 13-tih konceptov. Glede na to ali nek standard vsebuje ta koncept ali ne, so mu podelili + ali (tabela 8). Ti koncepti so naslednji: 1. I/O enote dela (angl. Task I/O): je osnovna enota dela, katere časovne ali logične povezave so modelirane v procesu. Vhodi in izhodi (I/O) teh enot se lahko modelirajo z uporabo enostavnih ali kompleksnih XML tipov. 2. Naslov enote dela (angl. Task Address): specificira kje oz. kako se lahko storitev za izvedbo enote dela najde. Naslov se lahko modelira direktno z uporabo URI (Universal Resource Identifikator) naslova storitve ali indirektno z iskanjem, ki enoznačno določa naslov storitve. 3. Atributi kakovosti (angl. Quality Attributes): Kadar je storitev klicana direktno z iskanjem, se lahko uporabi atribut kakovosti, ki določa najboljšo storitev. 4. Protokol enote dela (angl. Protocol): določa nabor pravil za kontrolo interakcij kadar storitev izvaja enoto dela. Spletne storitve uporabljajo SOAP protokol (Simple Object Access Protocol). 5. Kontrolni tok (angl Control Flow): časovna in logična povezava med različnimi enotami dela. 6. Rokovanje s podatki (angl. Data Handling): določajo katere spremenljivke se bodo uporabile pri posameznem izvajanju procesa. 7. Identiteta izvajanja (angl. Instance Handling): določa kako je identificirano posamezno izvajanje ter z njim povezana sporočila in podatki. 8. Vloge (angl. Roles): za abstrakcijo udeležencev v procesu. Vloge se dodelijo enotam dela in uporabniki vlogam. 9. Dogodki (angl. Events): spremembe oz. rokovanje z dogodki na vnaprej določen način. 10. Izjeme (angl. Exceptions): izjeme ali napake se pojavljajo med izvajanjem procesa. 11. Transakcije (angl. Transakcije): ACID transakcije so kratkotrajne transakcije, ki se izvršijo ali vrnejo v prvotno stanje, medtem ko so poslovne transakcije dolgo trajajoče. V primeru, da se mora poslovna transakcija vrniti v prvotno stanje (angl. Roll-back ali Back-out), za to poskrbi kompenzacijska transakcija (angl. Compensation Transaction). 12. Grafična pozicija (angl. Graphic Position): znatno pripomore k razumljivosti procesnega modela. Informacije o sami ureditvi procesa so lahko vključene v meta-model. 13. Statistični podatki (angl. Statistical Data): analize učinkovitosti procesa so narejene na statističnih podatkih kot sta strošek in čas izvajanja. Opis standardov: 1. BPDM 14 (Business Process Definition Meta-Model) OMG BPDM je še vedno v razvoju. Na sredi leta 2005 se je zaključil rok za oddajo pripomb. Standard BPDM obsega definicije poslovnih modelov. Skladen je z MOF (Meta-Object Facility), ki je standard v okviru MDA (Model Driven Architecture). Format izmenjave modelov temelji na XMI (XML Meta-Data Interchange). 2. BPEL4WS 15 (Business Process Execution Language For Web Services) ali na kratko samo BPEL OASIS od IBM, Microsoft in BEA BPEL4WS nastal iz WSDL in Microsoftovega XLANG. 45

58 BPEL je specificiran kot format izmenjave preko XML shem. BPEL modelira aktivnosti kot klice spletnih storitev, katerih vhodi in izhodi so določeni s sporočili in katerih naslovi so enoznačno določeni z URI (Uniform Resource Locator) tipa WSDL 16 (Web Service Description Language). Kot komunikacijski protokol je uporabljen SOAP. BPEL kontrolni tok je lahko modeliran z blok diagrami ali grafi, rokovanje s podatki pa je izraženo s spremenljivkami in operacijami. Vloge so določene s tako imenovanim tipom partnerske povezave (angl. Partner Link Type). BPEL podpira tudi rokovanje z dogodki in napakami, kakor tudi kompenzacijo transakcij procesa. Opiše lahko kompozicijo in koreografijo spletnih storitev. 3. BPML 17 (Business Process Modeling Language) BPMI BPML je zelo podoben BPEL. BPEL bo z verzijo 2 postal BPML skladna implementacija. Trenutno sta glavni razliki v tem, da BPML dovoljuje specifikacijo večih procesov v enem XML dokumentu ter da ni vezan na WSDL, temveč je komunikacijski protokol prepuščen BPML skladni implementaciji. 4. BPMN 18 (Business Process Modeling Notation) BPMI Namen BPMN je poenotenje različnih grafičnih notacij za poslovne in tehnične ljudi. Specifikacija vsebuje tudi povezavo z BPEL. Zato BPMN meta-model vsebuje večino BPEL konceptov. Dodatne specifikacije bodo določile BPMN meta-model, ki bo temeljil na MOF. To bo dovolilo serializacijo z XML pravili za XML izmenjavo. 5. BPSS 18 (Business Process Specification Schema) OASIS in UN/CEFACT Je del ebxml (e-business XML) standarda. Vsebuje meta-model in XML sheme za koreografijo spletnih storitev. Ne vsebuje implementacijskih vidikov kot so rokovanje s podatki ali identiteta izvajanja. Podpira tudi vloge, izjeme in transakcije v med-organizacijski izmenjavi sporočil. 6. EPML 19 (Event-Driven Process Chain Markup Language) akademska iniciativa Vsebuje elemente kontrolnega toka za verigo procesov na nivoju dogodkov (angl. Event-Driven Process Chain, EPC). Vsebuje tudi grafično predstavitev EPC objektov. Razširitve standarda se lahko dodajajo v obliki uporabniških dodatkov. 7. OWL-S 20 (Web Ontology Language - Service) akademska iniciativa in W3C OWL je jezik, uporabljen pri aplikacijah, ki morajo predelati vsebino informacij, ne pa jih samo prikazati ljudem. Storitveni meta-model, ki gradi na OWL, je OWL-S. OWL-S vsebuje osnovne gradnike za opis lastnosti in sposobnosti spletnih storitev. Vsebuje tudi definicijo vlog in svoj protokol, podoben WSDL, za odkrivanje in dostop do spletnih storitev. 8. PNML 21 (Petri Net Markup Language) akademska iniciativa Je XML format za izmenjavo modelov Petrijevih mrež. Podpira osnovno sintakso Petrijevih mrež. Lahko se tudi razširi na poljubne tipe Petrijevih mrež. 9. UML 2 22 diagram aktivnosti (Unified Modeling Language) OMG

59 Metamodel vsebuje koncepte za modeliranje vhodov in izhodov aktivnosti, kontrolnega toka, rokovanja s podatki, vlog, izjem in grafičnih informacij. Uporablja XMI za izmenjavo. 10. WSCDL 23 (Web Service Choreography Description Language) W3C Gradi na WSDL in SOAP. Vsebuje osnovne gradnike za kontrolni tok, rokovanje s podatki, vloge, izjeme in modeliranje transakcij. 11. WSCI 24 (Web Service Choreography Interface) W3C Opisuje obnašanje procesa pri izmenjavi sporočil med procesi. Podpira WSDL povezave, WSCI korelacije, vloge, obravnavanje izjem in transakcije. 12. WSCL 24 (Web Service Choreography Language) Hewlett-Packard, W3C Vsebuje minimalno število konceptov z namenom, da opiše koreografijo procesov, protokol, tip sporočil in lokacijo storitve. Specifikacija vsebuje meta-model in XML sheme. 13. WSFL 25 (Web Service Flow Language) IBM Je eden od predhodnikov BPEL-a. Vključuje večino konceptov, razen transakcij, informacij o grafični poziciji in statističnih podatkov. Kontrolni tok v WSFL je modeliran direktno z grafi. 14. XLANG 26 Microsoft Skupaj z WSFL je predhodnik BPEL4WS. Podobno kot WSCI, WSDL podpira povezave za opis obnašanja procesa, korelacijo, vloge, dogodke, obravnavanje izjem ter deklaracijo transakcij. 15. XPDL 27 (XML Process Definition Language) WfMC To je standardiziran format izmenjave za poslovne procese, predlagan s strani WfMC. Vključuje različne koncepte, razvidne iz tabele 8, poleg tega pa podpira tudi statistiko procesa kot so na primer trajanje in stroški procesa, kar ne podpira noben drug standard. Slika 16: Standardi BPM. Vir: prirejeno po

60 BPM nabor standardov na sliki 16 dandanes predstavlja pravzaprav dve tipični osnovi za veliko večino proizvajalcev BPMS programske opreme. Ena osnova je BPML in WSCI. Druga je BPEL4WS in WS. SOAP predstavlja transportni protokol za storitve izpostavljene kot spletne storitve z uporabo WSDL v obeh variantah. WSCI in WS sta uporabljeni za upravljanje spletnih storitev znotraj procesa ter za definicijo povezav med različnimi procesi. BPML uporablja WSCI. V primeru BPEL4WS le-ta uporablja spletne storitve protokol za varnost, koordinacijo in transakcijo. Oba, BPML in BPEL4WS, uporabljata kadar želimo neko storitev poiskati poleg SOAP in WSDL tudi UDDI register (UDDI 28 - Universal Description, Discovery and Integration). Šablone procesov so v bistvu primeri najboljše prakse in standardni procesi, razdeljeni po različni vertikalnih industrijah za horizontalne aplikacije. Modelirani so z BPMN, nato pa prevedeni v procese, pripravljene za izvajanje z uporabo BPML. Kot lahko ugotovimo, trenutno na področju BPM standardov vlada prava zmeda. Podjetji Microsoft in IBM želita postaviti BPEL4WS kot edini standard, seveda pa obstaja odpor pri konkurenčnih organizacijah, kot je na primer BPMI s svojim BPML standardom. BPMI ima podporo s strani podjetij Sun Microsystems in SAP, medtem ko podjetje BEA podpira oba standarda: BPEL4WS in BPML. WfMC prav tako ponuja podoben standard - XPDL. Celo Združeni narodi in OASIS sta vmešana z BPSS jezikom, ki obstaja v okviru ebxml (Electronic Business XML) iniciative. Pri tako veliki konkurenci je jasno, da smo še daleč od nekega splošno sprejetega standarda. Gartner je avgusta 2002 predvideval, da bo razvoj standardov za BPM trajal vsaj še do leta Med vsemi temi standardi imata verjetno BPEL4WS in BPML največ verjetnosti za uspeh, še posebej na področju spletnih storitev. Vsekakor je upravičena bojazen, da se organizacije, ki so zadolžene za standardizacijo, ne bodo mogle sporazumeti in določiti enotnega standarda. V tem primeru se zna zgoditi do bomo dobili de-facto standard, ki ga bo uporabljala večina. V tem primeru je verjetno BPEL4WS prvi kandidat Implementacija managementa poslovnih procesov Za implementacijo poslovnih procesov sama BPMS tehnologija ni dovolj. Najprej so predvsem potrebni naslednji pogoji: 1. razumevanje in odločenost vodstva o pomembnosti in potencialu BPM za organizacijo, 2. jasno določena strategija, cilji in detajli o načinu uvajanja BPM, 3. ljudje z zadovoljivim znanjem ter spektrom znanja, kar bo omogočalo hitro in učinkovito implementacijo. Ti pogoji so neločljivo povezani med seboj, ker drug drugega pogojujejo. Za uspešno implementacijo BPM se morajo ti pogoji razvijati in gojiti vzporedno. Smith in ostali (Smith et al., 2002, str ) predlagajo, da BPM tim uvede BPM v treh korakih. Ti trije koraki so naslednji: 1. Prva naloga BPM tima je izobraževanje vodilnih ljudi v organizaciji: Pričakujejo naj skepticizem s strani poslovnih in tehničnih ljudi

61 V obliki delavnic, skupaj s poslovnimi in tehničnimi ljudmi, morajo poskušati nadgraditi obstoječe strategije in poslovne procese z osredotočanjem na BPM pomoč pri izboljševanju poslovanja. Ustanoviti morajo BPM uporabniške skupine, v katerih vsi udeleženci BPM projekta aktivno sodelujejo. Narediti morajo elektronske zbirke dokumentov, v katerih se zbira vsa pomembnejša BPM literatura. Dostop do zbirke je omogočen vsem udeležencem BPM projekta. 2. Druga naloga BPM tima je izbira pravega projekta ter implementacija le-tega: Identificirati in izbrati morajo (ali vplivati na izbiro) pravi poslovni proces za implementacijo. Pod imenom pravi mislimo na poslovni proces oz. projekt, ki je dovolj viden, pomemben za organizacijo, ne preveč rizičen in bo pravilno demonstriral uporabonost BPM. Določiti je potrebno tudi faze in obseg projekta. Začeti morajo z aktivnostmi za snovanje procesa. Pri identifikaciji in snovanju procesa se ponavadi izkaže, da sta potrebni obe fazi, da se proces razume in definira. Včasih se izkaže, da nek proces sploh ne obstaja ter da udeleženci v procesu (stranke, dobavitelji ipd.) sledijo nekim svojim proceduram z zelo malo razumevanja, za poslovanje drugih v tem procesu. V fazi snovanja se uporabljajo BPMS orodja. Ta orodja imajo oz. bodo imela standardiziran format izmenjave podatkov, na primer BPML ali BPEL4WS, kar omogoča direkten prenos modela v izvajalno okolje. Katero BPM tehnologijo bodo izbrali, je odvisno od samega projekta. a.) kadar se poslovni proces razširija med aplikacijami in čez meje organizacije se izbere implementacija poslovnega procesa, ki vključuje samo čiste BPM tehnologije (brez EAI), b.) kadar se dve podjetji združita ali obstaja potreba po integraciji aplikacij z ERP sistemi ali z zalednimi aplikacijami, se ponavadi izbere BPM tehnologija, ki vključuje tudi EAI. glede na željeno funkcionalnost, kratkoročne in dolgoročne koristi ter odvisno od izbrane BPM tehnologije, morajo izbirati proizvajalca oz. proizvajalce BPMS programske opreme. Pozornost je potrebno usmeriti tudi na stroške nakupa in vzdrževanja orodja ter tveganje nakupa orodja. Nekatere funkcionalnosti, ki jih BPM tehnologija lahko ima, so naslednje: a.) integracija aplikacij in za to ustrezno vmesno programje, b.) spletni aplikacijski in aplikacijski strežniki, c.) WfM sistem za avtomatizacijo procesov in za ročno izvajanje, d.) BPM strežnik (nekateri bazirajo na predelanih WfMS strežnikih), e.) orodja za modeliranje, simuliranje, analizo, nadzor poslovnih procesov z uporabo šablon procesov in poslovnih pravil. Dandanes niti eden od ponudnikov še ne ponuja celovite BPMS rešitve. Izjeme so: a.) velike svetovalne organizacije, ki uporabljajo trenutno najboljše tehnologije različnih proizvajalcev, b.) veliki proizvajalci, ki kupujejo manjša podjetja in s tem tudi njihovo tehnologijo. Prenavljajo svoje produkte in jih integrirajo s kupljenimi. Rezultat je BPMS nabor produktov, ki lahko praktično ustreže kakršnikoli potrebni funkcionalnosti BPMS. Primer je podjetje IBM z WebSphere družino programske opreme, 49

62 c.) specializirani proizvajalci, osredotočeni na BPMS programsko opremo. Ti ponavadi kupujejo od drugih proizvajalcev določene komponente kot so na primer spletni aplikacijski strežnik, transakcijski strežnik ipd.. Odločiti se morajo za uporabo outsourcing procesov, ter kateri procesi niso strateškega pomena. Določiti morajo in v organizacijo uvesti lastne organizacijske BPM standarde. 3. Tretja naloga BPM tima je vzpostavitev, negovanje in rast različnih znanj: Poslovni in tehnični ljudje potrebujejo tri različne vrste znanj za implementacijo BPM: a.) Praktična in strokovna znanja. To so znanja o izvajaju aktivnosti. Za poslovne ljudi je to na primer procesiranje naročila, za tehnike pa na primer programiranje v nekem jeziku. b.) Sposobnost sodelovanja z drugimi ljudmi v timu. To obsega komunikacijske, sodelovalne, prepričevalne, izobraževalne in voditeljske sposobnosti. c.) Kognitivna znanja vključujejo sposobnost videti širšo sliko, spoznavanje novih možnosti (kreativnost) in sistemsko mišljenje (sposobnost prepoznavanja ključnih komponent procesa in razumevanje kompleksnih interakcij med njimi). Vzpostaviti morajo organizacijo, ki se uči (angl. Learning Organization) Storitveno orientirana arhitektura Storitveno orientirana organizacija 29 (angl. Service Oriented Enterprise, SOE) je nov model načrtovanja programske opreme in IT infrastrukture. Implementira se jo lahko na obstoječi arhitekturni platformi (na primer J2EE (Java 2 Enterprise Edition),.Net (Dot Net) itd.), hkrati pa predstavlja osnovo za BPM oz. za procesno orientirano arhitekturo (angl. Process Oriented Architecture, POA), ki je naslednja generacija IT arhitekture. V srcu SOE se uporablja SOA. SOA definira, kako dve računalniški entiteti delujeta vzajemno na način, da ena opravi enoto dela namesto druge entitete. Enota dela se razume kot storitev. Interakcije storitev so definirane z opisnim jezikom (na primer WSDL v primeru kadar SOA implementacija uporablja spletne storitve). Vsaka interakcija je zase zaključena celota ter je ohlapno povezana (angl. Loosely Coupled). Tako, da so interakcije neodvisne druga od druge. SOAP in spletne storitve (Web Services) so postali najbolj pogosta in priljubljena SOA implementacija, čeprav obstajajo tudi druge vrste SOA implementacij, ki ne uporabljajo spletnih storitev. Implementacija SOA je neodvisna od protokola, saj vsebuje nivo translacije protokolov med potrošnikom (angl. Consumer) in ponudnikom (angl. Provider), na primer med HTTP (Hyper Text Transfer Protocol) in JMS (Java Message Service). To pomeni, da lahko različne storitve komunicirajo med seboj neodvisno od protokola. Podobno kot SOA, ki ločuje integracijsko od poslovne logike, ločuje BPM arhitektura poslovno od procesne logike. BPM arhitektura uporablja SOA za enoten način dostopa do različnih sistemov in aplikacij, ki jih proces pri izvajanju potrebuje. SOA omogoča izmenjavo in uporabo informacij ter gibčnost IT sistemov ter je sestavni del BPMS

63 Sistem za management poslovnih procesov BPMS sistem mora biti fleksibilen in prilagodljiv, zanesljiv in razširljiv, varen (predvsem kadar se proces razteza na B2B področje), hkrati pa se mora dati upravljati in nadzorovati v realnem času. BPMS sistemi so konvergenca in konsolidacija IT tehnologij (na primer EAI, B2B ipd.). So kombinacija procesno in storitveno orientirane arhitekture. BPMS omogoča organizacijam modeliranje, simulacijo, postavitev, izvajanje in upravljanje poslovnih procesov, ki se raztezajo med različnimi aplikacijami, oddelki ter poslovnimi partnerji. BPM je relativno mlada iniciativa, zato so standardi za BPM šele v izoblikovanju. Iz tega razloga nekega tipičnega BPMS ni. Nekateri proizvajalci celo ne uporabljajo izraza BPMS ampak uporabljajo izraze kot so na primer: četrti sloj IT arhitekture, upravljanje poslovnih storitev (angl. Business Services Orchestration, BSO) ali sestavljene aplikacije (angl. Composite Applications), nova generacija WfMS, inteligentno vmesno programje (angl. Smart Midlleware), organizacija realnega časa ali arhitektura na zahtevo (angl. On-Demand Architecture). Kakorkoli že, vsi ti izrazi so znanilci BPM gibanja (Smith, Fingar, 2003, str ). Zaradi tega bomo v tem poglavju pogledali, glede na naše trenutno razumevanje BPM, katere funkcionalnosti naj bi imel idealni BPMS. Nato bomo pogledali še arhitekturo na zahtevo podjetja IBM. Slika 17: Shematičen prikaz sistema za management poslovnih procesov. Vir: Smith, Fingar, 2003, str BPMS je predstavljen na sliki 17 in 18. Na sliki 17 je predstavljen idealni BPMS s kocko (podobno kot baza podatkov z valjem). BPMS izvaja poslovne procese (ki so vedno na vrhu) s pomočjo funkcionalnosti: avtomatizacije, integracije in sodelovanja. Deset funkcionalnosti idealnega BPMS sistema navajata v svoji knjigi Smith in Fingar (Smith, Fingar, 2003, str. 245). Te funkcionalnosti za poslovni proces so sledeče: modeliranje, simulacija, analiza, razvoj sodelovanja, dokumentiranje, integracija aplikacij, avtomatizacija, B2B sodelovanje, postavitev okolja za uporabnike, management znanja (angl. Knowledge Management, KM). 51

64 K tem funkcionalnostim Russell (Russell, 2005) dodaja še naslednje: management ciljev (v realnem času), izvajanje procesa ter WfMS tehnologija, management vsebin (angl. Content Management, CM). Še posebej poudarja funkcionalnost in pomembnost analize ter povratne zanke iz analize na modeliranje in simulacijo. Trdi, da je management ciljev možno doseči samo na ta način. Slika 18 prikazuje IBM On-Demand arhitekturo. Bazira na SOA arhitekturi ter tehnologijah spletnih storitev. V tej arhitekturi je vsak vir navzven izpostavljen z naborom storitev, ki jih nudi. Določene so tri vrste storitev: storitve aplikacij, infrastrukture in poslovne storitve. Storitveno vodilo (angl. Enterprise Service Bus, ESB) predstavlja vezni člen med temi storitvami. Slika 18: IBM On-Demand arhitektura. Vir: IBM,

65 ESB skrbi za posredovanje in transformacijo podatkov in protokolov prenosa med storitvami, za zbiranje podatkov o dogodkih ipd.. Vključuje tehnologije kot so: JMS omogočen sporočilni sistem (angl. Message Queueing System, MQS), integracijski posrednik (angl. Integration Broker ali Message Broker), spletni aplikacijski strežnik (angl. Web Application Server, WAS), nadzornike transakcij ipd.. Vsebuje tudi priključke in adapterje, potrebne za integracijo zalednih aplikacij z ESB (v smislu EAI). Storitve aplikacij so tiste storitve, ki so skupne vsem poslovnim aplikacijam. Lahko se jih izlušči in postavi kot samostojne storitve, ki so na voljo vsem ostalim storitvam arhitekturi na zahtevo. Tipično so to naslednje storitve: za dostop in interakcijo uporabnikov do poslovnih aplikacij, kot so prilagajanje glede na vlogo uporabnika, sodelovanje med uporabniki, prikaz vsebine, povezovanje in interakcija z uporabniki. Vključujejo tehnologije kot so WfMS, WAS, programsko opremo za sodelovanje (IBM Lotus) ipd., poslovnih procesov, ki omogočajo koreografijo poslovnih procesov ter uporabo poslovnih pravil pri izvajanju procesov. Tehnologije: BPMS strežnik za koreografijo procesov, strežnik za poslovna pravila ipd., storitve poslovnih funkcij, ki vsebujejo kupljene (paketne) aplikacije ter aplikacije, narejene po meri. Zaželjeno je, da se aplikacije v čimvečji meri zavedajo procesov. Za tiste (zaledne) aplikacije, ki se procesov ne zavedajo, se lahko uporabi klasična EAI, skupne storitve, kot so generacija poročil, personalizacija, ter razne kupljene storitve (outsourcing), za management informacij, ki pomenijo manipulacijo in integracijo s podatki procesa in s podatki o dogajanju v procesu. Vključuje metodologije in tehnologije za analize kot so na primer poslovna inteligenca (angl. Business Intelligence, BI), management znanja ipd.. Storitve infrastrukture omogočajo nemoteno delovanje aplikacij in s tem poslovnih storitev. Vključujejo storitve za enostavno definiranje mer uspešnosti, izvajanje poslovnih storitev, omogočajo storitve upravljanja, avtomatizacije, odpravljanja problemov in napak, delitev dela (angl. Workload), razpoložljivosti ipd.. Na najnižjem nivoju so storitve navideznih virov, kar vključuje strojno opremo, kot so na primer strežniki, diskovna polja (angl. Storage Array Network, SAN), mreža ipd. ter avtomatsko dodeljevanje teh virov v primeru zmogljivostnih problemov. Poslovne storitve so tiste storitve, ki predstavljajo poslovanje organizacije. So ključ do uspeha oz. konkurenčne prednosti. Poslovna storitev predstavlja tisti nabor poslovnih pravil (in programske kode), ki predstavljajo organizaciji največjo vrednost in so kot taki največ vredni, najbolj dinamični in najtežje opisljivi v smislu formalnih definicij. Kot ena izmed poslovnih storitev je predstavljen tudi management poslovnih učinkov, ki uporablja predvsem storitve zajemanja in obdelave podatkov, obveščanje o poslovanju ter avtomatsko (če je mogoče in če so postavljena pravila) odpravlja probleme in napake. IBM arhitektura na zahtevo, pravilno implementirana, predstavlja popoln BPMS sistem, s katerim lahko organizacija postane sposobna zaznavati spremembe v poslovanju ter na njih hitro odgovarjati. 53

66 3. PRAKTIČNI DEL Čeprav ljudem navadno takoj, ko na delovnem mestu slišijo besedi poslovni proces, zledeni kri v žilah, saj pomislijo na birokratsko zapletenost, izpolnjevanje nepotrebnih obrazcev in odvečno delo, so urejeni poslovni procesi pogoj za uspešnost podjetja. Poslovni procesi so srce vsake organizacije. Pravzaprav je vsaka aktivnost, ki jo zaposleni v organizaciji opravlja, le del širšega procesa. Vidimo, da ob nespoštovanju le-teh zelo hitro pride do napak in zastoja, ki lahko prizadene velik del organizacije. Po drugi strani pa dobro definirani procesi omogočajo hitrejše delo, saj si aktivnosti sledijo po vnaprej določeni shemi. Zato se močno skrajša čas, ki preteče med aktivnostmi, ker ni potrebe po razmišljanju in iskanju poti za naslednji korak. Zmanjša se tudi število napak, saj pred-definiran proces vodi delo znotraj predvidenih okvirov in ima pripravljene točke na katerih se preverja rezultate in opravlja korektivne ukrepe. Različni načini dela zahtevajo različno strogost organizacije procesa. Stroge procese navadno uporabljamo pri ponavljajočem se delu, kjer smo iz izkušenj ugotovili optimalno zaporedje aktivnosti, ki omogočajo najkrajši čas in najnižje stroške. Intelektualnega dela pa navadno ni smiselno omejiti s preozkim okvirjem, saj že iz narave tega dela sledi, da z njim pravzaprav sproti iščemo pot do zaključka. Največji razlog za odpor do strogih poslovnih procesov je v načinu izvajanja le-teh. Ker proces na vsaki točki zahteva še obdelavo veliko spremnih informacij od vhodnih do kontrolnih imamo občutek, da namenjamo delu s temi informacijami več časa in energije kot delu z aktivnostmi samimi. Tukaj vidimo prednost, ki jo prinaša informatizacija in digitalizacija poslovnih procesov. BPM sistem kolikor je mogoče razbremeni izvajalca aktivnosti nepotrebnega dela in mu omogoči, da posveti več časa izvajanju aktivnosti. Hkrati ga tudi razbremeni poznavanja širšega procesa. Število napak se zmanjša, saj lahko v BPM sistem vgradimo preverjanje ustreznosti poteka dela na vsakem koraku. Poslovni proces definiramo kot zaporedje aktivnosti. Izvajajo se ročno, BPM sistemom pa želimo izvajanje poslovnih procesov in aktivnosti, kjer je le mogoče in smiselno, čim bolj avtomatizirati. Vedeti namreč moramo, da se nekatere aktivnosti in procesi ne dajo podpreti z informacijsko tehnologijo ali pa ni ekonomskega opravičila za to. Za jasno sliko procesa moramo definirati podatkovni in kontrolni tok procesa. Podatkovni tok sestavljajo podatki, ki prehajajo iz aktivnosti v aktivnost. Kontrolni tok pa na podlagi poslovnih pravil krmili prehode podatkov iz ene aktivnosti v drugo. Na podlagi določenih pravil v kontrolnem toku lahko proces na primer preskoči določeno aktivnost zaradi rezultata prejšnje aktivnosti. Zaporedje aktivnosti imenujemo procesni model. Procesni model opisuje strukturo poslovnega procesa v realnem svetu. Enoznačno določa vse možne poti, ki vodijo skozi poslovni proces, vse aktivnosti in tudi vsa pravila odločanja. Ta model je šablona, po kateri se tvori vsak nov primer (angl. Instance) procesa. Informatizacije procesa ne moremo začeti, dokler nimamo določenega modela procesa. Šele tedaj imamo na voljo vse informacije, na podlagi katerih se lahko odločimo za način implementacije procesa in predvidimo vse zahteve zanj. Ob natančni določitvi samih procesov, ki jih želimo podpreti, je treba pred izdelavo ali nakupom BPM sistema oceniti še naslednje faktorje: hitrost izdelave in implementacije modela, prilagodljivost poznejšim spremembam, zahteve uporabnikov, možnosti širše uporabe, možnosti nadzorovanja procesov ter seveda stroške razvoja poslovnih procesov ter nakupa in vzdrževanja (Slak, Geršak, 2002). 54

67 3.1. Tehnološke komponente V tem poglavju je podan kratek opis tehnoloških komponent (programske opreme) uporabljenih v praktičnem delu. Več informacij lahko najdemo na spletnem naslovu: ali iz naslednje literature, ki je dostopna na spletnem naslovu Intra-Enterprise Business Process Management (Van de Putte et al., 2001), Continous Business Process Management with Holosofx BPM Suite and IBM MQSeries Workflow (Deborin et al., 2002), A B2B Solution Using WebSphere Business Integration V4.1 and WebSphere Business Connection V1.1 (Gavin et al., 2003), Business Integration Management Using WebSphere BI Modeler and Monitor: A real world case study (Gavin et al., 2004) Modeliranje in analiziranje IBM WebSphere Business Integration Modeler 30 IBM WebSphere Business Integration Modeler je programski paket za modeliranje podjetja, modeliranje poslovnih procesov, analiziranje poslovnih procesov, prevajanje poslovnih procesov v FDL in BPEL4WS jezik. Zmožnost modeliranja in analiziranja kot-je in naj-bo poslovnih procesov sta najpomembnejši lastnosti. Z uporabo IBM WebSphere Business Integration Monitor programske opreme, se lahko to orodje uporablja tudi za ponovno snovanje naj-bo procesa. Glavne značilnosti WBI Modeler orodja so: enostavno modeliranje, testiranje, analiziranje, simuliranje in preiskovanje veljavnosti modela poslovnega procesa, uvoz in izvoz definicije modela v FDL jeziku (povezavenje z izvajalnim okoljem IBM WebSphere MQ Workflow), uvoz in izvoz definicije modela z njegovimi vrednostimi (čas izvajanja, cena ipd.) iz/v IBM WebSphere Business Integration Monitor za ponovno snovanje, simuliranje in analizo procesa v izvajanju Izvajalno okolje IBM WebSphere MQ Workflow 31 IBM WebSphere MQ Workflow (WMQWF) je sistem za management delovnega toka. Spada v skupino produkcijskih WfM sistemov (Slak, Geršak, 2002). Za produkcijski WfM sistem je značilno, da izvaja vitalne

68 poslovne procese z veliko poslovno vrednostjo in velika pogostost izvajanja teh procesov. Produkcijski potek dela je ponavadi povezan z obstoječimi zalednimi aplikacijami. Zaradi svoje pomembne vloge so aplikacije in WfMS ponavadi implementirani kot transakcijski programi, za katere je tudi značilno, da morajo biti stalno razpoložljivi in robustni. WMQWF potrebuje za svoje delovanje bazo podatkov in vmesno programje za povezovanje z zalednimi aplikacijami. Vmesno programje, ki ga potrebuje je WebSphere MQ in opcijsko tudi WebSphere Business Integration Message Broker in WebSphere Application Server. Temelječ na arhitekturi SOA, podpira arhitekturo POA. Primeren je za avtomatizacijo poslovnih procesov, ki vsebujejo tudi ročne aktivnosti. IBM WebSphere Business Integration Message Broker 32 IBM WebSphere Business Integration Message Broker V5 je integracijski posrednik. Podatki, ki so usmerjeni k njemu, se na podlagi predhodno določenih pravil transformirajo, oplemenitijo in usmerijo. Trasformacija: katerikoli format podatkov se lahko pretvori v katerikoli drugi. Na primer 3270 terminal se lahko pretvori v XML, COBOL copybook se lahko pretvori v format, kjer so polja ločena s podpičji itn. Ponavadi je potrebno zgraditi meta-podatkovno struktura, na podlagi katere se podatke razčleni. XML meta-podatakovne strukture ni potrebno definirati. Oplemenitenje: podatki, ki potujejo skozi WBI Message Broker se lahko medtem oplemenitijo. Na primer podatki iz baze podatkov se lahko dodajo. Usmerjanje: določijo se lahko pravila prehoda. Na primer, če je v določenem polju v podatkovni strukturi določen podatek, potem morajo biti podatki transformirani določen način ter biti dostavljeni določeni aplikaciji. V primeru napake pa se podatki shranijo. Hkrati se pošlje obvestilo operaterju po elektronski pošti. IBM WebSphere MQ 33 IBM WebSphere MQ (WMQ) med seboj povezuje aplikacije. Povezuje pravzaprav skoraj vse z vsem z namenom oblikovanja učinkovite organizacije ter z namenom racionalizacije procesov in skrajševanja časa prihoda na tržišče. Zagotavlja odprto, nadgradljivo in zmogljivo informacijsko orodje, ki združuje neenake aplikacije, ki delujejo na različnih računalniških platformah. WMQ skrajšuje čas, ki je potreben za integracijo aplikacij v različnih sistemih. Podjetja lahko na ta način ohranijo že obstoječe aplikacije, hkrati pa lahko hitreje uvajajo in razvijajo nove aplikacije. Aplikacija komunicirajo z uporabo WMQ programskega vmesnika, ki programerjem prihrani težave, s katerimi se sicer srečujejo zaradi zapletenosti različnih operacijskih sistemov in mrežnih protokolov. Programerji se tako lahko osredotočijo predvsem na poslovno logiko. Lastnosti WMQ so naslednje: ohlapna povezava aplikacij (asinhrona), povezava aplikacij znotraj in zunaj podjetja,

69 zagotovljena enkratna in samo enkratna dostava podatkov - celo v primeru izpada aplikacij, računalniških sistemov ali omrežja, podpira 35 najpomembnejših operacijskih sistemov. IBM WebSphere Application Server 34 IBM WebSphere Application Server (WAS) je spletni aplikacijski strežnik, zasnovan na tehnologiji Java po najnovejših J2EE V1.4 standardih, ki združuje poslovne informacije in transakcije s svetom elektronskega poslovanja. Bogato okolje za razvoj in uvajanje spletnih aplikacij za elektronsko poslovanje obsega širok nabor programskih storitev za management transakcij, varnost, povezovanje v gruče, hitrost, zmogljivost, razpoložljivost, povezljivost in razširljivost Nadzorovanje in management IBM WebSphere Business Integration Monitor 35 The WebSphere Business Integration Monitor beleži podatke o izvajanju procesa v izvajalnem okolju (WMQWF) ter generira poročila o tem izvajanju. Je napisan v javi ter se lahko namesti na katerikoli J2EE omogočen spletni aplikacijski strežnik. Sestavljen je iz dveh komponent: poslovne in komponente za spremljanje izvajanja delovnega toka. Poslovna komponenta omogoča naslednje: izdelava podrobnih poročil o zgodovini izvajanja poslovnega procesa, iz katerih so razvidne tudi poslovne zmogljivosti procesa, poleg standardni mer (stroški, čas trajanja ipd.) tudi možnost določitve lastnih mer za nadzorovanje. Komponenta za spremljanje izvajanja delovnega toka omogoča naslednje: spremljanje procesa in njegovih poslovnih zmogljivosti v realnem času, pregled primerov procesa in aktivnosti v procesu, možnost administracije primerov procesa in korektivnih ukrepov, izvoz/uvoz podatkov o izvajanju procesa v/iz WBI Modeler

70 3.2. Opis primera poslovnega procesa Predstavitev podjetja JPK d.d. Dejavnost podjetja uvrščamo v panogo Predelovalne dejavnosti kovine in kovinski izdelki. Osnovni program podjetja JPK d.d. je proizvodnja kakovostnih koles za svetovni trg. Podjetje izdeluje gorska, cestna in otroška kolesa, tako za vrhunske športnike kot tudi za rekreativne namena. Kolesa prodajajo na prostem trgu, Prav tako pa tudi znanim kupcem, ki jih pre-prodajajo pod svojo blagovno znamko (na primer Lufthansa, Mercedes-Benz ipd.). Glavni razlikovalni konkurenčni faktor so okvirji tekmovalnih gorskih in cestnih koles najvišje kakovosti, ki jih izdelujejo iz umetnih mas ojačanih z ogljikovimi vlakni, aluminija oplemenitenega z raznimi legurami, keramike in titana. V ta namen ima podjetje lasten laboratorij za razvoj in preizkušanje materialov. Ostale polizdelke 36, potrebne za izdelavo koles kupujejo pri dobaviteljih. Podjetje deluje kot delniška družba. Vodi jo uprava, delničarje zastopa nadzorni svet. Osnovno načelo vodstva je najvišja kakovost koles ob najnižjih možnih stroških ter konkurenčnih cenah. Podjetje ima 500 zaposlenih. Delo je organizirano v petih oddelkih: komerciala, razvoj, proizvodnja, finančno-računovodski in splošno-kadrovski oddelek (slika 19). Slika 19: Organizacijska shema podjetja JPK d.d.. Vodstvo podjetja se zaveda, da je potrebno prenoviti in informatizirati celotno poslovanje podjetja, če želijo obdržati in celo povečati konkurenčno prednost, ki jo trenutno imajo. Zavedajo se, da je prenova poslovnih procesov naporen postopek, ki se pravzaprav nikoli ne konča, zato so se odločili, da bodo prenovo izpeljali v večih fazah. Za prvo fazo prenove bodo vzeli nek poslovni proces, ki ga bo relativno enostavno prenoviti in informatizirati ob čimvečji možni stopnji izboljšanja. Za to bodo uporabili koncept managementa poslovnih procesov. S tem bodo preizkusili ta koncept, ki je trenutno zelo aktualen, v praksi ter ugotovili njegovo primernost za uporabo pri prenovi preostalih poslovnih procesov. Za identifikacjo takšnega procesa je vodstvo določilo in pooblastilo BPM tim. BPM tim je po opravljenih intervjujih prišel do sklepa, da je poslovni proces, ki ustreza merilom vodstva proces nabavljanja, pravzaprav del procesa nabavljanja. 36 Polizdelek ali sestavni del je izdelek za nadaljno vgradnjo. Tipičen polizdelek je na primer vijak. 58

71 Proces nabavljanja v podjetju JPK d.o.o. je sestavljen iz treh pod-procesov: 1. planiranja nabave, 2. naročanja polizdelkov ter 3. prevzema polizdelkov. Po mnenju BPM tima bi lahko prenova pod-procesa naročanja polizdelkov prinesla vrnitev investicije v najkrajšem možnem času, hkrati pa je ta pod-proces dovolj enostaven za prenovo. Vodstvo je potrdilo ugotovitve BPM tima. Izbrani pod-proces so na kratko poimenovali proces naročanja polizdelkov. Proces naročanja polizdelkov je na sliki 20 obkrožen s črtkano črto. To je tisti del procesa nabavljanja, ki skrbi za komunikacijo z dobavitelji. Skrbi, da je zahteva za polizdelke poslana dobavitelju, sprejema odgovore od dobaviteljev in glede na te odgovore pošilja naročilnice za dobavo ali poišče nadomestne dobavitelje. Slika 20: Proces naročanja polizdelkov v širšem kontekstu podjetja JPK d.d.. Vir: Kovačič, Opis procesa naročanja polizdelkov Komercialni oddelek sporoči proizvodnemu oddelku tip in količino proizvodov - koles. Planer proizvodnje vnese željene količine polizdelkov v ERP sistem. V ERP sistemu je implementiran modul, ki skrbi za skladiščno poslovanje. Planer proizvodnje nato vsak dan ob koncu delovnega dne ročno sproži proceduro, ki preveri trenutno razpoložljivost željenih odvečnih polizdelkov v skladišču, odšteje polizdelke od naročila, če so nekateri že v skladišču, nato pa izpiše listo polizdelkov, ki jih proizvodnja želi. Ta lista se po interni pošti (kurirju) pošlje kot interna naročilnica v komercialni oddelek nabave. Na interni naročilnici so napisani nazivi polizdelkov, njihove specifikacije, interne šifre ter količine, ki jih potrebuje oddelek proizvodnje ali razvoja. Nabavni uslužbenec v nabavni službi primerja postavke na naročilnici z dobavitelji ter naredi razpored, s katerim določi, kateri dobavitelj bo dobavil določen polizdelek. Ima seznam dobaviteljev, ki so rangirani po zanesljivosti in kakovosti izdelkov ter zanesljivosti in hitrosti dostave naročenega blaga. Za vsakega dobavitelja nato izpolni obrazec zahteva za dobavo, kamor napiše naziv in šifro polizdelka, dobaviteljevo šifro polizdelka, če jo ima, in zahtevano količino. Glede na dobavitelja tudi določi pot pošiljanja: faks ali elektronska izmenjava podatkov. Kopija obrazca zahteva za dobavo nato potuje v finančno-računovodski oddelek, ki opravlja storitev pošiljanja zahtevkov in naročilnic dobaviteljem za nabavno službo. Tajnica v finančno-računovodskem 59

72 oddelku nato faksira dokumente dobaviteljem. Dobaviteljev, s katerimi se komunicira po faksu, je 80%. V ostalih 20% mora tajnica pretipkati podatke v EDI aplikacijo. EDI aplikacija je preko X.25 omrežja povezana s ponudnikom EDIFact storitve. Le-ta nato pošlje sporočilo naslovniku (dobavitelju). Dobavitelj ima do tri delovne dni časa, da odgovori na zahtevo za dobavo, po enaki komunikacijski poti kot jo je dobil. Možne so štiri vrste odgovorov na zahtevo: 1. potrdi jo v celoti (v 70% primerov), 2. zavrne jo v celoti (v 5% primerov), 3. delno jo potrdi (v 20% primerov), 4. zgodi se izjema (v 5% primerov). Odgovore od dobaviteljev preko faksa sprejme finančno-računovodski oddelek, ki jih nato posreduje oddelku nabave. Odgovore od dobaviteljev preko EDI sprejme oddelek nabave, ki jih istočasno natisne na papir. Reakcije na sprejet odgovor na zahtevo za dobavo so lahko sledeče: 1. V primeru, da je zahteva v celoti potrjena, pošlje dobavitelju naročilnico po enaki poti kot zahtevo za dobavo. Hkrati posreduje podatke o naročenih polizdelkih oddelku proizvodnje, ki jih vnese v ERP sistem. 2. V primeru, da je zahteva v celoti zavrnjena, poišče po seznamu dobavitelja, ki je naslednji po rangu. Celoten proces pošiljanja in sprejemanja zahteve in odgovora se ponovi. 3. V primeru, da je zahteva delno potrjena, pošlje dobavitelju naročilnico po enaki poti kot zahtevo za dobavo ter posreduje podatke o naročenih polizdelkih oddelku proizvodnje, ki jih nato vnese v ERP sistem. Polizdelkov, ki so potrjeni, je v povprečju 90%, za ostalih 10% polizdelkov je pa potrebno poiskati nadomestnega dobavitelja, ki je naslednji po rangu, in ponoviti celotni proces. 4. V primeru izjeme oddlek nabave preuči kaj se dogaja. V primeru EDI komunikacijske poti je trenutno definirana samo ena izjema, namreč če dobavitelj ne odgovori v dogovorjenem roku. V primeru komunikacije preko faksa sta definirani dve izjemi. Prva, nečitljiv faks, se zgodi v 10% primerov. V tem primeru se poskuša ugotoviti za katerega dobavitelja gre, nato se ga pokliče in prosi za ponovno pošiljanje faksa. Če se ne da ugotoviti od katerega dobavitelja je prišel nečitljiv faks, potem postane ta zadeva druga izjema. Druga izjema, ki se zgodi v približno 90% je, da podjetje ne dobi odgovora na zahtevo. V tem primeru je potrebno ponoviti postopek pri dobavitelju, ki je naslednji po rangu in ponoviti celotni proces. Trenutno podjetje posluje z dobavitelji preko faksov in elektronske izmenjave podatkov. Poslujejo preko mreže X.25 ter EDIFact formata podatkov. Zaradi velikih stroškov EDI ob uporabi X.25, želijo preiti na elektronsko poslovanje med podjetji preko spleta, in sicer na ebxml (angl: e-business XML, ebxml). Opis dela in delovnih nalog za udeležence v procesu naročanja polizdelkov: 1. Direktor nabavnega oddelka: pregled in potrjevanje naročilnic za dobavo. 2. Nabavni uslužbenec v oddelku nabave: primerjanje postavk na internih naročilnicah s polizdelki, ki jih dobavitelji ponujajo, razpored teh postavk po dobaviteljih, glede na rang dobavitelja in način komunikacije, izpisovanje zahtev za dobavo z naslovom in dobaviteljevimi kontakti ter arhiviranje zahteve, 60

73 pošiljanje zahteve za dobavo za tiste dobavitelje, katerih komunikacijska pot je faks, finančnoračunovodskemu oddelku, ki skrbi za oddajo in sprejem faksov, predaja zahteve za dobavo za tiste dobavitelje, katerih komunikacijska pot je EDI, naslednjemu nabavnemu uslužbencu, vnašanje in pošiljanje zahteve za dobavo za tiste dobavitelje, katerih komunikacijska pot je EDI, v EDI aplikacijo, izpis odgovora na zahtevo prejetega po EDI kanalu, sprejem obeh odgovorov po faksu od finančno-računovodskega oddelka in po EDI od drugega nabavnega uslužbenca, primerjava kaj je bilo zahtevano ter kaj lahko dobavitelj dobavi, vnašanje naročilnice v ERP sistem, tiskanje naročilnice ter oddaja v interno pošto za direktorja nabave v odobritev naročilnice, Ugotavljanje kateri polizdelki so potrjeni in kateri ne, procesiranje izjem, klicanje dobavitelja v primeru, da faks ni čitljiv. 3. Tajnica v finančno-računovodskem oddelku: pošiljanje in sprejemanje faksov (zahtev za dobavo, naročilnic). 4. Planer proizvodnje: priprava liste polizdelkov potrebnih za proizvodnjo. Viri in stroški virov udeleženih pri procesu naročanja polizdelkov so prikazani v tabeli 9. Stroški uslužbencev udeleženih v procesu naročanja polizdelkov so celotni celoletni bruto stroški. Vključujejo izobraževanje. Ne vključujejo nadurnega dela, ki je prikazano v posebnem stolpcu v tabeli 9. Stroški za ERP in EDI sistema so ocenjeni letni stroški vzdrževanja. Uporaba EDI storitve se obračunava po količini prenesenih podatkov, ki se ocenjujejo na 5 EUR na pošiljanje enega EDI dokumenta. Stroški infrastrukture so stroški na zaposlenega in vključujejo vsa delovna sredstva kot so na primer delovno mesto, oprema delovnega mesta, osebni računalnik, amortizacija ipd.. Pri vsaki aktivnosti se porabljajo določeni drugi viri kot so na primer papir, pisala ipd.. Ti so ovrednoteni na 1 EUR na enoto dela na zaposlenega. Tabela 9: Viri in stroški virov udeleženih pri kot-je procesu naročanja polizdelkov. Ime vira Strošek vira [EUR / leto] Strošek nadure vira [EUR / leto] Strošek na enoto dela [EUR] Direktor nabave Nabavni uslužbenec Planer proizvodnje Tajnica ERP sistem EDI sistem Infrastruktura

74 Tabela 10: Aktivnosti kot-je procesa naročanja polizdelkov. Aktivnost T1 [h] T2 [h] Del. Mesto (DM) Število DM Oddelek Izvedba Dodatni viri Pregled in tiskanje zahteve Ročna, Infrastruktura, 2 1,5 Planer proizvodnje 1 Proizvodnja za dobavo iz ERP sistema Avtomatska ERP sistem Izbiranje dobavitelja in Nabavni 2,5 2 načina pošiljanja uslužbenec 3 Nabava Ročna Infrastruktura Pošiljanje dokumenta Finančnoračunovodski 0,25 0,1 Tajnica 1 dobavitelju Ročna Infrastruktura Vnašanje dokumenta v EDI Nabavni Ročna, Infrastruktura, 1 0,75 1 Nabava sistem in pošiljanje uslužbenec Avtomatska EDI sistem Sprejemanje EDI odgovora Nabavni Avtomatska, 0,5 0,25 1 Nabava Infrastruktura in tiskanje na papir uslužbenec Ročna Zbiranje in posredovanje Finančno- 0,25 0,1 Tajnica 1 odgovora nabavni službi računovodski Ročna Infrastruktura Pregledovanje odgovora in Nabavni 0,5 0,25 primerjava z zahtevo uslužbenec 1 Nabava Ročna Infrastruktura Ugotavljanje kateri Nabavni 1 0,5 polizdelki so potrjeni uslužbenec 1 Nabava Ročna Infrastruktura Vnašanje podatkov v ERP Nabavni Infrastruktura, 1 0,75 1 Nabava Ročna in tiskanje naročilnice uslužbenec ERP sistem Odobravanje naročilnice 8 0,5 Direktor nabave 1 Nabava Ročna Infrastruktura Procesiranje izjeme 1,5 1 Nabavni uslužbenec 1 Nabava Ročna Infrastruktura Iskanje nadomestnega Nabavni 3 2,5 dobavitelja uslužbenec 1 Nabava Ročna Infrastruktura Klicanje dobavitelja za Nabavni 1 0,25 ponovno pošiljanje faksa uslužbenec 1 Nabava Ročna Infrastruktura Vnašanje potrditve o Nabavni 1 0,25 dobavi v ERP sistem uslužbenec 1 Nabava Ročna Infrastruktura Legenda: T1 [h]... čas trajanja aktivnosti (bruto) T2 [h]... dejanski (neto) čas izvajanja aktivnosti Cilji prenove procesa naročanja polizdelkov so določeni s strani vodstva. Prikazani so na sliki 21. Cilja prenove procesa naročanja polizdelkov sta dva: 1. Izboljšati in poenostaviti proces naročanja polizdelkov. 2. Izboljšati partnerske odnose z dobavitelji. Vodstvo se je odločilo, da bo za dosego ciljev prenove digitaliziralo proces ter uvedlo klicni center za procesiranje izjem. Z uvedbo JIT, internetnih in tehnologij IT, želijo doseči naslednje cilje zmogljivosti (angl. Performance): Razpolovitev časa in stroškov procesa naročanja polizdelkov. Ugotavljanje uspešnosti cilja je zagotovljeno s primerjavo stroškov in časa izvajanja procesa pred in po uvedbi digitalnega procesa. Povečanje zadovoljstva dobaviteljev za vsaj 3% letno. Ugotavljanje uspešnosti cilja z enkrat letnim anketiranjem dobaviteljev ter primerjava z anketami iz prejšnjih let. Zmanjšanje zalog za vsaj 25% z uvedbo hitrejše komunikacijske poti (internet), informacijskih tehnologij ter JIT proizvodnje. Ugotavljanje uspešnosti cilja je zagotovljeno s primerjavo celotne vrednosti zalog na skladišču pred in po uvedbi zgoraj omenjenih odločitev. 62

75 Slika 21: Cilji prenove procesa naročanja polizdelkov. Cilji prenove procesa 1. Izboljšati in poenostaviti proces. 2. Izboljšati partnerske odnose z dobavitelji polizdelkov Prioriteta visoka visoka Cilji zmogljivosti procesa 1. Razpolovitev časa potrebnega za izvajanje posameznega primera procesa. 2. Razpolovitev stroškov potrebnih za izvajanje primera procesa. 3. Povečanje zadovoljstva dobaviteljev za vsaj 3% letno. 4. Zmanjšanje zalog za vsaj 25% z uvedbo hitrejše komunikacijske poti JIT proizvodnje. Merila Povprečni čas posameznih izvajanj primerov procesa. Najdaljši in najkrajši čas izvajanja primera procesa. Stroški posameznih primerov procesa. Povprečni stroški primerov procesa. Enkrat letno anketiranje dobaviteljev ter primerjava z anketo iz prejšnjih let. Celotna vrednost zalog na skladišču pred uvedbo. Odločitve vodstva 1. Uporaba informacijski in internetnih tehnologij. 2. Uvedba klicnega centra za procesiranje izjem. 3. Uvedba JIT proizvodnje. Natančni popis aktivnosti pri procesu naročanja polizdelkov je prikazan v tabeli 10. Tim BPM je popisal vse aktivnosti, ki se trenutno izvajajo pri tem procesu ter njihove glavne atribute kot so čas trajanja, kdo izvaja aktivnost, število izvajalcev, v katerem oddelku se aktivnost izvaja, kako se izvaja ali je mogoče avtomatizirana ali se izvaja ročno, ter dodatni viri, ki sodelujejo pri izvajanju procesa. Meje procesa naročanja polizdelkov predstavljajo sprožilniki in izhodi procesa ter uporabniki, oddelki in zunanje entitete, ki so udeleženi v izvajanju procesa. Navedene so na sliki 22. Slika 22: Meje kot-je procesa naročanja polizdelkov. 63

76 SWOT analiza procesa naročanja polizdelkov odkrije prednosti, pomanjkljivosti, kje so priložnosti za izboljšanje procesa ter kaj lahko proces ogrozi. SWOT analiza je prikazana v tabeli 11. Tabela 11: SWOT analiza kot-je procesa naročanja polizdelkov. Prednosti procesa: 1. izdelki odlične kakovosti, 2. osebni odnos z dobavitelji, 3. utečen proces tako v podjetju kot pri dobaviteljih. Priložnosti procesa: 1. izločitev nepotrebnega ročnega dela, 2. izločitev nepotrebnih dokumentov v papirnati obliki, 3. višja stopnja avtomatizacije procesa, 4. elektronska izmenjava podatkov ter s tem znižanje stroškov procesa tako v podjetju kot pri dobaviteljih, 5. možnost oddajanja in sprejemanja elektronskih dokumentov 24. ur na dan vsak dan (24/7). SWOT analiza procesa naročanja polizdelkov Pomanjkljivosti procesa: 1. dolgotrajnost izvajanja posameznega primera, 2. preveč ročnih aktivnosti (tiskanje, sortiranje, pretipkavanje iz sistema v sistem ipd.), 3. veliko napak pri naročanju, 4. pretok pošte med oddelki je počasen, 5. veliki stroški procesa. Grožnje procesu: 1. vzdrževanje osebnega odnosa z dobavitelji, 2. izobraževanje zaposlenih glede novega procesa, 3. z uvedbo avtomatizacije procesa se bo mogoče pojavil presežek zaposlenih, 4. nesprejemanje novih načinov izmenjave podatkov s strani dobaviteljev, 5. visoki stroški uvedbe novih tehnologij IT za podporo digitaliziranemu procesu (strojna in programska oprema, izobraževanja ipd.). Zaključek BPM tima je, da proces naročanja polizdelkov traja predolgo časa, da preveč stane ter da imajo na račun tega tudi večje stroške skladiščenja polizdelkov. Predlagajo prenovo procesa, ki bo naredila proces stroškovno učinkovitejši, zmogljivejši, prilagodljivejši, enostavnejši, nedvoumen ter lažje obvladljiv. S tem želijo tudi izboljšati odnose z dobavitelji in preiti na nove, sodobne in stroškovno učinkovitejše načine komunikacije z njimi. Vodstvu so predlagali naslednji plan izvedbe projekta prenove poslovnega procesa naročanja polizdelkov: Faza 1: Identifikacija Identifikacija poslovnega procesa in zbiranje osnovnih podatkov o njem. Ta faza je že bila izvedena. V njej je tim BPR opisal proces, določil cilje prenove procesa, določil meje procesa ter naredil SWOT analizo. Faza 2: Snovanje Modeliranje, simuliranje, analiza in primerjava kot-je in naj-bo modelov. Potrebno je načrtovati preureditev procesa s stališča zaposlenih in samega poslovanja. Potrebna je tudi odločitev o nakupu programske opreme za integracijo aplikacij ter odločitev o nakupu BPM sistema. Faza 3: Postavitev Postavitev modela v izvajalno okolje. Potrebno je izvesti namestitev programske opreme, izobraževanje zaposlenih, ki bodo delali s to opremo ter integracijo aplikacij. Potrebno je tudi vse udeležence v procesu izobraziti o delovanju novega procesa. Faza 4: Izvajanje in nadzorovanje Odpravljanje po-porodnih težav. Nadzorovanje in opazovanje procesa v izvajanju. Podatki o 64

77 izvajanju se shranjujejo za poznejšo analizo in ugotavljanje ozkih grl, dejanskega časa izvajanja, stroškov ipd.. Faza 5: Analiziranje in optimaliziranje Na podlagi podatkov izvajanja procesa in analiz na teh podatkih se po potrebi izvede ponovno snovanje procesa. BPM tim je predstavil stroškovno analizo (tabela 12) in terminski plan projekta (slika 23). Celoten projekt je razdelil na pet faz. Vsaka faza ima dve ali več podfaz. Ocenil je potrebne vire (človeške in denarne) ter trajanje projekta. Njegova ocena za izvedbo projekta je 12 mesecev ob planiranih stroških ,00 EUR. Poleg tega je tim podal oceno stroškov za vsako nadaljnje leto vzdrževanja BPM sistema. Ti stroški so ,00 EUR. Tabela 12: Aktivnosti posameznih faza projekta prenove procesa naročanja polizdelkov in stroškovna analiza. Faza Trajanje [v mesecih] Obseg [v človek mesecih] Planirani stroški [v 1000 EUR] 1. Identifikacija A. Načrtovanje in organiziranje projekta (projekt. vodja) B. Identifikacija, intervjuji in izbira procesa Snovanje A. Podrobni procesni modeli ( kot-je, naj-bo ) B. Širše načrtovanje informatike (baza podatkov ipd.) C. Načrtovanje preureditve in avtomatizacije procesa 0,5 1 1,5 D. Izbira programske in strojne opreme 0,5 1 1,5 3. Postavitev A. Nakup programske (licence) in strojne opreme B. Nakup storitev za postavitev C. Integracija aplikacij D. Postavitev procesa v izvajanje 0,5 1 1,5 E. Izobraževanje udeležencev procesa Izvajanje in nadzorovanje A. Odpravljanje porodnih težav B. Izvajanje nadzora 1 1 mesec/leto 3 5. Analiziranje in optimaliziranje A. Analiziranje zajetih podatkov 1 1 mesec/leto 3 B. Po potrebi ponovno snovanje procesa 1 2 mesec/leto 6 - Skupaj: 283,5 Nepredvideni stroški cca. 5% vrednosti projekta ,5 Planirani celotni stroški: 300 BPM tim je poudaril, da bodo stroški za uvajanje BPM za prvi proces precej višji kot za uvajanje nadaljnjih procesov. Razloga sta v nakupu programske opreme in v krivulji učenja zaposlenih. Vodstvo podjetja JPK d.d. se je odločilo, da projekt nadaljujejo do vključno faze 2D, kjer se bo dalo iz modela procesa narediti študijo povračila investicije (angl. Return On Investment, ROI). Do te faze je tudi odobrilo predlagane skupne stroške, ter pooblastilo tim BPM za aktivnosti, povezane z izvedbo projekta. 65

78 Slika 23: Terminski plan izvedbe projekta prenove procesa naročanja polizdelkov Modeliranje in analiziranje procesa naročanja polizdelkov Model obstoječega stanja "kot-je" procesa naročanja polizdelkov Kot-je proces naročanja polizdelkov je modeliran z orodjem za modeliranje, ki se imenuje IBM WebSphere Business Process Modeler Workbench V4.2.4, oz. na kratko WBI Modeler. Model vsebuje vse potrebne informacije kot so čas in stroški izvajanja aktivnosti, potrebni viri za izvajanje ipd.. Model procesa se imenuje JPK.org. Kot dodatek temu poglavju je dosegljiv na CD-ROM mediju, priloženem k temu magistrskemu delu. Model procesa je relativno enostaven. Vsebuje en osnovni proces (slika 24), to je proces naročanja polizdelkov (AsIs N1 Narocanje polizdelkov), ter tri pod-procese: 1. Zahteva za dobavo in odgovor od dobavitelja (AsIs N2 Zahteva in odgovor od dob.), 2. Naročilnica, zahteva za dobavo ali izjema (AsIs N2 Narocilnica,zahteva,izjema), 3. Pošiljanje naročilnice (AsIs N2 Posiljanje narocilnice). Slika 24: Kot-je proces naročanja polizdelkov na najvišjem nivoju. Celoten, razvit proces, je prikazan na sliki 25, ki je zaradi prostorske stiske razdeljen na dva dela. Povečan proces je na voljo v prilogi poglavja 6.4. Kot-je model procesa naročanja polizdelkov na strani 110. Tam so tudi prikazane vse možne poti skozi proces (angl. Cases). 66

79 V procesu je, matematično gledano, neskončno število možnih poti, saj je v samem procesu zanka, ki ponovi celotni proces naročanja polizdelkov v primeru, da je odgovor na zahtevek negativen, delno uspešen ali pa dobavitelj sploh ne vrne odgovora. Simulacija modela procesa s takšno povratno zanko je možna, vendar lahko ugotovimo, da je precej kompleksna, dolgotrajna in nerazumljiva. Razlog je v orodju, ki ni primerno za takšno simulacijo. Zaradi tega razloga bomo proces ustavili, kadar bi se moral vrniti na začetek. Iz tabele 13 lahko vidimo, da je primerov procesov, ki gredo v drugo ponovitev 30%. Od tega jih gre v tretjo ponovitev zopet 30% od 30% itn. S seštevanjem teh procentov ugotovimo, da je število primerov procesov, ki se morajo ponoviti enkrat ali večkrat približno 42,85%. Število dejanskih ponovitev, ki jih želimo simulirati, moramo torej povečati za 42,85%. S tem bomo izničili efekt povratne zanke. Aktivnosti, ki nastopajo v procesu, so zbrane v tabeli 10. V tabeli 13 so zbrane odločitvene točke ter možne izbire procesa in njihove verjetnosti pojava. Tabela 13: Odločitvene točke kot-je procesa naročanja polizdelkov, možne izbire in njihove verjetnosti pojava. Odločitev Izbira Verjetnost [%] Način pošiljanja? EDI 20 Način pošiljanja? Faks 80 Zahtevana dobava? V celoti nepotrjena 5 Zahtevana dobava? Izjema 5 Zahtevana dobava? Delno potrjena 20 Zahtevana dobava? V celoti potrjena 70 Vrsta izjeme? Nečitljiv faks 10 Vrsta izjeme? Ni odgovora 90 Slika 25: Razvit kot-je model procesa naročanja polizdelkov Analiziranje "kot-je" procesa naročanja polizdelkov Analiza kot-je procesa nam omogoča razumeti kakovost procesa in njegova ozka grla. Pomaga nam tudi najti področja, kjer je proces slab, ter področja, ki so najbolj kritična in potrebna prenove. Analiza zmožnosti kot-je procesa omogoča kasnejšo primerjavo variant naj-bo procesa. 67

80 Že v fazi modeliranja se lahko identificira probleme procesa. Ti problemi kažejo na težave v toku informacij med posameznimi aktivnostmi, težave v distribuciji in dostopanju do podatkov med posameznimi oddelki in med podjetjem ter dobavitelji. Če sledimo tem težavam do njihovih izvorov, ugotovimo, da podjetje nima enovitega informacijskega sistema, ki bi omogočal enostavno izmenjavo podatkov v elektronski obliki, ampak so informacije še vedno na papirju. To se lepo pokaže v primeru, ko je potrebno dobavitelju poslati faks. Analiziranje procesa in vseh možnih poti procesa Tabela 14: Možne poti skozi kot-je proces naročanja polizdelkov in njihove verjetnosti pojava. Primer poti Procent verjetnosti [%] Način pošiljanja? Zahtevana dobava? Vrsta izjeme? Število aktivnosti Št. zunanjih aktivnosti 1 56,00 Faks V celoti potrjena ,00 Faks Delno potrjena ,00 EDI V celoti potrjena ,00 Faks V celoti nepotrjena ,00 EDI Delno potrjena ,60 Faks Izjema Ni odgovora ,00 EDI Izjema Ni odgovora ,00 EDI V celoti nepotrjena ,40 Faks Izjema Nečitljiv faks 7 1 Skupaj: 100% Kombinacija odločitev in možnosti v procesu tvori množico različnih možnih poti izvedbe primera procesa. Z analizo raziščemo obnašanje procesa z upoštevanjem vseh teh možnih variant poti procesa. Primeri poti so med sabo zelo različni. Vsak ima svojo verjetnost pojava. Vse možne poti skozi proces naročanja polizdelkov ter njihove verjetnosti pojava so prikazane v tabeli 14. Analiziranje posameznih primerov in povprečnih utežnostnih faktorjev Primer poti Tabela 15: Časovna in stroškovna analiza kot-je proces naročanja polizdelkov po metodi povprečnih utežnostih faktorjev. Procent verjetnosti Čas trajanja procesa [dan] Čas zunanjih aktivnosti [dan] Čas prenosa med akt. [dan] Čas čakanja Neto delovni čas [dan] Minimalni čas obhoda [dan] Čas enega obhoda [dan] Strošek virov [%] [dan] [EUR] 1 56,00 9,47 6,00 1,53 1,22 0,71 10,08 11,16 186, ,00 9,63 6,00 1,56 1,29 0,78 10,11 11,21 252, ,00 9,06 6,00 0,88 1,28 0,91 9,26 11,02 249,50 4 4,00 4,84 3,00 0,78 0,25 0,81 4,20 4,28 192,70 5 4,00 9,22 6,00 0,91 1,34 0,97 9,29 11,07 316,16 6 3,60 5,06 3,00 0,81 0,31 0,94 4,25 7,02 215,25 7 1,00 4,75 3,00 0,38 0,34 1,03 4,14 4,25 243,70 8 1,00 4,53 3,00 0,34 0,28 0,91 4,08 4,18 221,15 9 0,40 4,81 3,00 0,81 0,34 0,66 4,16 4,27 166,76 Utežnostno povprečje 100% 8,97 5,70 1,34 1,15 0,78 9,35 10,55 213,03 Posamezen primer lahko izoliramo in ga analiziramo posebej. Primer, ki ga izberemo za podrobno analizo, je lahko tisti, ki se pojavlja največkrat ali tisti, ki največ stane ipd.. Lahko tudi analiziramo kombinacijo 68

81 primerov skupaj in rezultate združimo. Analizo kombinacije primerov lahko naredimo z metodo povprečnih utežnostnih faktorjev, ki upošteva dejstvo, da so različni primeri vredni različno, glede na pogostost pojavljanja. Torej imajo primeri, ki imajo večjo verjetnost pojavljanja, večji utežnostni faktor. Čas in strošek posameznega primera sta pomnožena s pogostostjo pojavljanja (procentom). Povprečni utežnostni faktor procesa dobimo s seštevanjem utežnostnih faktorjev posameznih primerov. V našem primeru je možnih devet primerov poti. Rezultati so prikazani v tabeli 15. Grafični prikazi posameznih primerov poti so prikazani v prilogi poglavja 6.3. Primeri poti kot-je procesa naročanja na strani 111. Pojasnilo časov uporabljenih v tabeli 15: Čas trajanja procesa: Ocena števila delovnih ur potrebnih za izvršitev enega primera poslovnega procesa. Čas procesa je izračunan iz trajanja aktivnosti na kritični poti. Je seštevek časov izvajanj aktivnosti, časa izvajanja zunanjih aktivnosti in časa prenosa med aktivnostmi. Ne upošteva delovnika, ampak predvideva, da so viri neprekinjeno na razpolago. Čas zunanjih aktivnosti: Ocena števila delovnioh ur potrebnih za izvršitev aktivnosti, ki jo izvršuje zunanja entiteta. Te aktivnoti so del poslovnega procesa, vendar organizacija za njihovo izvrševanje ne potrebuje svojih virov. Čas prenosa med aktivnostmi: Ocena celotnega časa prenosa primera procesa med aktivnostmi. Čas čakanja: Primer procesa se začne, vendar je uslužbenec trenutno še zaposlen z drugimi aktivnostmi. To je ocena časa čakanja pri izvrševanju enega primera poslovnega procesa. Čas čakanja je odštevek delovnega časa od pretečenega časa. Neto delovni čas: Ocena števila ur potrebnih za izvršitev enega primera procesa. Minimalni čas obhoda: Ocena minimalnega trajanja primera procesa startanega na določen datum. Pri izračunu se upošteva delovnik. Čas enega obhoda: Povprečna ocena trajanja primera procesa, startanega na določen datum in čas. Pri izračunu se upošteva delovnik. Analiziranje različnih poti nam pomaga najti predvsem tiste procese, ki stanejo največ in trajajo najdlje. Iz tabele 14 in 15 lahko razberemo sledeče: 1. Primer poti 1 (naročanje polizdelkov preko faksa, ki je v celoti potrjeno) vsebuje 12 aktivnosti, od tega 2 zunanji. Pogostost pojava je 56%, povprečno časovno trajanje posameznega primera poti je 11,16 koledarskih dni oz. 9,47 delovnih dni. Od tega je 6 delovnih dni namenjenih čakanju na dobaviteljev odgovor; 1,53 dni poteče, da se dokumenti prenesejo iz oddelka v oddelek; sam delovni čas porabljen za proces je 0,71 dni; čas čakanja na obdelavo je 1,22 dni. Celotni strošek virov, porabljenih v tem primeru, je 186,14 EUR. 2. Primer poti 3 je enak primeru 1, samo da izmenjava dokumentov poteka preko EDI. Vidimo, da je strošek virov precej večji (249,50 EUR) kot pri izmenjavi dokumentov preko faksa v primeru 1. To je razumljivo, saj je za EDI izmenjavo potrebno več virov, kot so EDI aplikacija, EDI komunikacija, osebni računalnik ipd.. 3. Največ, 316,16 EUR, stane primer poti 5, ki je delno naročilo preko EDI. Verjetnost pojava je 4%; ima pa tudi eno izmed najdaljših časovnih trajanj izvedbe procesa, to je 11,07 koledarskih dni. 69

82 Analiziranje povprečnih utežnostnih faktorjev nam pove kako se proces obnaša kot celota. V našem primeru (tabela 15) nam pove naslednje: 1. eno izvajanje procesa v povprečju stane 213,03 EUR ter traja nekaj več kot dva tedna (10,55 koledarskih dni), 2. povprečen čas prenosa dela iz aktivnosti v aktivnost je 1,34 dni, čas čakanja v vrsti za izvajanje znaša 1,15 dni, 3. povprečen delovni čas, potreben za izvedbo procesa, je 0,78 dni. Pomanjkljivosti procesa naročanja polizdelkov Sam proces ima nekaj izrazitih pomanjkljivosti, ki se jih da zajeti z naslednjimi ugotovitvami: 1. Avtomatizacije v procesu naročanja polizdelkov skorajda ni, ampak prevladujejo večinoma ročne aktivnosti, kot so na primer: tiskanje in sortiranje zahtev po dobavi glede na dobavitelje, tiskanje in pošiljanje faksov dobaviteljem ter vnos v EDI aplikacijo, tiskanje prejetega odgovora iz EDI aplikacije, vnos naročenih polizdelkov v ERP sistem, pretok pošte (papirnata dokumentacija) med oddelki lahko včasih zamuja ali pa se kakšen dokument izgubi, založi ipd.. 2. Trajanje izvedbe procesa je predolgo; predvsem čakanje na odgovor dobavitelja. 3. Čas prenosa med aktivnostmi je predolg. 4. Ker v podjetju ni dovolj virov za izvajanje procesa, se delo kopiči in čaka v na izvedbo. Analiziranje porabljenih virov Tabela 16 prikazuje potrebne vire za izvajanje procesa naročanja polizdelkov. Vidimo, da nabavni uslužbenec potrebuje 0,80 dneva, da izvede posamezen primer procesa. Strošek na to izvedbo je 123,01 EUR. Ta strošek vključuje tudi strošek ERP in EDI sistemov, ki jih uporablja. Infrastruktura je poseben vir, implicitni strošek, ki se pojavi pri vsaki aktivnosti (poglavje 3.2. Opis primera poslovnega procesa, stran 58). Tabela 16: Viri in stroški virov pri izvajanju naj-bo procesa naročanja polizdelkov. Ime vira Delovni čas Strošek vira Št. uporab- [dan] [EUR] ljenih virov Direktor nabave 0,06 12,93 1 Nabavni uslužbenec 0,80 123,01 3 Planer proizvodnje 0,19 28,74 1 Tajnica 0,04 5,13 1 Infrastruktura 1,09 43,22 18 Skupaj: 1,09 213,03 Simulacija procesa naročanja polizdelkov Ugotovili smo, da je povprečni strošek izvajanja posameznega primera procesa 213,03 EUR in da eno izvajanje procesa traja v povprečju 10,55 dni. To je res, kadar moramo izvesti samo posamezen primer procesa in ko imamo na voljo vse vire, kadar jih potrebujemo. Kako pa se obnaša proces v resničnih 70

83 okoliščinah? Ko se izvaja neprenehoma dan za dnem? Koliko časa potem traja posamezen primer procesa in koliko stane? Odgovore na takšna in podobna vprašanja nam daje simulacija. V podjetju JPK d.d. se proces naročanja polizdelkov izvede 350-krat na leto. Če na to dodamo še 42,85% izvajanj zaradi povratnih zank, ugotovimo, da se proces izvede približno 500-krat na leto. To v praksi pomeni v povprečju dva naročila na dan, oz. približno eden na vsake štiri ure. Ostali parametri simulacije so navedeni v tabeli 10. Tabela 17: Rezultati simulacije kot-je procesa naročanja polizdelkov po aktivnostih. Ime aktivnosti Celotno trajanje dela [dan] Trajanje dela [dan] Celotni strošek [EUR] Število končanih primerov Maksimalno število čakajočih Pregled in tiskanje zahteve za dobavo iz ERP sistema 0,241 0, , Izbiranje dobavitelja in načina pošiljanja 0,339 0, , Ugotavljanje kateri polizdelki so potrjeni 0,072 0, , Procesiranje izjeme 0,135 0, , Iskanje nadomestnega dobavitelja 0,353 0, , Pošiljanje dokumenta dobavitelju 0,013 0, , Zbiranje in posredovanje nabavni službi 0,021 0, , Vnašanje dokumenta v EDI sistem in pošiljanje 0,113 0, , Sprejemanje EDI odgovora in tiskanje na papir 0,063 0, , Pregledovanje odgovora in primerjava z zahtevo 0,054 0, , Klicanje dob. za ponovno pošiljanje faksa 0,031 0,031 6, Vnašanje podatkov v ERP in tiskanje naročilnice 0,109 0, , Odobravanje naročilnice 0,064 0, , Pošiljanje dokumenta dobavitelju 01 0,013 0, , Vnašanje dokumenta v EDI sistem in pošiljanje 01 0,117 0, , Dobaviteljev proces 3,000 3, Dobaviteljev proces 01 3,000 3, Dobaviteljev proces 02 3,000 3, Dobaviteljev proces 03 3,000 3, Zbiranje in posredovanje nabavni službi 01 0,013 0, , Sprejemanje EDI odgovora in tiskanje na papir 01 0,054 0, , Vnašanje potrditve o dobavi v ERP 0,051 0, , Rezultati simulacije so prikazani v tabelah 17 in 18. Povzamemo jih lahko v naslednjih ugotovitvah: 1. povprečni čas trajanja enega cikla procesa je 11,11 koledarskih dni, oz. 7,91 delovnih dni, 2. indeks izkoriščenosti virov (55,61%) je največji pri nabavnih uslužbencih, vsi ostali imajo nižji indeks izkoriščenosti (na primer planer proizvodnje ima indeks izkoriščenosti 38,46%), 3. povprečni strošek izvajanja enega procesa je 213,50 EUR kar pri 500-tih ponovitvah znese ,65 EUR, 4. predvidimo lahko, da lahko od stroškov, ki nastanejo, ko zaposleni nimajo dela, odštejemo strošek čakanja tajnice, direktorja nabave, infrastrukture ter ERP sistema, ker lahko predvidimo, da bodo preostanek delovnega časa porabili za druge aktivnosti. Tako znaša celotni strošek čakanja ,27 EUR. 5. strošek izvajanja procesa naročanja polizdelkov je seštevek povprečnih stroškov izvajanja procesa in stroškov čakanja, kar znese nekaj več kot ,00 EUR letno. 71

84 Tabela 18: Rezultati simulacije kot-je procesa naročanja polizdelkov po vlogah in oddelkih. Vloga Oddelek Uporabljenih virov Čas čakanja na delo [dan] Čas zaposlenosti [dan] Izkoriščenost Strošek čakanja Celotni strošek [%] [EUR] [EUR] Planer proizvodnje Proizvodnja 1 93,75 150,00 38, , ,00 Infrastruktura Proizvodnja 1 93,75 150,00 38, , ,87 ERP sistem Proizvodnja 1 93,75 482,57 16, ,04 Nabavni uslužbenec Nabava 3 406,66 324,61 55, , ,92 Direktor nabave Nabava 1 27,06 216,69 11, ,16 Infrastruktura Nabava 4 433,72 541,30 44, , ,67 ERP sistem Nabava 3 54, ,95 3,09-991,30 EDI sistem Nabava 2 25, ,30 2, , ,22 Tajnica Fin-računovodski 1 21,45 222,30 8, ,99 Infrastruktura Fin-računovodski 1 21,45 222,30 8, ,48 Skupaj: , ,65 Študija povračila investicije Predvideva se prenova procesa ter dvig avtomatizacije procesa na vsaj 60% (gledano po številu avtomatskih aktivnosti), s čimer bi se prepolovili stroški in čas izvajanja procesa. S tem bi podjetje tudi izboljšalo odnose z dobavitelji ter prerazporedilo odvečne vire. Projekt uvedbe BPM koncepta na primeru procesa naročanja polizdelkov se ocenjuje na cca ,00 EUR. Vsako naslednje leto vzdrževanja in upravljanja BPMS se ocenjuje na ,00 EUR letno (stran 58, poglavje 3.2. Opis primera poslovnega procesa). BPM sistem je najdražja postavka v planiranih stroških. Če se uporablja samo za izvajanje enega procesa, je seveda izvajanje tega procesa zelo drago. Ob večanju števila procesov, ki se izvajajo na BPMS, pada tudi strošek BPMS na primer procesa. Trenutni strošek izvajanja procesa naročanja polizdelkov znaša približno ,00 EUR. Pričakuje se, da bo prenovljeni poslovni proces naročanja imel povprečni čas izvajanja manj kot 4 dni ter da bo v povprečju njegov strošek manjši kot 107 EUR na primer procesa, oz ,00 EUR za 500 izvajanj letno. Pričakuje se tudi, da bo proces avtomatiziran do tolikšne mere, da bo vsaj en nabavni uslužbenec lahko opravljal druge delovne naloge, kar predstavlja zmanjšanje stroškov za ,00 EUR letno. Predvidimo lahko tudi, da bodo temu projektu sledili še drugi podobni projekti, ki bodo izkoriščali že pridobljeno znanje ter kupljeno programsko opremo. Zato bomo pri izračunu povračila investicije upoštevali tretjino vrednosti projekta ( ,00 EUR). Enačba za izračun povračila investicije: ROI% = leta * korist vložek vložek Tako znaša korist ,00 EUR letno ( ,00 EUR ,00 EUR ,00 EUR) Če predpostavimo, da podjetje želi doseči 100% ROI, potem lahko napišemo enačbo: 72

85 1 = leta * ,00 ( ,00 + (leta -1) * ,00) ( ,00 + (leta -1) * ,00) Iz te enačbe sledi, da se bo investicija povrnila v petih letih. Uprava podjetja JPK d.d. je študijo preučila in sprejela. Odobrila je predlagane enoletne planirane stroške ter BPM tim pooblastila za nadaljnje aktivnosti, potrebne za uvajanje BPM koncepta v podjetje Predlog prenove "naj-bo" modela procesa naročanja polizdelkov V tem poglavju je prikazana ena izmed možnih naj-bo procesov naročanja polizdelkov. Poudarimo še enkrat, da je to samo ena izmed nešteto možnih variant. "Naj-bo" proces je bil modeliran z WBI Modeler programsko opremo. Model vsebuje vse potrebne informacije, kot so čas in stroški izvajanja aktivnosti, potrebni viri ipd.. Model procesa je vsebovan v datoteki JPK.org in je dosegljiv kot dodatek temu poglavju na CD-ROM mediju. Pri predlogu prenove procesa je tim BPM izhajal iz dejstva, da trenutni proces predstavlja prevelike stroške ter da traja predolgo. Na podlagi teh dejstev je tim BPR uvedel še tretji način komunikacije s partnerji, tj. poslovanje preko svetovnega spleta (B2Bi). Uvedel je avtomatizacijo procesa tam, kjer je to bilo smiselno. Dodal je aktivnost avtomatskega odobravanja dobavnice, če se željena cena od podjetja JPK d.d. ne razlikuje od predlagane cene dobavitelja. Poleg tega so aktivnost, ki je izvajala delno potrditev zahtevane dobave, umaknili v infrastrukturo. To praktično pomeni, da bo v fazi izvajanja WBI Message Broker skrbel za avtomatizacijo zahtevane delne dobave. Model procesa je enostaven, saj vsebuje en osnovni proces (slika 26), proces naročanja polizdelkov (ToBe N1 Narocanje polizdelkov), ter tri pod-procese: 1. Zahteva za dobavo in odgovor od dobavitelja (ToBe N2 Zahteva in odgovor od dob.), 2. Naročilnica, zahteva za dobavo ali izjema (ToBe N2 Narocilnica,zahteva,izjema), 3. Pošiljanje naročilnice (ToBe N2 Posiljanje narocilnice). Slika 26: "Naj-bo" model procesa naročanja polizdelkov na najvišjem nivoju. Celoten, razvit proces je prikazan na sliki 27. V prilogi, v poglavju 6.6. "Naj-bo" model procesa naročanja polizdelkov, stran 124, je prikazan povečan proces. Aktivnosti, ki nastopajo v naj-bo procesu, so zbrane v tabeli 19. V tabeli 20 pa so zbrane njegove odločitvene točke in možne izbire. 73

86 Tabela 19: Aktivnosti naj-bo procesa naročanja polizdelkov. Aktivnost T1 T2 Del. mesto (DM) Število DM Oddelek Izvedba Dodatni viri Int. hrbtenica, Pregled zahteve za dobavo Ročno, 90 m 75 m Planer proizvodnje 1 Proizvodnja Infrastruktura, v ERP sistemu Avtomatsko ERP sistem Izbiranje dobavitelja in 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica načina pošiljanja Pošiljanje dokumenta Int. hrbtenica, 1 s 1 s - - Informatika Avtomatsko dobavitelju po faksu Pošiljanje dokumenta po EDI B2B pošiljanje dokumenta Sprejemanje odgovorov in vnašanje podatkov Sprejemanje EDI dokumenta Sprejemanje B2B dokumenta Pregledovanje odgovora in primerjava z zahtevo 1 s 1 s - - Informatika Avtomatsko Infrastruktura Int. hrbtenica, EDI sistem 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica Finančno- Int. hrbtenica, 60 m 45 m Tajnica 1 Ročno računovodski Infrastruktura Int. hrbtenica, 1 s 1 s - - Informatika Avtomatsko EDI sistem 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica Direktor Int. hrbtenica, Odobravanje dobave 480 m 15 m 1 Nabava Ročno nabave Infrastruktura Vnašanje podatkov v ERP Int. hrbtenica, 1 s 1 s - - Informatika Avtomatsko ter izdelava naročilnice ERP sistem Vnašanje potrditve o Int. hrbtenica, 1 s 1 s - - Informatika Avtomatsko dobavi v ERP sistem ERP sistem Int. hrbtenica, Procesiranje izjeme 1 s 1 s - - Nabava Avtomatsko Infrastruktura Ugotavljanje nepotrjenih 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica zahtev Obvesti dobavitelja 15 m 10 m Nabavni uslužbenec 1 Nabava Ročno Int. hrbtenica, Infrastruktura Legenda: T1... čas trajanja aktivnosti (bruto), T2... dejanski (neto) čas izvajanja aktivnosti, m... minuta, s... sekunda Tabela 20: Odločitvene točke naj-bo procesa naročanja polizdelkov, možne izbire ter verjetnosti pojava. Odločitev Izbira Verjetnost [%] Način pošiljanja? Faks 20 Način pošiljanja? EDI 20 Način pošiljanja? B2B 60 Zahtevana dobava? Izjema 5 Zahtevana dobava? Delno ali v celoti nepotrjena 25 Zahtevana dobava? V celoti potrjena 70 Razlika v ceni? Da 50 Razlika v ceni? Ne 50 Dobava odobrena? Da 90 Dobava odobrena? Ne 10 Vrsta izjeme? Nečitljiv faks 10 Vrsta izjeme? Ni odgovora 90 74

87 Slika 27: Razvit naj-bo model procesa naročanja polizdelkov Analiziranje "naj-bo" modela naročanja polizdelkov Analize različnih variant naj-bo procesa nam pokažejo, katera varianta najbolj ustreza našim željam in predstavam o prenovljenem procesu. V tem poglavju je prikazana analiza ene izmed možnih variant najbo modela procesa naročanja polizdelkov. Analiziranje procesa in vseh možnih poti procesa Kombinacija odločitev in možnosti v procesu tvorijo množico različnih možnih poti izvedbe primera procesa. Z analizo raziščemo obnašanje procesa z upoštevanjem vseh teh možnih variant poti procesa. Primeri poti so med sabo zelo različni. Vsak ima svojo verjetnost pojava. Vse možne poti, ki jih je sedaj 16, skozi najbo proces naročanja polizdelkov ter njihove verjetnosti pojava so prikazane v tabeli

88 Tabela 21: Možne poti skozi naj-bo proces naročanja polizdelkov in njihove verjetnosti pojava. Primer Procent Način Zahtevana Razlika Dobava Vrsta Število Št. zunanjih poti verjetnosti [%] pošiljanja? dobava? v ceni? odobrena? izjeme? aktivnosti aktivnosti 1 21,00 B2B V celoti potrjena Ne ,90 B2B V celoti potrjena Da Da ,00 B2B Delno ali v celoti nepotrjena ,00 EDI V celoti potrjena Ne ,00 Faks V celoti potrjena Ne ,30 EDI V celoti potrjena Da Da ,30 Faks V celoti potrjena Da Da ,00 EDI Delno ali v celoti nepotrjena ,00 Faks Delno ali v celoti nepotrjena ,00 B2B Izjema Ni odgovora ,10 B2B V celoti potrjena Da Ne ,00 EDI Izjema Ni odgovora ,90 Faks Izjema Ni odgovora ,70 Faks V celoti potrjena Da Ne ,70 EDI V celoti potrjena Da Ne ,10 Faks Izjema Nečitljiv faks 7 1 Skupaj: 100% Analiziranje posameznih primerov in povprečnih utežnostnih faktorjev Posamezen primer lahko izoliramo in ga analiziramo posebej. Primer, ki ga izberemo za podrobno analizo, je lahko tisti, ki se pojavlja največkrat ali tisti, ki največ stane ipd. Lahko pa analiziramo kombinacijo primerov skupaj in rezultate združimo. Tabela 22: Časovna in stroškovna analiza naj-bo procesa po metodi povprečnih utežnostih faktorjev. Primer poti Procent verjetnosti Čas trajanja procesa [dan] Čas zunanjih aktivnosti [dan] Čas prenosa med akt. [dan] Čas čakanja Neto delovni čas [dan] Minimalni čas obhoda [dan] Čas enega obhoda [dan] Strošek virov [%] [dan] [EUR] 1 21,00 0,22 0,02 0,00 0,03 0,17 0,06 0,08 30, ,90 1,23 0,02 0,00 1,00 0,20 0,08 1,08 38, ,00 0,21 0,01 0,00 0,03 0,17 0,06 0,07 30,28 4 7,00 6,20 6,00 0,00 0,03 0,17 8,06 8,07 70,24 5 7,00 6,45 6,00 0,00 0,09 0,36 8,12 8,15 58,71 6 6,30 7,20 6,00 0,00 1,00 0,20 8,07 9,07 67,38 7 6,30 7,45 6,00 0,00 1,06 0,39 8,13 9,15 78,91 8 5,00 3,20 3,00 0,00 0,03 0,17 3,06 3,07 44,47 9 5,00 3,32 3,00 0,00 0,06 0,26 3,09 3,11 50, ,00 0,25 0,01 0,00 0,04 0,20 0,07 0,08 31, ,10 1,21 0,01 0,00 1,00 0,20 0,07 1,07 38, ,00 3,24 3,00 0,00 0,04 0,20 3,07 3,08 51, ,90 3,36 3,00 0,00 0,07 0,29 3,10 3,12 45, ,70 4,32 3,00 0,00 1,03 0,29 3,10 4,11 53, ,70 4,20 3,00 0,00 1,00 0,20 3,07 4,07 58, ,10 3,39 3,00 0,00 0,08 0,31 3,10 3,13 49,99 Utežnostno povprečje 100,00 2,60 2,01 0,00 0,38 0,21 2,60 2,97 44,75 Analiziranje kombinacije primerov se lahko naredi z metodo povprečnih utežnostnih faktorjev, ki upošteva dejstvo, da so različni primeri glede na pogostost pojavljanja vrednoteni različno. Torej imajo primeri z večjo verjetnostjo pojavljanja večji utežnostni faktor. Čas in strošek posameznega primera sta pomnožena s 76

89 pogostostjo pojavljanja (procentom). Povprečni utežnostni faktor procesa se dobi s seštevanjem utežnostnih faktorjev posameznih primerov. V našem primeru je možnih 16 različnih primerov poti. Rezultati so prikazani v tabeli 22. Grafični prikazi posameznih primerov poti pa so prikazani v prilogi poglavja 6.5. Primeri poti naj-bo procesa naročanja polizdelkov na strani 116. Analiziranje različnih poti nam pomaga najti predvsem tiste procese, ki stanejo največ in trajajo najdlje. Iz tabele 21 in 22 lahko razberemo sledeče: 1. Primera poti 1 in 2 (naročanje polizdelkov preko B2Bi, ki sta v celoti potrjena) vsebujeta 9 oz. 10 aktivnosti, od tega vsak dve zunanji. Pogostost pojava primera 1 je 21%. Primer 1 stane 30,28 EUR ter se zaključi v slabih dveh urah (0,08 dneva). Pogostost pojava primera poti 2 je 18,9% ter stane 38,95 EUR. Vsebuje še aktivnost Odobravanje dobave, ki je potrebna, kadar se strošek, ki ga je pripravljeno podjetje JPK d.d. plačati, razlikuje od dobaviteljeve cene. To aktivnost izvaja ročno direktor nabave. Izvajanje traja 15 minut, vendar se pogosto zgodi, da od direktorjeve potrditve ali zavrnitve dobavnice preteče tudi do osem ur. 2. Primera poti 4 in 5 sta EDI in Faks različici primera poti 1 (B2B). Pojavljata se v 7% primerov ter staneta precej več kot B2B primer poti 1 (EDI stane 70,24 EUR, Faks stane 58,71 EUR). Oba primera poti trajata več kot 8 koledarskih dni od tega se 6 dni čaka odgovor od dobavitelja, medtem ko je čas čakanja minimalen ter čas prenosa med aktivnostmi ničen, saj je cel prenos podatkov med aktivnostmi avtomatiziran. 3. Primera poti 6 in 7 sta v bistvu enaka kot primera poti 4 in 5. Razlika je v tem, da je tukaj potrebna še odobritev naročilnice s strani direktorja nabave. Vidimo, da primer poti 7 stane 78,91 EUR, kar je največ izmedvseh primerov poti. 4. Primeri poti 11, 14 in 15 se pojavijo kadar direktor nabave naročilnico zavrne. Stanejo med 38,95 in 58,91 EUR, kar pomeni, da se podjetju, kljub višji dobaviteljevi ceni splača odobriti naročilnico do cca. 45 EUR razlike. V primeru zavrnitve bo ponovno naročanje stalo vsaj 44,75 EUR, kolikor je povprečni strošek izvajanja posameznega primera procesa. 5. Primeri poti 3, 8 in 9 se zgodijo kadar se zgodi delna potrditev ali nepotrditev zahteve v celoti. Polizdelki, ki niso bili uspešno potrjeni za dobavo, se avtomatsko vnesejo v ERP sistem, kjer jih planer proizvodnje lahko ponovno naroči. Seveda dobijo status, da so že bili naročeni pri določenem dobavitelju. 6. Primeri poti 10, 12, 13 in 16 se zgodijo v primeru izjeme. Najbolj pogosta izjema je, da s strani dobavitelja ni odgovora, kar pomeni, da se nenaročeni izdelki ponovno avtomatsko vnesejo v ERP sistem, kjer jih planer proizvodnje lahko ponovno naroči. Seveda dobijo status, da so že bili naročeni pri določenem dobavitelju. Analiziranje povprečnih utežnostnih faktorjev nam pove kako se proces obnaša kot celota. V našem primeru (tabela 22) nam pove naslednje: 1. eno izvajanje procesa v povprečju stane 44,75 EUR (pri kot-je procesu 213,03 EUR) ter traja 2,97 koledarskih dni (pri kot-je procesu 10,55 koledarskih dni), 2. povprečni čas prenosa dela iz aktivnosti v aktivnost je ničen (pri kot-je procesu 1,34 koledarskih dni), čas čakanja v vrsti za izvajanje pa znaša 0,38 dneva (pri kot-je procesu 1,15 dni koledarskih dni), 77

90 3. povprečni delovni čas, potreben za izvedbo procesa, je 0,21 dneva (pri kot-je procesu 0,78 dneva). Izboljšave naj-bo procesa naročanja polizdelkov "Naj-bo" proces ima nekaj izrazitih izboljšav glede na kot-je proces. Te so naslednje: 1. Avtomatizacija v naj-bo procesu naročanja polizdelkov je 76% (glede na število aktivnosti, ki se izvajajo avtomatsko), s čimer se znatno zmanjša ročno delo ter napake zaradi človeškega faktorja. 2. Prenos dokumentov med aktivnostmi je popolnoma avtomatiziran. 3. Pošiljanje faksov se izvede preko računalnika in programske opreme za pošiljanje faksov, kar nam prihrani tiskanje dokumentov ter ročno pošiljanje. 4. Uvedla se je moderna in stroškovno učinkovita komunikacijska pot z dobavitelji (B2Bi). 5. "Kot-je" proces se je končal, ko se je dobavitelju poslala naročilnica. V procesu se še čaka potrditev te naročilnice s strani dobavitelja. 6. Direktor dobave je razbremenjen, saj več ne odobrava naročil, ki nimajo razlike v ceni za več kot 45 EUR (med dobaviteljevo ter JPK d.o.o. ceno). 7. "Naj-bo" proces je do potankosti formaliziran, kar pri kot-je procesu ni bilo res. Analiziranje porabljenih virov Tabela 23 prikazuje potrebne vire za izvajanje procesa naročanja polizdelkov. Nabavni uslužbenec potrebuje 0,80 dneva, da izvede en primer procesa. Strošek za to je 44,75 EUR ter vključuje tudi strošek ERP in EDI sistemov. Infrastruktura je poseben vir, implicitni strošek, ki je potreben pri vsaki aktivnosti. Tajnica finančno-računovodskega oddelka je potrebna za sprejemanje faksov ter njihovo pretipkavanje v informacijski sistem. Nabavni uslužbenec je potreben samo v primeru izjeme, ko je faks nečitljiv. Takrat mora obvestiti dobavitelja za ponovno pošiljanje. Tabela 23: Viri in stroški virov pri izvajanju naj-bo procesa naročanja polizdelkov. Ime vira Delovni čas Strošek vira Št. uporab- [dan] [EUR] ljenih virov Direktor nabave 0,01 2,51 1 Nabavni uslužbenec 0,01 0,24 1 Planer proizvodnje 0,16 23,95 1 Tajnica 0,03 3,59 1 Ostalo (infrastruktura ipd.) 0,21 14,46 21 Skupaj: 0,21 44,75 Simulacija procesa naročanja polizdelkov Ugotovili smo, da je povprečni strošek izvajanja posameznega primera procesa 44,75 EUR ter da eno izvajanje procesa traja v povprečju 2,97 dni. To drži kadar moramo izvesti samo posamezen primer procesa in ko imamo na voljo vse vire takrat ko jih potrebujemo. S simulacijo bomo ugotovili kako se proces izvaja v resnici. V podjetju JPK d.d. se proces naročanja polizdelkov izvede 350-krat na leto. Če na to dodamo še 42,85% izvajanj zaradi povratnih zank, ugotovimo, da se proces izvede približno 500-krat na leto. To v praksi 78

91 pomeni v povprečju dva naročila na dan, oz. približno eden na vsake štiri ure. Ostali parametri simulacije so navedeni v tabeli 19 na strani 74. Tabela 24: Rezultati simulacije naj-bo procesa naročanja polizdelkov po aktivnostih. Ime aktivnosti Celotno trajanje dela [dan] Trajanje dela [dan] Celotni strošek [EUR] Število končanih primerov Maksimalno število čakajočih Procesiranje izjeme 01 0,031 0, , Pošiljanje dokumenta dobavitelju po faksu 0,000 0, , Obvesti dobavitelja 0,000 0,000 0, Odobravanje dobave 01 0,031 0, , Pošiljanje dokumenta dobavitelju po faksu 01 0,000 0,000 74, Dobaviteljev proces 3,000 3,000 0, Dobaviteljev proces 02 3,000 3,000 0, Dobaviteljev proces 04 3,000 3,000 0, Dobaviteljev proces 05 3,000 3,000 0, Pregled zahteve za dobavo v ERP sistemu 01 0,190 0, , Izbiranje dobavitelja in načina pošiljanja 01 0,000 0,000 0, Pošiljanje dokumenta po EDI 0,000 0, , Sprejemanje EDI dokumenta 0,000 0, , Dobaviteljev proces 03 0,010 0,010 0, B2B pošiljanje dokumenta 0,000 0,000 0, Sprejemanje B2B dokumenta 0,000 0,000 0, Pregledovanje odgovora in primerjava z zahtevo 01 0,000 0,000 0, Sprejemanje odgovorov in vnašanje podatkov 0,094 0, , Vnos podatkov v ERP ter izdelava naročilnice 0,000 0,000 0, Sprejemanje odgovorov in vnašanje podatkov 01 0,096 0, , Pošiljanje dokumenta po EDI 01 0,000 0, , Dobaviteljev proces 06 0,010 0,010 0, B2B pošiljanje dokumenta 01 0,000 0,000 0, Sprejemanje B2B dokumenta 01 0,000 0,000 0, Sprejemanje EDI dokumenta 01 0,000 0, , Vnašanje potrditve o dobavi v ERP 01 0,000 0,000 0, Ugotavljanje nepotrjenih zahtev 01 0,000 0,000 0, Rezultati simulacije glede na tabeli 24 in 25 so naslednji: 1. povprečni čas trajanja enega cikla procesa je 3,26 koledarskih dni, 2. povprečni čas izvajanja procesa je 2,33 delovna dneva, 3. povprečni delovni čas posameznega primera procesa je 0,205 dneva, 4. povprečni čas izvajanja zunanjih aktivnosti je 2,10 dneva, 5. indeks izkoriščenosti (32,30%) je največji pri planerju proizvodnje, vsi ostali imajo manjši indeks, na primer nabavni uslužbenec ima indeks izkoriščenosti 0,00%, ker ni bilo nobenega nečitljivega faksa, 6. povprečni strošek izvajanja enega procesa je 45,32 EUR, kar pri 500-tih ponovitvah znese ,64 EUR, 7. povprečni strošek čakanja oz. časa, ko viri ne izvajajo dela, je ,06 EUR. To niso dejanski stroški čakanja. Stroške čakanja infrastrukture, integracijske hrbtenice in ERP sistema ne bomo šteli med stroške čakanja, ker se le-ti viri lahko uporabljajo tudi pri drugih procesih. Prav tako ne bomo šteli stroške čakanja človeških virov, saj lahko le-ti izvajajo druge aktivnosti. Ko odštejemo 79

92 vse te stroške, dobimo dejanski strošek čakanja, ki ga v bistvu predstavlja samo EDI sistem, to je ,01 EUR. 8. strošek izvajanja procesa naročanja polizdelkov je tako vsota povprečnih stroškov izvajanja in povprečnih stroškov čakanja. Strošek izvajanja procesa je tako približno ,00 EUR letno. Tabela 25: Rezultati simulacije naj-bo procesa naročanja polizdelkov po vlogah in oddelkih. Vloga Oddelek Uporabljenih virov Čas čakanja na delo [dan] Čas zaposlenosti [dan] Izkoriščenost Strošek čakanja Celotni strošek [%] [EUR] [EUR] Planer proizvodnje Proizvodnja 1 78,13 163,72 32, , ,20 Infrastruktura Proizvodnja 5 78, ,11 6, , ,40 ERP sistem Proizvodnja 1 78,13 484,83 13, , ,85 Integracijska hrbtenica Proizvodnja 5 78, ,63 2, ,01 868,05 Nabavni uslužbenec Nabava 1 0,00 241,85 0, ,07 0,24 Direktor nabave Nabava 1 5,66 236,19 2, , ,29 Infrastruktura Nabava 4 6,75 960,63 0, ,73 345,81 Integracijska hrbtenica Nabava 4 6, ,66 0, ,45 75,00 Tajnica Fin-računovodski 1 17,72 224,13 7, , ,47 Infrastruktura Fin-računovodski 3 17,72 707,82 2, ,90 529,75 Integracijska hrbtenica Fin-računovodski 3 17, ,77 1, ,00 196,88 ERP sistem Informatika 2 0, ,09 0, ,25 0,40 EDI sistem Informatika 2 0, ,21 0, , ,12 Infrastruktura Informatika 5 0, ,22 0, ,26 252,17 Integracijska hrbtenica Informatika 5 0, ,05 0, ,33 1, , ,64 Študija povračila investicije Projekt uvedbe BPM koncepta na primeru procesa naročanja polizdelkov se ocenjuje na cca ,00 EUR, vendar samo do ene tretjine za ta proces. Vsako nadaljnje leto vzdrževanja in upravljanja BPMS se ocenjuje na ,00 EUR letno. Trenutni strošek izvajanja 500-tih primerov kot-je procesa naročanja polizdelkov znaša dobrih ,00 EUR. Strošek izvajanja naj-bo procesa se s simulacijo ocenjuje na ,00 EUR pri čemer lahko dodamo še stroške dveh nabavnih uslužbencev (80.000,00 EUR na leto), ki sedaj v tem procesu nista več potrebna, ampak lahko opravljata druga dela. Enačba za izračun povračila investicije: ROI% = leta * korist vložek vložek Podjetje JPK želi oceniti v kolikšnem času bi se investicija povrnila, to je 100% ROI. Korist na leto je ocenjena na ,00 EUR ( , , ,00). Vložek je odvisen od števila let, zato je enak ,00 / 3 + (leta 1) * ,00. 1 = leta * ,00 ( ,00 + (leta -1) * ,00) ( ,00 + (leta -1) * ,00) Iz te enačbe sledi, da se bo investicija povrnila v 17. mesecih. 80

93 3.4. Prenos "naj-bo" procesa naročanja polizdelkov v izvajalno okolje Finalizacija "naj-bo" procesa za izvajalno okolje Z orodjem za modeliranje smo do sedaj modelirali kot-je in naj-bo poslovna procesa v osnovnem načinu. Če želimo naj-bo model uporabiti kot osnovo za poslovni proces, ki se bo izvajal v izvajalnem okolju, je potrebno orodje preklopiti na integracijski način (angl. Integration Mode). S tem se pojavijo pri aktivnostih novi zavihki, v katere se vnašajo parametri, potrebni v času izvajanja. Štirje zavihki (slika 28), v katere je potrebno vnesti podatke so naslednji: splošni (angl. General) dopolnijo se podatki o načinu izvajanja aktivnosti, podatki (angl. Data) vhodne in izhodne podatkovne strukture, dodeljevanje osebja (angl. Staff Assignment) kdo sme začeti in izvajati posamezno aktivnost, avtomatizacija (angl. Automation) avtomatski ali ročni začetek oz. zaključek aktivnosti. Slika 28: Modeliranje procesa naročanja polizdelkov v integracijskem načinu. 81

94 Podatkovna struktura je zaradi enostavnosti samo ena. Imenuje se S_NP (struktura za naročanje polizdelkov). Prehaja iz aktivnosti v aktivnost in je določena je z orodjem za modeliranje. Prikazana je na sliki 28, kjer vidimo, da se pod-strukturi ZahtevaPodatki in NarocilnicaPodatki lahko ponovita do 10-krat. Slika 29: Podatkovna struktura S_NP za naj-bo proces naročanja polizdelkov. V tabeli 26 so zbrani vsi podatki, potrebni za prenos modela v izvajalno okolje. Ker smo pri modeliranju za opis aktivnosti uporabljali dolga imena, izvajalno okolje (v našem primeru WebSphere MQ WorkFlow, WMQWF) pa ima za ime aktivnosti omejitev do 31 znakov, smo imena ustrezno skrajšali. Pri aktivnostih, ki se začnejo in zaključijo avtomatsko, smo določili ime strežnika in način izvajanja. Ko se aktivnost prične avtomatsko, se vhodni podatki predajo strežniku. Le-ta nato preda podatke v eno izmed WebSphere MQ sporočilnih vrst. Iz sporočilne vrste vzame podatke WebSphere Business Integration Message Broker, ki jih obdela (na primer zapiše v bazo podatkov) ter vrne odgovor BPM sistemu. V primeru, da je določen sinhroni način izvajanja, bo BPM sistem čakal na odgovor. Ko so vsi potrebni podatki vnešeni, poženemo WMQWF preverjanje pravilnosti modela ter izvozimo model v FDL obliki. To FDL datoteko nato uvozimo v izvajalno okolje z ukazom: fmcibie u uporabniško ime -p geslo -o t f i ime datoteke 82

95 Tabela 26: Podatki aktivnosti naj-bo procesa naročanja polizdelkov za integracijski način. Dodajanje Avtomatizacija Splošni zavihek Zavihek podatki osebja Ime aktiv. pri modeliranju Ime aktivnosti v BPM sistemu Strežnik Način SA Vloga Začetek Konec I/O S S/T Pregled zahteve za dobavo I, PP,DP, PregledZahteveZaDobavoVERP UPES - DA M A, OI S_NP/ _STRUCT/ v ERP sistemu DN, DI S_NP _STRUCT Izbiranje dobavitelja in I, DN, DI, IzbiranjeDobInNacPosiljanja IZBRDOB S DA A A, OI S_NP/ _STRUCT/ načina pošiljanja NU S_NP _STRUCT Pošiljanje dokumenta I, DN, DI, PosiljanjeDokDob_Faks ZAHFAKS S DA A A, OI S_NP/ _STRUCT/ dobavitelju po faksu T, NU S_NP _STRUCT Pošiljanje dokumenta po I, DN, DI, PosiljanjeDokDob_EDI ZAHEDI S DA A A, OI S_NP/ _STRUCT/ EDI NU S_NP _STRUCT I, DN, DI, B2B pošiljanje dokumenta PosiljanjeDokDob_B2B ZAHB2B S DA A A, OI S_NP/ _STRUCT/ NU S_NP _STRUCT Sprejemanje odgovorov in I, T, DN, SprejemInVnosOdgovorov UPES - DA M A, OI S_NP/ _STRUCT/ vnašanje podatkov DI, NU S_NP _STRUCT Sprejemanje EDI I, DN, DI, SprejemanjeEDIDokumenta ZAHSEDI S DA A A, OI S_NP/ _STRUCT/ dokumenta NU S_NP _STRUCT Sprejemanje B2B I, DN, DI, SprejemanjeB2Bdokumenta ZAHSB2B S DA A A, OI S_NP/ _STRUCT/ dokumenta NU S_NP _STRUCT Pregledovanje odgovora in I, DN, DI, PregledOdgovoraInPrimerjava PRGLDZAH S DA A A, OI S_NP/ _STRUCT/ primerjava z zahtevo NU S_NP _STRUCT Odobravanje dobave OdobritevNarocilnice UPES - DA I, DN, DI M A, OI S_NP/ _STRUCT/ S_NP _STRUCT Vnos podatkov v ERP ter I, DN, DI, VnosVERPInIzdelavaNarocilnice ZAHERP S DA A A, OI S_NP/ _STRUCT/ izdelava naročilnice NU S_NP _STRUCT Pošiljanje dokumenta I, DN, DI, PosiljanjeDokDob_Faks_01 NARFAKS S DA A A, OI S_NP/ _STRUCT/ dobavitelju po faksu 01 T, NU S_NP _STRUCT Pošiljanje dokumenta po I, DN, DI, PosiljanjeDokDob_EDI_01 NAREDI S DA A A, OI S_NP/ _STRUCT/ EDI 01 NU S_NP _STRUCT Pošiljanje dokumenta po I, DN, DI, PosiljanjeDokDob_B2B_01 NARB2B S DA A A, OI S_NP/ _STRUCT/ B2B 01 NU S_NP _STRUCT Sprejemanje odgovorov in I, T, DN, SprejemInVnosOdgovorov_01 UPES - DA M A, OI S_NP/ _STRUCT/ vnašanje podatkov 01 DI, NU S_NP _STRUCT Sprejemanje EDI I, DN, DI, SprejemanjeEDIDokumenta_01 NARSEDI S DA A A, OI S_NP/ _STRUCT/ dokumenta 01 NU S_NP _STRUCT Sprejemanje B2B I, DN, DI, SprejemanjeB2Bdokumenta_01 NARSB2B S DA A A, OI S_NP/ _STRUCT/ dokumenta 01 NU S_NP _STRUCT Vnašanje potrditve o VnasanjePotrditveODobaviVERP I, DN, DI, NARERP S DA A A, OI S_NP/ _STRUCT/ dobavi v ERP 01 _01 NU S_NP _STRUCT Ugotavljanje nepotrjenih I, DN, DI, UgotavljanjeNepotrjenihZahtev NEPOTZAH S DA A A, OI S_NP/ _STRUCT/ zahtev NU S_NP _STRUCT I, DN, DI, Procesiranje izjeme ProcesiranjeIzjeme_01 IZJEMA S DA A A, OI S_NP/ _STRUCT/ NU S_NP _STRUCT I, DN, DI, Obvesti dobavitelja ObvestiDobZaPonovnoPosiljanje UPES S DA M A, OI S_NP/ _STRUCT/ NU S_NP _STRUCT Legenda: S... Sinhron način AS... Asinhron način SA... Dodeljevanje osebja DA... Dinamično dodeljevanje I... Informatik PP... Planer proizvodnje DP... Direktor proizvodnje DN...Direktor nabave DI... Direktor informatike NU... Nabavni uslužbenec T...Tajnica M... Ročno A... Avtomatsko I/OS... Vhodne/Izhodne strukture S/T... Vir/Ponor OI... Čakanje na en vhod za zaključek pri avtomatskem izvajanju UPES. Strežnik za izvajanje uporabniške aplikacije (angl: User Program Execution Server) 83

96 Izgradnja uporabniškega vmesnika za ročne aktivnosti "naj-bo" procesa Tabela 26 vsebuje spisek aktivnosti in njihove atribute, potrebne za prenos modela v produkcijsko okolje. Pet aktivnosti na tem spisku se izvajajo ročno. Za njih je potrebno izgraditi aplikacije za vnos in pregled podatkov. Najenostavnejši način za to je uporaba WebSphere MQ Workflow spletnega odjemalca ter WebSphere MQ Workflow Rapid Application Development 37 programske opreme (WMQWF RAD). WebSphere MQ Workflow spletni odjemalec se uporablja kot tanek odjemalec (slika 30). Za svoje delovanje potrebuje spletni aplikacijski strežnik. V tem primeru je to WebSphere aplikacijski strežnik. Namestitev WebSphere MQ Workflow spletnega odjemalca poteka po priloženi dokumentaciji. Slika 30: WebSphere MQ Workflow spletni odjemalec. WebSphere MQ Workflow Rapid Application Development je dodatek v WebSphere Studio Application Developer (slika 31). Namesti se po priloženi dokumentaciji. Na podlagi uvožene FDL datoteke ta dodatek izgradi osnovno javansko strežniško stran (angl. Java Server Page, JSP), ki se lahko po potrebi dodela. Slika 31: WebSphere Studio Application Developer in WMQWF RAD dodatek. Izgradili smo pet JSP strani za pet ročnih aktivnosti, ki so prikazane na sliki 32: 1. Pregled zahteve za dobavo za aktivnost PregledZahteveZaDobavoVERP (levo zgoraj), 37 Oba sta na voljo na: 84

97 2. Vnos odgovora na zahtevo za aktivnost SprejemInVnosOdgovorov (v sredini zgoraj), 3. ObvestiDobZaPonPosiljanje za aktivnost ObvestiDobZaPonPosiljanje (levo zgoraj). 4. Odobritev naročilnice za aktivnost OdobritevNarocilnice (levo spodaj), 5. Vnos odgovora na naročilnico za aktivnost SprejemInVnosOdgovorov_01 (desno spodaj), Aktivnosti Vnos odgovora na zahtevo in Vnos odgovora na naročilnico nastopita samo v primeru, da je komunikacijska pot do dobavitelja po faksu. Slika 32: JSP strani za izvajanje ročnih aktivnosti procesa naročanja polizdelkov. 85

98 Komunikacijske poti do dobaviteljev so tri: faks, EDI in B2B. Za lažji prikaz in simulacijo celotnega procesa smo izgradili še dve JSP strani za vnos odgovorov od dobaviteljev (slika 33). Ti dve aktivnosti nadomeščajo dobaviteljeva procesa sprejemanja in vračanja odgovorov na zahteve za dobavo in na naročilnice. Slika 33: JSP strani za vnos odgovorov dobaviteljev za proces naročanja polizdelkov Avtomatizacija aktivnosti in povezovanje uporabniških programov "naj-bo" procesa Tabela 27: Avtomatske aktivnosti naj-bo procesa naročanja polizdelkov. Ime aktivnosti v BPM sistemu Strežnik Ime sporočilne vrste IzbiranjeDobInNacPosiljanja IZBRDOB IZBIRA.DOB.NAC.POS PosiljanjeDokDob_Faks ZAHFAKS POSIL.ZAHTEVA.FAKS PosiljanjeDokDob_EDI ZAHEDI POSIL.ZAHTEVA.EDI PosiljanjeDokDob_B2B ZAHB2B POSIL.ZAHTEVA.B2B SprejemanjeEDIDokumenta ZAHSEDI SPREJ.ZAHTEVA.EDI SprejemanjeB2Bdokumenta ZAHSB2B SPREJ.ZAHTEVA.B2B PregledOdgovoraInPrimerjava PRGLDZAH PREGLED.ZAHTEVE.ERP VnosVERPInIzdelavaNarocilnice ZAHERP VNOS.PODATKOV.ERP PosiljanjeDokDob_Faks_01 NARFAKS POSIL.NAROCIL.FAKS PosiljanjeDokDob_EDI_01 NAREDI POSIL.NAROCIL.EDI PosiljanjeDokDob_B2B_01 NARB2B POSIL.NAROCIL.B2B SprejemanjeEDIDokumenta_01 NARSEDI SPREJ.NAROCIL.EDI SprejemanjeB2Bdokumenta_01 NARSB2B SPREJ.NAROCIL.B2B VnasanjePotrditveODobaviVERP _01 NARERP VNOS.NAROCIL.ERP UgotavljanjeNepotrjenihZahtev NEPOTZAH NEPOTRJENE.ZAHTEVE ProcesiranjeIzjeme_01 IZJEMA IZJEMA Aktivnost v BPM sistemu se lahko izvede tudi popolnoma avtomatsko (tabela 27). Takih aktivnosti je šestnajst. Za avtomatizacijo aktivnosti je potrebno le-tej definirati strežnik za izvajanje aplikacij (angl. 86

99 Program Execution Server, PES). V našem primeru definiramo PES kot sporočilno vrsto (angl. Message Queue, MQ) v WebSphere MQ. To sporočilno vrsto opazuje uporabniška aplikacija, napisana z WebSphere Business Integration Message Broker. Ko sporočilo prispe v vrsto, jo uporabniška aplikacija vzame iz vrste in obdela. Na primer prebere podatke iz baze podatkov, sešteje dve števili, pretvarja podatkovne strukture, na primer iz XML strukture v strukturo s polji fiksnih dolžin ipd.. V orodju za modeliranje v integracijskem načinu vnesemo vse potrebne podatke za izvajalno okolje. Nato jih izvozimo v FDL obliki. Lahko jih direktno uvozimo v izvajalno okolje (WebSphere MQ Workflow Runtime) ali pa jih predhodno še pregledamo z orodjem za modeliranje, ki ga vsebuje samo izvajalno okolje (WebSphere MQ Workflow Buildtime). Slika 34: WBI Message Broker aplikacija JPK_8 VnosDobaveVERP. Uporabniških aplikacij, narejenih v WebSphere Business Integration Message Broker za primer avtomatizacije poslovnega procesa naročanja polizdelkov, je deset. Te so naslednje: JPK_1 IzbiranjeDobInNacPosiljanja, JPK_2 PosiljanjeZahteveDobavitelju, JPK_3 SprejemanjeOdgovoraZahteva, JPK_4 PregledOdgovoraInPrimerjava, JPK_5 VnosVERPInIzdelavaNarocilnice, JPK_6 PosiljanjeNarocilniceDobavitelju, JPK_7 SprejemanjeOdgovoraNarocilnica, JPK_8 VnosDobaveVERP, 87

100 JPK_9 ProcesiranjeIzjeme, JPK_10 UgotavljanjeNepotrjenihZahtev. Podrobneje bomo pogledali samo aplikacijo JPK_8 VnosDobaveVERP. Ostale aplikacije so na razpolago na CD-ROM mediju kot datoteke izvožene iz WBI Message Broker razvojnega okolja. V Message Broker Toolkit razvojnem orodju najprej naredimo nov projekt za uporabniško aplikacijo (angl. Message Flow Project) ter novo uporabniško aplikacijo (angl. Message Flow). Iz palete dodatkov prenesemo po en MQInput, MQOutput in Compute dodatek ter jih povežemo kot kaže slika 34. V MQInput dodatek vnesemo parameter za vhodno sporočilno vrsto (VNOS.NAROCIL.ERP). To je hkrati tudi njegovo ime. Vnesemo tudi podatek o formatu vhodne strukture podatkov, kar je v tem primeru XML. V primeru napake v tej aplikaciji, bodo opis napake in podatki šli v MQOutput v sporočilno vrsto NAPAKA. Istočasno se v Compute dodatku z imenom In -> Out XML Napaka zgradi odgovor za preklic primera procesa. V primeru, da v tej aplikaciji ne pride do napake, Compute dodatek z imenom Vnos v ERP vnese podatke v JPK ERP bazo podatkov in hkrati izgradi odgovor o uspešnosti izvedbe aktivnosti. Ta odgovor se pošlje nazaj BPM sistemu, ki v sinhronem stanju čaka na odgovor. Da to dosežemo, moramo v Vnos v ERP vnesti naslednjo ESQL programsko logiko: -- Update baze podatkov UPDATE Database.JPK.NAROCILA AS A SET CASZIGZAHODG = InputRoot.XML.WfMessage.ActivityImplInvoke.ProgramInputData.S_NP.ZahtevaPolizdelek.DatumInCasOdgovor, CCENAZAHODG = InputRoot.XML.WfMessage.ActivityImplInvoke.ProgramInputData.S_NP.ZahtevaPolizdelek.CelotnaCenaDobavitelj, ZAHTEVANADOB = InputRoot.XML.WfMessage.ActivityImplInvoke.ProgramInputData.S_NP.ZahtevaPolizdelek.ZahtevanaDobava, CASZIGNAR = InputRoot.XML.WfMessage.ActivityImplInvoke.ProgramInputData.S_NP.NarocilnicaPolizdelek.DatumInCas, CASZIGNARODG = InputRoot.XML.WfMessage.ActivityImplInvoke.ProgramInputData.S_NP.NarocilnicaPolizdelek.DatumInCasOdgovor, CCENANARJPK = InputRoot.XML.WfMessage.ActivityImplInvoke.ProgramInputData.S_NP.ZahtevaPolizdelek.CelotnaCenaDobavitelj, CCENANARODG = InputRoot.XML.WfMessage.ActivityImplInvoke.ProgramInputData.S_NP.ZahtevaPolizdelek.CelotnaCenaDobavitelj, KOLICINANAR = InputRoot.XML.WfMessage.ActivityImplInvoke.ProgramInputData.S_NP.ZahtevaPolizdelek.ZahtevaPodatki.KolicinaDobavitelj, ODOBRENANAR = 'D', OPOMBA = InputRoot.XML.WfMessage.ActivityImplInvoke.ProgramInputData.S_NP.Opomba WHERE A.SFNAR = InputRoot.XML.WfMessage.ActivityImplInvoke.ProgramInputData.S_NP.StDokumenta; -- Odgovor o uspešnosti izvedbe aktivnosti ( ProgramRC = '0' ) Set OutputRoot.MQMD.ReplyToQ = InputRoot.MQMD.ReplyToQ; Set OutputRoot.MQMD.CorrelId = InputRoot.MQMD.MsgId; Set OutputRoot.MQMD.MsgType = MQMT_REPLY; Set OutputRoot.XML.WfMessage.WfMessageHeader.ResponseRequired = 'No'; Set OutputRoot.XML.WfMessage.ActivityImplInvokeResponse.ActImplCorrelID = InputRoot.XML.WfMessage.ActivityImplInvoke.ActImplCorrelID; Set OutputRoot.XML.WfMessage.ActivityImplInvokeResponse.ProgramRC = '0'; Slika 35: Entitetno relacijski model JPK baze podatkov in tabel za proces naročanja polizdelkov. 88

101 Baza podatkov nam v tej fazi predstavlja ERP sistem JPK podjetja. V IBM DB2 RDBMS je narejena podatkovna zbirka JPK. V podatkovnem prostoru (angl. Table Space) so narejene tri tabele: DOBAVITELJI, NAROCILA in POLIZDELKI ter dve povezovalni tabeli NAR_POLIZD in DOB_POLIZD. Slednji sta narejeni zaradi mnoge-mnogim (angl. Many-to-Many, M:N) povezav med tremi zgoraj naštetimi entitetami. Na sliki 35 je prikazan entitetno-relacijski diagram JPK baze podatkov za proces naročanja izdelkov. DDL (angl. Data Definition Language, DDL) in DML (angl. Data Manipulation Language, DML) ukazi za izgraditev in napolnitev tabel s podatki so v prilogi poglavij 6.8. Opis tabel v JPK bazi podatkov v DDL jeziku in 6.9. Opis vsebine tabel v JPK bazi podatkov v DML jeziku, na straneh 125 in Določevanje poslovnih mer za nadzorovanje "naj-bo" procesa naročanja polizdelkov Poslovne mere za nadzorovanje definiramo v orodju za modeliranje ali v WebSphere Business Integration Monitor aplikaciji. Veliko mer za nadzorovanje je že pred-definiranih. Nekaj najpomembnejših je: v strošek izvajanja aktivnosti ali procesa (angl. Activity/Process Cost), v neto trajanje izvajanja aktivnosti ali procesa (angl. Activity/Process Working Duration), v bruto trajanje izvajanja aktivnosti ali procesa (angl. Activity/Process Elapsed Duration), v kdo je izvajalec aktivnosti (angl. Activity User Identifier). Poleg že pred-definiranih mer, lahko dodatno definiramo še svoje lastne. Razdelimo jih lahko na tri različne elemente: 1. mera (angl. Metric): je vrednost (polje) v podatkih. Lahko jo samo prikažemo ali pa na tem podatku uporabimo matematične operacije, 2. pozicija (angl. Location): določa točko procesa, kjer želimo določiti mero. To je na primer pred začetkom, po zaključku ali med izvajanjem aktivnosti, 3. pogoj (angl. Condition): je dogodek za katerega mera velja. Na primer, ko bodo zaključene aktivnosti A, B in C, se bo izračunala vsota vrednosti določenih polj v podatkih. Za naš primer bomo definirali štiri poslovne mere in jim določili pozicijo: 1. poslovno mero za prikaz statusa zahteve, ki nam bo povedala ali je vrnjena zahteva popolna (P), delna (D) ali se je zgodila izjema (I). 2. poslovni meri za prikaz JPK in dobaviteljeve celotne cene, 3. poslovno mero za prikaz datuma predvidevane dobave. Tabela 28: Določitev poslovnih mer. Ime mere Polje v pod. strukturi Ime pozicije Ime aktivnosti Izvršitev Ime poslovne mere DM_StatusZahteve S_NP.ZahtevaPolizdelek. Pregledovanje odgovora po zaključku L_PregledZahOdg BM_StatusZahteve ZahtevanaDobava in primerjava z zahtevo aktivnosti DM_CCenaJPK S_NP.ZahtevaPolizdelek. Pregledovanje odgovora po zaključku L_PregledZahOdg BM_CCenaJPK CelotnaCenaJPK in primerjava z zahtevo aktivnosti DM_CCenaDobavitelj S_NP.ZahtevaPolizdelek. Pregledovanje odgovora po zaključku L_PregledZahOdg BM_CCenaDobavitelj CelotnaCenaDobavitelj in primerjava z zahtevo aktivnosti DM_DatumDobave S_NP.Opomba L_VnosNarVERP Vnašanje potrditve o po zaključku BM_DatumDobave dobavi v ERP aktivnosti 89

102 Na sliki 36 je prikazan postopek določitve mer za nadzorovanje v orodju za modeliranje. Najprej določimo mero (levo zgoraj), nato določimo njeno pozicijo (levo spodaj) ter na koncu še poslovne mere (desno). V tabeli 28 pa so zbrani vsi podatki za določitev štirih poslovnih mer. Ko jih naredimo, lahko poženemo tudi orodja za preverjanje veljavnosti poslovnih mer (Select -> Process -> Business Measures -> Business Measures Validation). Slika 36: Določevanje poslovnih mer v WebSphere Business Integration Modeler orodju. Na koncu še izvozimo podatke v XML obliki v datoteko. Datoteka vsebuje opis celotnega procesa s stroški in trajanji aktivnosti, stroški virov ipd.. Datoteko nato uvozimo v WebSphere Business Integration Monitor, ki je okolje za nadzorovanje poslovnega procesa Nadzorovanje izvajanja "naj-bo" procesa naročanja polizdelkov Z WebSphere Business Integration Monitor orodjem lahko istočasno spremljamo in upravljamo izvajanje primerov procesov, lahko pa tudi izvajamo analize na zbranih podatkih. Ena izmed možnosti, ki zaključi povratno zanko od modeliranja preko izvajanja do ponovnega modeliranja, je izvoz resničnih podatkov iz WBI Monitor in njihov uvoz v WBI Modeler. 90

103 Analiziranje istočasnega spremljanja izvajanja "naj-bo" procesa Istočasno spremljanje izvajanja posameznih primerov procesa je z WBI Monitor zelo enostavno. Popolnoma lahko upravljamo s posameznim primerom procesa. Lahko ga ustavimo, pogledamo kdo ga trenutno izvaja, uničimo, dodelimo za izvajanje drugi osebi ipd.. Na sliki 37 vidimo prikazane poslovne mere, ki smo jih definirali v orodju za modeliranje. Tudi v WBI Monitorju lahko, če želimo, definiramo še dodane poslovne mere. Slika 37: Spremljanje in upravljanje izvajanja posameznih primerov procesa naročanja polizdelkov z WBI Monitor orodjem. Za primer procesa številka 1 na zgornji sliki lahko ugotovimo, da je v izvajanju že 3 dni, 7 ur, 49 minut in 2 sekundi. Strošek izvajanja do sedaj je 67,86 EUR. Če kliknemo na Activity Instance, bomo dobili vrstni red izvajanja aktivnosti. Za vsako aktivnost je moč videti koliko časa je trajala, koliko je stala ter kdo jo trenutno izvaja oz. jo je izvajal Analiziranje zgodovine izvajanja "naj-bo" procesa Vsi podatki o izvajanju poslovnega procesa se shranjujejo v bazo podatkov. Z WBI Monitor lahko analiziramo podatke o izvajanju procesa za poljuben časovni interval, za poljubno osebo, organizacijo ali podjetje. Na voljo je tudi več vrst analiz. Za nadaljnjo obdelavo podatkov v preglednicah se lahko izvozi v formatu, ločenem z vejicami. 91

104 Primer analize primera procesa je na sliki 38. Vidimo čas začetka in konca primera procesa, njegov celotni in delovni čas trajanja. Po aktivnostih lahko točno vidimo, katera aktivnost se trenutno izvaja, kdo jo izvaja, strošek tega izvajanja ipd.. Slika 38: Prikaz in analiza izvajanja primera naj-bo procesa naročanja polizdelkov. V našem primeru smo izvajali 50 primerov procesa. Pri tem smo upoštevali procent pojavljanja posameznega primera. Procenti, število izvajanj in rezultati izvajanj so prikazani v tabeli 29 na strani 93. Strošek izvajanja predstavlja strošek virov (v EUR), ki zajema predvsem stroške človeških virov. Vidimo, da so stroški izvajanja procesa za približno 50% nižji kot pri simulaciji v orodju za modeliranje. To je zaradi naslednjih dveh vzrokov: stroški aktivnosti, ki se izvajajo avtomatsko, so odvisni od hitrosti računalnika, kjer BPM sistem teče, WBI Monitor ne upošteva in sešteva stroške izvajanja pomožnih virov v aktivnostih. Na primer pri izvajanju primera procesa št. 4, WBI Monitor ne upošteva stroškov EDI sistema. 92