Peter gersak Management poslovnih procesov · 2005. 5. 31. · Storitveno orientirana arhitektura .....50 2.3.2. Sistem za management poslovnih procesov ... Prikaz in analiza izvajanja

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

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 31.05.2005 Podpis: __________________________

KAZALO VSEBINE

1. UVOD .......................................................................................................................................................1 1.1. Namen magistrskega dela ..............................................................................................................3 1.2. Opis praktičnega primera................................................................................................................3 1.3. Cilj magistrskega dela.....................................................................................................................4 1.4. Uporabljene metode dela, predpostavke, trditve in omejitve ..........................................................5

2. TEORETIČNI DEL ....................................................................................................................................6 2.1. Prenova poslovanja ........................................................................................................................7

2.1.1. Opredelitev poslovnega procesa ........................................................................................10 2.1.2. Opredelitev managementa poslovnih procesov..................................................................11 2.1.3. Cilji, učinki in tveganja uvedbe managementa poslovnih procesov ....................................16 2.1.4. Zgodovinski vidik managementa poslovnih procesov.........................................................22 2.1.5. Prenova prenove poslovnih procesov ................................................................................28

2.1.5.1. Cilji in problemi prenove poslovnih procesov.........................................................29 2.1.5.2. Primerjava prenove in managementa poslovnih procesov ....................................30

2.1.6. Management kakovosti ......................................................................................................32 2.1.6.1. Celovit management kakovosti..............................................................................32 2.1.6.2. Metodologija šest sigma ........................................................................................33 2.1.6.3. Primerjava metodologij celovitega managementa kakovosti in šest sigma............35

2.1.7. Od identificiranja do managementa poslovnega procesa...................................................36 2.1.7.1. Metode spremljanja in analize poslovnih procesov................................................38 2.1.7.2. Metode modeliranja poslovnih procesov ...............................................................39 2.1.7.3. Simulacija poslovnih procesov...............................................................................40

2.1.8. Prihodnost managementa poslovnih procesov...................................................................40 2.2. Standardi za management poslovnih procesov ............................................................................43 2.3. Implementacija managementa poslovnih procesov ......................................................................48

2.3.1. Storitveno orientirana arhitektura .......................................................................................50 2.3.2. Sistem za management poslovnih procesov ......................................................................51

3. PRAKTIČNI DEL.....................................................................................................................................54 3.1. Tehnološke komponente ..............................................................................................................55

3.1.1. Modeliranje in analiziranje ..................................................................................................55 3.1.2. Izvajalno okolje...................................................................................................................55 3.1.3. Nadzorovanje in management............................................................................................57

3.2. Opis primera poslovnega procesa ................................................................................................58 3.3. Modeliranje in analiziranje procesa naročanja polizdelkov ...........................................................66

3.3.1. Model obstoječega stanja "kot-je" procesa naročanja polizdelkov .....................................66 3.3.2. Analiziranje "kot-je" procesa naročanja polizdelkov ...........................................................67 3.3.3. Predlog prenove "naj-bo" modela procesa naročanja polizdelkov......................................73 3.3.4. Analiziranje "naj-bo" modela naročanja polizdelkov ...........................................................75

3.4. Prenos "naj-bo" procesa naročanja polizdelkov v izvajalno okolje................................................81 3.4.1. Finalizacija "naj-bo" procesa za izvajalno okolje ................................................................81 3.4.2. Izgradnja uporabniškega vmesnika za ročne aktivnosti "naj-bo" procesa ..........................84 3.4.3. Avtomatizacija aktivnosti in povezovanje uporabniških programov "naj-bo" procesa .........86

3.5. Določevanje poslovnih mer za nadzorovanje "naj-bo" procesa naročanja polizdelkov .................89

3.6. Nadzorovanje izvajanja "naj-bo" procesa naročanja polizdelkov ..................................................90 3.6.1. Analiziranje istočasnega spremljanja izvajanja "naj-bo" procesa .......................................91 3.6.2. Analiziranje zgodovine izvajanja "naj-bo" procesa .............................................................91

4. ZAKLJUČEK ...........................................................................................................................................97 5. LITERATURA IN VIRI ...........................................................................................................................101 6. PRILOGE..............................................................................................................................................105

6.1. Slovar slovenskih prevodov tujih izrazov ....................................................................................105 6.2. Opis uporabljenih kratic ..............................................................................................................108 6.3. Primeri poti "kot-je" procesa naročanja.......................................................................................110 6.4. "Kot-je" model procesa naročanja polizdelkov............................................................................115 6.5. Primeri poti "naj-bo" procesa naročanja......................................................................................116 6.6. "Naj-bo" model procesa naročanja polizdelkov...........................................................................124 6.7. "Kot-je" in "naj-bo" modeli procesa naročanja polizdelkov..........................................................125 6.8. Opis tabel v JPK bazi podatkov v DDL jeziku .............................................................................125 6.9. Opis vsebine tabel v JPK bazi podatkov v DML jeziku ...............................................................126 6.10. Opis "naj-bo" procesa naročanja polizdelkov v FDL jeziku .........................................................127

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. ...........................................................................................11 Slika 4: Podpora BPM korenitim in postopnim spremembam poslovnih procesov. ......................................13 Slika 5: Povezovanje EAI in B2B v BPM kontekstu......................................................................................15 Slika 6: Porterjev model petih tekmovalnih sil. .............................................................................................16 Slika 7: Vrste poslovnih procesov in njihova delitev. ....................................................................................17 Slika 8: Temeljni cilji prenove poslovanja.....................................................................................................18 Slika 9: Glavne tehnologije ter njihov vpliv na spreminjanje in prenavljanje poslovnih procesov. ................23 Slika 10: Porterjeva vrednostna veriga.........................................................................................................24 Slika 11: Rummler-Branch diagram nivojev in pogledov organizacije. .........................................................25 Slika 12: Demingov PDCA krog nenehnega izboljševanja poslovnih procesov............................................33 Slika 13: Gausova krivulja in standardna deviacija. .....................................................................................33 Slika 14: DMAIC metodologija izvedbe šest sigma projektov.......................................................................34 Slika 15: Življenjska doba poslovnega procesa............................................................................................36 Slika 16: Standardi BPM. .............................................................................................................................47 Slika 17: Shematičen prikaz sistema za management poslovnih procesov. ................................................51 Slika 18: IBM “On-Demand” arhitektura. ......................................................................................................52 Slika 19: Organizacijska shema podjetja JPK d.d.. ......................................................................................58 Slika 20: Proces naročanja polizdelkov v širšem kontekstu podjetja JPK d.d.. ............................................59 Slika 21: Cilji prenove procesa naročanja polizdelkov..................................................................................63 Slika 22: Meje “kot-je” procesa naročanja polizdelkov. ................................................................................63 Slika 23: Terminski plan izvedbe projekta prenove procesa naročanja polizdelkov. ....................................66

Slika 24: “Kot-je” proces naročanja polizdelkov na najvišjem nivoju. ...........................................................66 Slika 25: Razvit “kot-je” model procesa naročanja polizdelkov.....................................................................67 Slika 26: "Naj-bo" model procesa naročanja polizdelkov na najvišjem nivoju. .............................................73 Slika 27: Razvit “naj-bo” model procesa naročanja polizdelkov. ..................................................................75 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. ........................................82 Slika 30: WebSphere MQ Workflow spletni odjemalec. ...............................................................................84 Slika 31: WebSphere Studio Application Developer in WMQWF RAD dodatek. ..........................................84 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. ..............................86 Slika 34: WBI Message Broker aplikacija JPK_8__VnosDobaveVERP. ......................................................87 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. .................................92 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. ..............................................................................................................31 Tabela 5: Primerjava TQM in metodologije šest sigma. ...............................................................................35 Tabela 6: Različni vidiki in metode modeliranja poslovnih procesov. ...........................................................39 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. ...................................61 Tabela 10: Aktivnosti “kot-je” procesa naročanja polizdelkov.......................................................................62 Tabela 11: SWOT analiza “kot-je” procesa naročanja polizdelkov. ..............................................................64 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. .......................................................................................................................................67 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. ...................................................................................................................68 Tabela 16: Viri in stroški virov pri izvajanju “naj-bo” procesa naročanja polizdelkov. ...................................70 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

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.

...................................................................................................................................................74 Tabela 21: Možne poti skozi “naj-bo” proces naročanja polizdelkov in njihove verjetnosti pojava. ..............76 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. ...................................78 Tabela 24: Rezultati simulacije “naj-bo” procesa naročanja polizdelkov po aktivnostih. ..............................79 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. ......................83 Tabela 27: Avtomatske aktivnosti “naj-bo” procesa naročanja polizdelkov. .................................................86 Tabela 28: Določitev poslovnih mer. ............................................................................................................89 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. ....................................................................................................................................94 Tabela 32: Viri in stroški virov izvajanja “naj-bo” procesa naročanja polizdelkov. ........................................94 Tabela 33: Rezultati simulacije resničnega procesa naročanja polizdelkov po aktivnostih. .........................95 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

1

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. 42-45). 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.

2

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

3

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.

1.1. 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.

1.2. 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. B2B1).

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.

1Pravilna 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).

4

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.

1.3. 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.

5

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

6

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

7

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).

2.1. 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.

8

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., 2004.

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, 2002.

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.

9

Tabela 2: Prehod iz konvencionalne v procesno orientirano organizacijo.

Prehod iz konvencionalne v procesno organizacijo. funkcijski oddelki procesne skupine enostavna opravila opolnomočeni izvajalci nadzorovani izvajalci pooblaščeni izvajalci trening zaposlenih izobraževanje zaposlenih plačilo po izkušnjah in porabljenem času plačilo po rezultatih/učinku plačilo narašča z napredovanjem in časom prisotnosti nizko plačilo z visokimi bonusi odvisnimi od učinka oz. uspešnosti napredovanje odvisno od sposobnosti napredovanje odvisno od rezultatov “zaščitniška” organizacijska kultura produktivna organizacijska kultura vodje nadzirajo in kontrolirajo vodje usmerjajo in svetujejo hierarhična organizacijska kultura horizontalna ločitev na zadolžitve in funkcije timsko delo procesnih skupin masovna proizvodnja “masovno” prilagajanje kupcem delo v pisarni delo kjerkoli

Vir: Kovačič, 2005.

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 2.1.4. 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 procesov2, • 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 2Izraz, 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.

10

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.

2.1.1. 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.

11

Slika 3: Shematski prikaz poslovnega procesa.


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.

2.1.2. 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.

12

• 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.

13

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.

14

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 integriteto3 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 trgovanje4 (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). 4Sodelovalno trgovanje predstvalja (v okviru skupnosti) poslovne interakcije med podjetji, poslovnimi partnerji in strankami na

podlagi elektronske izmenjave podatkov.

15

• 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.

Vir: Smith, 2002, str.14.

Poglejmo še dve definiciji managementa poslovnih procesov:

“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

16

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.”

2.1.3. 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. 5.

17

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 komoditizacija5 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 procesov6:

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.

5Komoditizacija (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. 6Hammer 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.

18

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. 63-65) 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.


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.”

19

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 procesov7. 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.”

7Modeliranje poslovnih procesov je bilo takratno poimenovanje dandanašnjega managementa poslovnih procesov.

20

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č.

21

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.

22

• 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.

2.1.4. 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 ravnala8:

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.

8Taylor je objavil svoje delo z naslovom Priciples of Scientific Management leta 1911.

23

• 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. 19-41).

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

24

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..

25

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

26

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 2.1.5. 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).

9Slovenski 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.

27

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 2.1.6. 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

28

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.

2.1.5. 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.

29

• 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.

2.1.5.1. 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.”

30

“Č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.

2.1.5.2. 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

31

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 BPM pogled popravljanje procesa namesto njegovega ponovnega definiranja

jasno definirana pot in krmiljena življenjska doba procesa bi morali peljati od začetnih majhnih k radikalnim spremembam

osredotočenost na proces ni bila dovolj velika.

procesi predstavljajo samo en pogled na poslovanje. Vodje morajo imeti orodja za upravljanje procesov, ki jih razumejo

snovanje procesa ni bil pomembno z orodji za BPM naj bi BPM postal rutina

zadovoljstvo z manjšimi uspehi glede na zastavljene cilje

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

vnaprej postavljene omejitve pri BPR BPM lahko upošteva vse omejitve, ki jih management želi uveljaviti, ker so oni tisti, ki vodijo organizacijo

management organizacije ni dovolil, da bi se BPR sploh pričel

BPM je naravni del poslovanja – ne bi smel biti zastrašujoč, njegovi rezultati bi morali biti merljivi in predvidljivi

vodja tima, ki ne razume BPR BPM orodja in metode naj bi bili intuitivni za uporabo. istočasno prenavljati več kot en celovit proces BPMS je okolje v katerem naj bi se lahko simultano upravljalo na stotine procesov

nezmožnost razlikovanja enkratnosti BPR od ostalih programov izboljševanja procesov

BPM ni nova teorija o managementu, ampak pomaga implementirati obstoječo strategijo organizacije

Vir: Smith, Fingar, 2003, tabela 5.1, str. 108-110.

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).

32

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.

2.1.6. 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.

2.1.6.1. 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

33

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. 71.

2.1.6.2. 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. 183.

34

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

35

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.

2.1.6.3. 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.

TQM Šest sigma

Poslovanje Pogosto ni del poslovne strategije. Vodstvo organizacije ponavadi ni vključeno in ni prave odgovornosti za projekt.

Strategija vodstva oddelka oz. organizacije. Vodstvo je močno vključeno. Projekti pazljivo izbrani in managerji so odgovorni.

Cilji Izboljšati vse. Ponavadi ne cilja na proces. Pogosto brez fokusa.

3,4 napak na milijon izdelkov. Točno opredeljen cilj. Vodstvo definira področje in obseg.

Vodenje Z močno podporo vodstva je ponavadi uspešna, čeprav nekateri mislijo, da je modna muha.

Uspešna tam, kjer je iniciativa vodstva organizacije. Vodje imajo aktivno vlogo v vseh fazah.

Uporaba Naučiti se uporabljati čimveč orodij. Čimvečja uporaba teh orodij. Ni toliko skrbi glede stroškov in rezultatov.

Od projektov se zahteva, da dosežejo cilj. Uporaba samo potrebnih orodij. Pričakujejo se velike izboljšave.

Spremembe

Znotraj oddelkov. Postopne. Redko izhajajo iz kupčevih želja in kritik. Ni časovne omejitve projekta.

Najboljši rezultati, če je osredotočanje na kupca. Osredotočanje na poslovni proces in s tem na sodelovanje med oddelki. Časovna omejitev projekta.

Organizacija

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.

Č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.

Osredotočanje Proizvodnja, produkti. Skoraj nič na storitve, logistiko ali trženje. Vsi poslovni procesi.

Vir: Adams, Wilson, Reiger, 2004.

36

2.1.7. Od identificiranja do managementa poslovnega procesa

BPM obsega osem obsežnih področij (opisano tudi v točki C. poglavja 2.1.2. 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

37

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 2.1.7.3. 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

38

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.

2.1.7.1. 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 2.1.6. 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).

39

• 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.

2.1.7.2. 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,

diagram toka podatkov (angl. Data Flow Diagram, DFD), entitetno-relacijski diagram (angl. Entity-Relationship,ER),

funkcijski (kaj, kateri)

katere aktivnosti je potrebno opraviti, katere aktivnosti se izvajajo, kateri podatki vstopajo/izstopajo v/iz aktivnosti,

SADT diagram (angl. Structured Analysis and Design Techniques),IDEF0 diagram,

organizacijski (kje, kdo)

kje se aktivnosti izvajajo, kdo jih izvaja, kateri so mehanizmi komunikacije, kako se podatki shranjujejo,

IDEF3 diagram, UML diagram primerov uporabe, UML diagram sodelovanja, organizacijski graf,

procesni (kdaj, kako)

kateri so sprožilniki aktivnosti, sledenje izvajanju aktivnosti: niz, ponavljanje, odločitev, pogoj, kdaj se aktivnost izvaja, koliko časa traja aktivnost.

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

40

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).

2.1.7.3. 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.

2.1.8. 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

41

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 pravil10. 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. 10Več o poslovnih pravilih je napisal Ronald Ross (Ross, 2003) v knjigi Principles of the Business Rules Approach.

42

Tabela 7: Preteklost, sedanjost in prihodnost BPM.

1. BPR

(preteklost)

2. ERP in Workflow

(bližnja preteklost)

3. Proces kot urejeni podatki

(sedanjost)

4. Proces kot programska koda za direktno izvajanje

(prihodnost) Poslovni pogled

Pred dobrim desetletjem je BPR obljubljal dramatične izboljšave, vendar je bilo pot-rebnih preveč naporov in roč-nega dela. Tam, kjer je BPR bil uspešen, je sicer izboljšal pro-ces(e), vendar mu ni uspelo zagotoviti dovolj velike okret-nosti in prilagodljivosti procesa.

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 aplikacij11 se v obliki poslovnih pravil izvaja na WfMS.

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.

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.

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.

ERP model je “zapekel” poslovne procese v program-sko 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.

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.

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 BPM12.

Pogled uvajanja in organizacije BPR ni imel točno določene metodologije. Zato sta se na primer identificiranje in snovanje pričela s sestankom tima s praznim listom papirja. Postavitev v izvajanje in izvajanje samo je bilo sestavljeno iz pravil in procedur, ki jim je bilo potrebno slediti. Vzdrževanje je bilo izvedeno samo v primeru neuspeha, optimalizacija in analiza sta bili večinoma na seznamu želja.

Identificiranje je bilo naporno ročno opravilo, ki je vodilo do dokumentacije procesa. Postavitev aplikacij v izvajanje je pomenilo ogromno delo v smislu časa in stroškov, ter veliko tveganje v primeru zmote. Vzdrževanje in optimalizacija sta bili omejeni. WfMS tehnologija, ki je to malo omilila, je bila tudi vključena v ERP sisteme.

V fazi identificiranja je sedaj možno pogledati na definici-jo procesa iz različnih zornih kotov v smislu poslovnih funkcij (vodstvo, analitik, IT tehnolog ipd.). Vseeno za-enkrat še vedno ni mogoče proces prevesti direktno v delujoč sistem. Optimalizaci-ja in vzdrževanje je izvedeno predvsem vizualno s pregle-dom 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.

Identificiranje bo opisalo pro-ces v standardnem digital-nem 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 izvaja-nje, ki se lahko “uglašuje v živo”. Procesi sami vključu-jejo mere in informacije o optimalizacijah in izboljša-vah. 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

11Tudi ERP je aplikacija oz. skupek aplikacij. 12Poglavje 2.1.7. Od identificiranja do managementa poslovnega procesa.

43

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.”

2.2. 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.

44

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 leti13, š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

BPEL

4WS

BPM

L

BPM

N

BPSS

EPM

L

OW

L-S

PNM

L

UML

Act.D

WS-

CDL

WSC

I

WSC

L

WSF

L

XLAN

G

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.

13Primer 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

45

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. BPDM14 (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. BPEL4WS15 (Business Process Execution Language For Web Services) ali na kratko samo BPEL – OASIS od IBM, Microsoft in BEA

14http://www.omg.org/ 15BPEL4WS nastal iz WSDL in Microsoftovega XLANG.

46

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 WSDL16 (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. BPML17 (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. BPMN18 (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. BPSS18 (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. EPML19 (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-S20 (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. PNML21 (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 222 diagram aktivnosti (Unified Modeling Language) – OMG

16http://www.w3.org/TR/wsdl 17http://www.bpmi.org/specifications.htm 18http://www.ebxml.org/specs/ 19http://wi.wu-wien.ac.at/Wer_sind_wir/mendling/EPML/ 20http://www.w3.org/2004/OWL/ 21http://www.petriweb.org/specs/ 22http://www.omg.org/uml/

47

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. WSCDL23 (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. WSCI24 (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. WSCL24 (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. WSFL25 (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. XLANG26 – 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. XPDL27 (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 http://www.intalio.com/

23http://www.w3.org/2002/ws/ 24http://www.w3.org/TR/wscl10/ 25http://www-306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf 26http://search.microsoft.com/ 27http://www.wfmc.org/standards/docs.htm

48

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 (UDDI28 - 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 2007. 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.

2.3. 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. 32-42) 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.

28http://www.uddi.org/

49

• 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,

50

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).

2.3.1. Storitveno orientirana arhitektura

Storitveno orientirana organizacija29 (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.

29http://www.serviceoriented.org/service_oriented_enterprise.html

51

2.3.2. 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. 233-256).

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. 246.

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).

52

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, 2005.

53

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.

54

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).

55

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: http://www.ibm.com ali iz naslednje literature, ki je dostopna na spletnem naslovu http://www.redbooks.ibm.com:

• 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).

3.1.1. Modeliranje in analiziranje

IBM WebSphere Business Integration Modeler30 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.

3.1.2. Izvajalno okolje

IBM WebSphere MQ Workflow31 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 30http://www-306.ibm.com/software/integration/wbimodeler/workbench/ 31http://www-306.ibm.com/software/integration/wmqwf/

56

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 Broker32 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 MQ33 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,

32http://www-306.ibm.com/software/integration/wbimessagebroker/ 33http://www-306.ibm.com/software/integration/wmq/

57

• 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 Server34 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.

3.1.3. Nadzorovanje in management

IBM WebSphere Business Integration Monitor35 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.

34http://www-306.ibm.com/software/webservers/appserv/was/ 35http://www-306.ibm.com/software/integration/wbimonitor/

58

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 polizdelke36, 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.

36Polizdelek ali sestavni del je izdelek za nadaljno vgradnjo. Tipičen polizdelek je na primer vijak.

59

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č, 2005.

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

60

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,

61

• pošiljanje zahteve za dobavo za tiste dobavitelje, katerih komunikacijska pot je faks, finančno-rač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 60.000 40 - Nabavni uslužbenec 40.000 25 - Planer proizvodnje 40.000 25 - Tajnica 30.000 15 - ERP sistem 20.000 - - EDI sistem 12.000 - 5 Infrastruktura 5.000 - 1

62

Tabela 10: Aktivnosti “kot-je” procesa naročanja polizdelkov.

Aktivnost T1 [h] T2 [h] Del. Mesto (DM) Število DM Oddelek Izvedba Dodatni viriPregled in tiskanje zahteve za dobavo iz ERP sistema 2 1,5 Planer proizvodnje 1 Proizvodnja Ročna,

Avtomatska Infrastruktura, ERP sistem

Izbiranje dobavitelja in načina pošiljanja 2,5 2 Nabavni

uslužbenec 3 Nabava Ročna Infrastruktura

Pošiljanje dokumenta dobavitelju 0,25 0,1 Tajnica 1 Finančno-

računovodski Ročna Infrastruktura

Vnašanje dokumenta v EDI sistem in pošiljanje 1 0,75 Nabavni

uslužbenec 1 Nabava Ročna, Avtomatska

Infrastruktura, EDI sistem

Sprejemanje EDI odgovora in tiskanje na papir 0,5 0,25 Nabavni

uslužbenec 1 Nabava Avtomatska, Ročna Infrastruktura

Zbiranje in posredovanje odgovora nabavni službi 0,25 0,1 Tajnica 1 Finančno-

računovodski Ročna Infrastruktura

Pregledovanje odgovora in primerjava z zahtevo 0,5 0,25 Nabavni


Ugotavljanje kateri polizdelki so potrjeni 1 0,5 Nabavni


Vnašanje podatkov v ERP in tiskanje naročilnice 1 0,75 Nabavni

uslužbenec 1 Nabava Ročna Infrastruktura, 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 dobavitelja 3 2,5 Nabavni


Klicanje dobavitelja za ponovno pošiljanje faksa 1 0,25 Nabavni


Vnašanje potrditve o dobavi v ERP sistem 1 0,25 Nabavni


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.

63

Slika 21: Cilji prenove procesa naročanja polizdelkov.

Cilji prenove procesa Prioriteta 1. Izboljšati in poenostaviti proces. 2. Izboljšati partnerske odnose z dobavitelji polizdelkov

visoka visoka

Cilji zmogljivosti procesa Merila

1. Razpolovitev časa potrebnega za izvajanje posameznega primera procesa.

• Povprečni čas posameznih izvajanj primerov procesa.

• Najdaljši in najkrajši čas izvajanja primera procesa. 2. Razpolovitev stroškov potrebnih za

izvajanje primera procesa. • Stroški posameznih primerov procesa. • Povprečni stroški primerov procesa.

3. Povečanje zadovoljstva dobaviteljev za vsaj 3% letno.

• Enkrat letno anketiranje dobaviteljev ter primerjava z anketo iz prejšnjih let.

4. Zmanjšanje zalog za vsaj 25% z uvedbo hitrejše komunikacijske poti JIT proizvodnje.

• 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.

64

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.

SWOT analiza 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.

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.

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).

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

65

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 300.000,00 EUR. Poleg tega je tim podal oceno stroškov za vsako nadaljnje leto vzdrževanja BPM sistema. Ti stroški so 50.000,00 EUR.

Tabela 12: Aktivnosti posameznih faza projekta prenove procesa naročanja polizdelkov in stroškovna analiza.

Faza Trajanje [v mesecih]

Obseg [v člo-vek mesecih]

Planirani stroški [v 1000 EUR]

1. Identifikacija A. Načrtovanje in organiziranje projekta (projekt. vodja) 1 2 6 B. Identifikacija, intervjuji in izbira procesa 12 1 36 2. Snovanje A. Podrobni procesni modeli (“kot-je”, “naj-bo”) 1 2 6 B. Širše načrtovanje informatike (baza podatkov ipd.) 2 1 6 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 - - 150 B. Nakup storitev za postavitev - - 30 C. Integracija aplikacij 3 2 18 D. Postavitev procesa v izvajanje 0,5 1 1,5 E. Izobraževanje udeležencev procesa 2 2 12 4. Izvajanje in nadzorovanje A. Odpravljanje porodnih težav 1 1 3 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 - - 16,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.

66

Slika 23: Terminski plan izvedbe projekta prenove procesa naročanja polizdelkov.

3.3. Modeliranje in analiziranje procesa naročanja polizdelkov

3.3.1. 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).

67

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.

3.3.2. 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.

68

Ž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 10 2 2 16,00 Faks Delno potrjena 12 2 3 14,00 EDI V celoti potrjena 10 2 4 4,00 Faks V celoti nepotrjena 6 1 5 4,00 EDI Delno potrjena 12 2 6 3,60 Faks Izjema Ni odgovora 7 1 7 1,00 EDI Izjema Ni odgovora 7 1 8 1,00 EDI V celoti nepotrjena 6 1 9 0,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

Tabela 15: Časovna in stroškovna analiza “kot-je” proces naročanja polizdelkov 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

[dan]

Neto delovni čas

[dan]

Minimal-ni čas

obhoda [dan]

Čas enega

obhoda [dan]

Strošek virov

[EUR]

1 56,00 9,47 6,00 1,53 1,22 0,71 10,08 11,16 186,14 2 16,00 9,63 6,00 1,56 1,29 0,78 10,11 11,21 252,80 3 14,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

69

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.

70

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 [dan]

Strošek vira [EUR]

Št. uporabljenih 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

71

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

Maksimal-no število čakajočih

Pregled in tiskanje zahteve za dobavo iz ERP sistema 0,241 0,188 18443,01 500 4 Izbiranje dobavitelja in načina pošiljanja 0,339 0,250 44269,39 500 3 Ugotavljanje kateri polizdelki so potrjeni 0,072 0,063 1134,46 96 1 Procesiranje izjeme 0,135 0,125 860,12 38 1 Iskanje nadomestnega dobavitelja 0,353 0,313 8924,01 162 2 Pošiljanje dokumenta dobavitelju 0,013 0,013 1038,20 387 1 Zbiranje in posredovanje nabavni službi 0,021 0,021 1472,33 387 1 Vnašanje dokumenta v EDI sistem in pošiljanje 0,113 0,094 2627,95 113 1 Sprejemanje EDI odgovora in tiskanje na papir 0,063 0,031 1327,98 113 2 Pregledovanje odgovora in primerjava z zahtevo 0,054 0,031 3204,34 500 2 Klicanje dob. za ponovno pošiljanje faksa 0,031 0,031 6,41 1 0 Vnašanje podatkov v ERP in tiskanje naročilnice 0,109 0,094 8202,30 433 2 Odobravanje naročilnice 0,064 0,063 7198,63 433 1 Pošiljanje dokumenta dobavitelju 01 0,013 0,013 917,48 342 1 Vnašanje dokumenta v EDI sistem in pošiljanje 01 0,117 0,094 2116,31 91 1 Dobaviteljev proces 3,000 3,000 - 387 - Dobaviteljev proces 01 3,000 3,000 - 113 - Dobaviteljev proces 02 3,000 3,000 - 342 - Dobaviteljev proces 03 3,000 3,000 - 91 - Zbiranje in posredovanje nabavni službi 01 0,013 0,013 917,48 342 1 Sprejemanje EDI odgovora in tiskanje na papir 01 0,054 0,031 1069,44 91 2 Vnašanje potrditve o dobavi v ERP 0,051 0,031 3022,76 433 2

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

106.752,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 95.393,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 200.000,00 EUR letno.

72

Tabela 18: Rezultati simulacije “kot-je” procesa naročanja polizdelkov po vlogah in oddelkih.

Vloga Oddelek

Uporab-ljenih virov

Čas zaposle-

nosti [dan]

Čas čakanja na

delo [dan]

Izkoriš-čenost

[%]

Strošek čakanja

[EUR]

Celotni strošek

[EUR]

Planer proizvodnje Proizvodnja 1 93,75 150,00 38,46 23.077,51 14.423,00Infrastruktura Proizvodnja 1 93,75 150,00 38,46 2.884,69 2.302,87ERP sistem Proizvodnja 1 93,75 482,57 16,27 - 1.717,04Nabavni uslužbenec Nabava 3 406,66 324,61 55,61 49.939,25 62.562,92Direktor nabave Nabava 1 27,06 216,69 11,10 - 6.245,16Infrastruktura Nabava 4 433,72 541,30 44,48 7.807,16 11.844,67ERP sistem Nabava 3 54,13 1698,95 3,09 - 991,30EDI sistem Nabava 2 25,50 1063,30 2,34 11.684,63 2.320,22Tajnica Fin-računovodski 1 21,45 222,30 8,80 - 2.474,99Infrastruktura Fin-računovodski 1 21,45 222,30 8,80 - 1.870,48 Skupaj: 95.393,27 106.752,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. 300.000,00 EUR. Vsako naslednje leto vzdrževanja in upravljanja BPMS se ocenjuje na 50.000,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 200.000,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. 100.000,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 40.000,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 (100.000,00 EUR).

Enačba za izračun povračila investicije:

ROI% = leta * korist – vložek vložek

Tako znaša korist 140.000,00 EUR letno (200.000,00 EUR – 100.000,00 EUR + 40.000,00 EUR) Če predpostavimo, da podjetje želi doseči 100% ROI, potem lahko napišemo enačbo:

73

1 = leta * 140.000,00 – (100.000,00 + (leta -1) * 50.000,00) (100.000,00 + (leta -1) * 50.000,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.

3.3.3. 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.

74

Tabela 19: Aktivnosti “naj-bo” procesa naročanja polizdelkov.

Aktivnost T1 T2 Del. mesto (DM) Število DM Oddelek Izvedba Dodatni viri

Pregled zahteve za dobavo v ERP sistemu 90 m 75 m Planer proizvodnje 1 Proizvodnja Ročno,

Avtomatsko

Int. hrbtenica, Infrastruktura, ERP sistem

Izbiranje dobavitelja in načina pošiljanja 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica

Pošiljanje dokumenta dobavitelju po faksu 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica,

Infrastruktura Pošiljanje dokumenta po EDI 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica,

EDI sistem B2B pošiljanje dokumenta 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica

Sprejemanje odgovorov in vnašanje podatkov 60 m 45 m Tajnica 1 Finančno-

računovodski Ročno Int. hrbtenica, Infrastruktura

Sprejemanje EDI dokumenta 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica,

EDI sistem Sprejemanje B2B dokumenta 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica

Pregledovanje odgovora in primerjava z zahtevo 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica

Odobravanje dobave 480 m 15 m Direktor nabave 1 Nabava Ročno Int. hrbtenica,

Infrastruktura Vnašanje podatkov v ERP ter izdelava naročilnice 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica,

ERP sistem Vnašanje potrditve o dobavi v ERP sistem 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica,

ERP sistem

Procesiranje izjeme 1 s 1 s - - Nabava Avtomatsko Int. hrbtenica, Infrastruktura

Ugotavljanje nepotrjenih zahtev 1 s 1 s - - Informatika Avtomatsko Int. hrbtenica

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

75

Slika 27: Razvit “naj-bo” model procesa naročanja polizdelkov.

3.3.4. 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 “naj-bo” 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 “naj-bo” proces naročanja polizdelkov ter njihove verjetnosti pojava so prikazane v tabeli 21.

76

Tabela 21: Možne poti skozi “naj-bo” proces naročanja polizdelkov in njihove verjetnosti pojava.

Primer poti

Procent verjetnosti [%]

Način pošiljanja?

Zahtevana dobava?

Razlika v ceni?

Dobava odobrena?

Vrsta izjeme?

Število aktivnosti

Št. zunanjih aktivnosti

1 21,00 B2B V celoti potrjena Ne 9 2 2 18,90 B2B V celoti potrjena Da Da 10 2 3 15,00 B2B Delno ali v celoti nepotrjena 6 1 4 7,00 EDI V celoti potrjena Ne 9 2 5 7,00 Faks V celoti potrjena Ne 9 2 6 6,30 EDI V celoti potrjena Da Da 10 2 7 6,30 Faks V celoti potrjena Da Da 10 2 8 5,00 EDI Delno ali v celoti nepotrjena 6 1 9 5,00 Faks Delno ali v celoti nepotrjena 6 1 10 3,00 B2B Izjema Ni odgovora 7 1 11 2,10 B2B V celoti potrjena Da Ne 7 1 12 1,00 EDI Izjema Ni odgovora 7 1 13 0,90 Faks Izjema Ni odgovora 7 1 14 0,70 Faks V celoti potrjena Da Ne 7 1 15 0,70 EDI V celoti potrjena Da Ne 7 1 16 0,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

[%]


[dan]

Čas zunanjih

aktivnosti [dan]


[dan]

Čas čakanja

[dan]

Neto delovni čas

[dan]

Minimal-ni čas

obhoda [dan]

Čas enega

obhoda [dan]

Strošek virov

[EUR]

1 21,00 0,22 0,02 0,00 0,03 0,17 0,06 0,08 30,28 2 18,90 1,23 0,02 0,00 1,00 0,20 0,08 1,08 38,95 3 15,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,24 10 3,00 0,25 0,01 0,00 0,04 0,20 0,07 0,08 31,29 11 2,10 1,21 0,01 0,00 1,00 0,20 0,07 1,07 38,95 12 1,00 3,24 3,00 0,00 0,04 0,20 3,07 3,08 51,24 13 0,90 3,36 3,00 0,00 0,07 0,29 3,10 3,12 45,47 14 0,70 4,32 3,00 0,00 1,03 0,29 3,10 4,11 53,14 15 0,70 4,20 3,00 0,00 1,00 0,20 3,07 4,07 58,91 16 0,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

77

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),

78

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.


Strošek vira [EUR]


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

79

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]




Procesiranje izjeme 01 0,031 0,031 236,46 35 0 Pošiljanje dokumenta dobavitelju po faksu 0,000 0,000 115,12 115 0 Obvesti dobavitelja 0,000 0,000 0,00 0 0 Odobravanje dobave 01 0,031 0,031 1657,91 181 1 Pošiljanje dokumenta dobavitelju po faksu 01 0,000 0,000 74,08 74 0 Dobaviteljev proces 3,000 3,000 0,00 115 - Dobaviteljev proces 02 3,000 3,000 0,00 96 - Dobaviteljev proces 04 3,000 3,000 0,00 74 - Dobaviteljev proces 05 3,000 3,000 0,00 63 - Pregled zahteve za dobavo v ERP sistemu 01 0,190 0,156 16320,43 500 1 Izbiranje dobavitelja in načina pošiljanja 01 0,000 0,000 0,19 500 0 Pošiljanje dokumenta po EDI 0,000 0,000 480,07 96 0 Sprejemanje EDI dokumenta 0,000 0,000 480,07 96 0 Dobaviteljev proces 03 0,010 0,010 0,00 289 - B2B pošiljanje dokumenta 0,000 0,000 0,11 289 0 Sprejemanje B2B dokumenta 0,000 0,000 0,11 289 0 Pregledovanje odgovora in primerjava z zahtevo 01 0,000 0,000 0,19 500 0 Sprejemanje odgovorov in vnašanje podatkov 0,094 0,094 1686,11 115 1 Vnos podatkov v ERP ter izdelava naročilnice 0,000 0,000 0,32 317 0 Sprejemanje odgovorov in vnašanje podatkov 01 0,096 0,094 1084,98 74 1 Pošiljanje dokumenta po EDI 01 0,000 0,000 378,09 63 0 Dobaviteljev proces 06 0,010 0,010 0,00 180 - B2B pošiljanje dokumenta 01 0,000 0,000 0,07 180 0 Sprejemanje B2B dokumenta 01 0,000 0,000 0,07 180 0 Sprejemanje EDI dokumenta 01 0,000 0,000 315,05 63 0 Vnašanje potrditve o dobavi v ERP 01 0,000 0,000 0,32 317 0 Ugotavljanje nepotrjenih zahtev 01 0,000 0,000 0,07 183 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 22.661,64 EUR,

7. povprečni strošek čakanja oz. časa, ko viri ne izvajajo dela, je 211.077,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

80

vse te stroške, dobimo dejanski strošek čakanja, ki ga v bistvu predstavlja samo EDI sistem, to je 11.310,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 34.000,00 EUR letno.

Tabela 25: Rezultati simulacije “naj-bo” procesa naročanja polizdelkov po vlogah in oddelkih.

Vloga Oddelek Uporab-

ljenih virov

Čas zaposle-

nosti [dan]

Čas čakanja na

delo [dan]

Izkoriš-čenost

[%]

Strošek čakanja

[EUR]

Celotni strošek

[EUR]

Planer proizvodnje Proizvodnja 1 78,13 163,72 32,30 25187,84 12019,20 Infrastruktura Proizvodnja 5 78,13 1131,11 6,46 21752,03 2002,40 ERP sistem Proizvodnja 1 78,13 484,83 13,88 8879,60 1430,85 Integracijska hrbtenica Proizvodnja 5 78,13 2736,63 2,78 30407,01 868,05 Nabavni uslužbenec Nabava 1 0,00 241,85 0,01 37207,07 0,24 Direktor nabave Nabava 1 5,66 236,19 2,34 54505,32 1305,29 Infrastruktura Nabava 4 6,75 960,63 0,70 18473,73 345,81 Integracijska hrbtenica Nabava 4 6,75 2062,66 0,33 22918,45 75,00 Tajnica Fin-računovodski 1 17,72 224,13 7,33 25860,83 2044,47 Infrastruktura Fin-računovodski 3 17,72 707,82 2,44 13611,90 529,75 Integracijska hrbtenica Fin-računovodski 3 17,72 1552,77 1,13 17253,00 196,88 ERP sistem Informatika 2 0,02 1059,09 0,00 19397,25 0,40 EDI sistem Informatika 2 0,01 1029,21 0,00 11310,01 1590,12 Infrastruktura Informatika 5 0,01 1209,22 0,00 23254,26 252,17 Integracijska hrbtenica Informatika 5 0,11 2833,05 0,00 31478,33 1,26 361496,65 22661,64

Študija povračila investicije Projekt uvedbe BPM koncepta na primeru procesa naročanja polizdelkov se ocenjuje na cca. 300.000,00 EUR, vendar samo do ene tretjine za ta proces. Vsako nadaljnje leto vzdrževanja in upravljanja BPMS se ocenjuje na 50.000,00 EUR letno. Trenutni strošek izvajanja 500-tih primerov “kot-je” procesa naročanja polizdelkov znaša dobrih 200.000,00 EUR. Strošek izvajanja “naj-bo” procesa se s simulacijo ocenjuje na 34.000,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:


Podjetje JPK želi oceniti v kolikšnem času bi se investicija povrnila, to je 100% ROI. Korist na leto je ocenjena na 246.000,00 EUR (200.000,00 - 34.000,00 + 80.000,00). Vložek je odvisen od števila let, zato je enak 300.000,00 / 3 + (leta – 1) * 50.000,00.

1 = leta * 246.000,00 – (100.000,00 + (leta -1) * 50.000,00) (100.000,00 + (leta -1) * 50.000,00)

Iz te enačbe sledi, da se bo investicija povrnila v 17. mesecih.

81

3.4. Prenos "naj-bo" procesa naročanja polizdelkov v izvajalno okolje

3.4.1. 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.

82

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”

83

Tabela 26: Podatki aktivnosti “naj-bo” procesa naročanja polizdelkov za integracijski način.

Splošni zavihek Dodajanje osebja

Avtoma-tizacija Zavihek podatki

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 v ERP sistemu PregledZahteveZaDobavoVERP UPES - DA I, PP,DP,

DN, DI M A, OI S_NP/S_NP

_STRUCT/_STRUCT

Izbiranje dobavitelja in načina pošiljanja IzbiranjeDobInNacPosiljanja IZBRDOB S DA I, DN, DI,

NU A A, OI S_NP/S_NP

_STRUCT/_STRUCT

Pošiljanje dokumenta dobavitelju po faksu PosiljanjeDokDob_Faks ZAHFAKS S DA I, DN, DI,

T, NU A A, OI S_NP/S_NP

_STRUCT/_STRUCT

Pošiljanje dokumenta po EDI PosiljanjeDokDob_EDI ZAHEDI S DA I, DN, DI,


_STRUCT/_STRUCT

B2B pošiljanje dokumenta PosiljanjeDokDob_B2B ZAHB2B S DA I, DN, DI, NU A A, OI S_NP/

S_NP _STRUCT/_STRUCT

Sprejemanje odgovorov in vnašanje podatkov SprejemInVnosOdgovorov UPES - DA I, T, DN,

DI, NU M A, OI S_NP/S_NP

_STRUCT/_STRUCT

Sprejemanje EDI dokumenta SprejemanjeEDIDokumenta ZAHSEDI S DA I, DN, DI,


_STRUCT/_STRUCT

Sprejemanje B2B dokumenta SprejemanjeB2Bdokumenta ZAHSB2B S DA I, DN, DI,


_STRUCT/_STRUCT

Pregledovanje odgovora in primerjava z zahtevo PregledOdgovoraInPrimerjava PRGLDZAH S DA I, DN, DI,


_STRUCT/_STRUCT

Odobravanje dobave OdobritevNarocilnice UPES - DA I, DN, DI M A, OI S_NP/S_NP

_STRUCT/_STRUCT

Vnos podatkov v ERP ter izdelava naročilnice VnosVERPInIzdelavaNarocilnice ZAHERP S DA I, DN, DI,


_STRUCT/_STRUCT

Pošiljanje dokumenta dobavitelju po faksu 01 PosiljanjeDokDob_Faks_01 NARFAKS S DA I, DN, DI,

T, NU A A, OI S_NP/S_NP

_STRUCT/_STRUCT

Pošiljanje dokumenta po EDI 01 PosiljanjeDokDob_EDI_01 NAREDI S DA I, DN, DI,


_STRUCT/_STRUCT

Pošiljanje dokumenta po B2B 01 PosiljanjeDokDob_B2B_01 NARB2B S DA I, DN, DI,


_STRUCT/_STRUCT

Sprejemanje odgovorov in vnašanje podatkov 01 SprejemInVnosOdgovorov_01 UPES - DA I, T, DN,

DI, NU M A, OI S_NP/S_NP

_STRUCT/_STRUCT

Sprejemanje EDI dokumenta 01 SprejemanjeEDIDokumenta_01 NARSEDI S DA I, DN, DI,


_STRUCT/_STRUCT

Sprejemanje B2B dokumenta 01 SprejemanjeB2Bdokumenta_01 NARSB2B S DA I, DN, DI,


_STRUCT/_STRUCT

Vnašanje potrditve o dobavi v ERP 01

VnasanjePotrditveODobaviVERP _01 NARERP S DA I, DN, DI,


_STRUCT/_STRUCT

Ugotavljanje nepotrjenih zahtev UgotavljanjeNepotrjenihZahtev NEPOTZAH S DA I, DN, DI,


_STRUCT/_STRUCT

Procesiranje izjeme ProcesiranjeIzjeme_01 IZJEMA S DA I, DN, DI, NU A A, OI S_NP/


Obvesti dobavitelja ObvestiDobZaPonovnoPosiljanje UPES S DA I, DN, DI, NU M A, OI S_NP/


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)

84

3.4.2. 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 Development37 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),

37Oba sta na voljo na: http://www-306.ibm.com/software/integration/support/supportpacs/product.html#wmqwf

85

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.

86

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.

3.4.3. 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.

87

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,

88

• 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.

89

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 126.

3.5. 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.ZahtevanaDobava L_PregledZahOdg Pregledovanje odgovora

in primerjava z zahtevo po zaključku aktivnosti BM_StatusZahteve

DM_CCenaJPK S_NP.ZahtevaPolizdelek.CelotnaCenaJPK L_PregledZahOdg Pregledovanje odgovora

in primerjava z zahtevo po zaključku aktivnosti BM_CCenaJPK

DM_CCenaDobavitelj S_NP.ZahtevaPolizdelek.CelotnaCenaDobavitelj L_PregledZahOdg Pregledovanje odgovora

in primerjava z zahtevo po zaključku aktivnosti BM_CCenaDobavitelj

DM_DatumDobave S_NP.Opomba L_VnosNarVERP Vnašanje potrditve o dobavi v ERP

po zaključku aktivnosti BM_DatumDobave

90

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.

3.6. 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.

91

3.6.1. 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.

3.6.2. 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.

92

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.

93

Zaradi teh dveh vzrokov je najbolje, da se zbrani podatki o dejanskih časih izvajanja izvozijo iz WBI Monitor in se uvozijo v WBI Modeler, kjer se izvede ponovna simulacija poslovnega procesa. S tem se zaključi povratna zanka od snovanja preko analize, izvajanja, nadzorovanja do ponovnega modeliranja.

Tabela 29: Procent pojavljanja primerov poti pri izvajanju “naj-bo” procesa naročanja polizdelkov ter njihovi stroški.

Primer poti

Procent pojavljanja [%]

Število izvajanj

Način pošiljanja?

Zahtevana dobava?

Razlika v ceni?

Dobava odobrena?

Vrsta izjeme?

Strošek izvajanja

1 22,00 11 B2B V celoti potrjena Ne 24,11 2 20,00 10 B2B V celoti potrjena Da Da 26,12 3 16,00 8 B2B Delno ali v celoti nepotrjena 23,08 4 6,00 3 EDI V celoti potrjena Ne 28,65 5 6,00 3 Faks V celoti potrjena Ne 43,27 6 6,00 3 EDI V celoti potrjena Da Da 30,28 7 4,00 2 Faks V celoti potrjena Da Da 51,86 8 4,00 2 EDI Delno ali v celoti nepotrjena 22,53 9 2,00 1 Faks Delno ali v celoti nepotrjena 33,99 10 2,00 1 B2B Izjema Ni odgovora 23,75 11 2,00 1 B2B V celoti potrjena Da Ne 32,82 12 2,00 1 EDI Izjema Ni odgovora 23,85 13 2,00 1 Faks Izjema Ni odgovora 34,38 14 2,00 1 Faks V celoti potrjena Da Ne 40,92 15 2,00 1 EDI V celoti potrjena Da Ne 30,64 16 2,00 1 Faks Izjema Nečitljiv faks 36,38

Skupaj: 100% 50 Analiziranje posameznih primerov in povprečnih utežnostnih faktorjev procesa naročanja polizdelkov z dejanskimi podatki Podatki, dobljeni iz izvajalnega okolja so zbrani v tabeli 30. Časi dobaviteljev za pošiljanje odgovorov so enaki kot pri prejšnji simulaciji (glej tabelo 19). To so za Faks in EDI 3 dni ter za B2B 5 minut. Prav tako so bili enaki tudi časi izvajanja avtomatskih aktivnosti, to je 1 sekunda.

Tabela 30: Resnični podatki izvajanja “naj-bo” procesa naročanja polizdelkov.

Aktivnost T1 T2 Del. mesto (DM) Število DM Pregled zahteve za dobavo v ERP sistemu 85 m 73 m Planer proizvodnje 1 Sprejemanje odgovorov in vnašanje podatkov 52,23 m 38,75 m Tajnica 1 Sprejemanje odgovorov in vnašanje podatkov_01 58,90 m 43,62 m Tajnica 1 Odobravanje dobave 393 m 12,82 m Direktor nabave 1 Obvesti dobavitelja 17,63 m 13,10 m Nabavni uslužbenec 1

Legenda: T1 ... čas trajanja aktivnosti (bruto), T2 ... dejanski (neto) čas izvajanja aktivnosti, m ... minuta

V tabeli 31 so prikazani podatki analize procesa z dejanskimi podatki. Vidimo, da je v povprečju strošek za izvajanje enega procesa padel za 1,50 EUR – iz 44,75 EUR na 43,25 EUR. Samo trajanje procesa se je zmanjšalo iz 2,60 na 2,51 delovnega dne.

94

Tabela 31: Časovna in stroškovna analiza izvajanja “naj-bo” procesa po metodi povprečnih utežnostnih faktorjev.

Primer poti

Procent verjetnosti

[%]


[dan]

Čas zunanjih

aktivnosti [dan]


[dan]

Čas čakanja

[dan]

Neto delovni čas

[dan]

Minimal-ni čas

obhoda [dan]

Čas enega

obhoda [dan]

Strošek virov

[EUR]

1 21,00 0,20 0,02 0,00 0,02 0,15 0,06 0,07 29,54 2 18,90 1,02 0,02 0,00 0,82 0,18 0,07 1,00 37,09 3 15,00 0,19 0,01 0,00 0,02 0,15 0,05 0,06 29,53 4 7,00 6,18 6,00 0,00 0,02 0,15 8,05 8,06 69,54 5 7,00 6,41 6,00 0,00 0,08 0,32 8,11 8,14 55,93 6 6,30 7,23 6,00 0,00 0,88 0,35 8,12 9,07 63,48 7 6,30 7,00 6,00 0,00 0,82 0,18 8,06 8,33 77,09 8 5,00 3,29 3,00 0,00 0,05 0,23 3,08 3,09 42,07 9 5,00 3,18 3,00 0,00 0,02 0,15 3,05 3,06 49,53 10 3,00 0,19 0,01 0,00 0,02 0,15 0,05 0,06 30,54 11 2,10 1,01 0,01 0,00 0,82 0,18 0,06 1,00 37,09 12 1,00 3,18 3,00 0,00 0,02 0,15 3,05 3,06 50,54 13 0,90 3,29 3,00 0,00 0,05 0,23 3,08 3,09 43,07 14 0,70 4,10 3,00 0,00 0,84 0,26 3,09 4,03 49,62 15 0,70 4,00 3,00 0,00 0,82 0,18 3,06 3,33 57,09 16 0,10 3,32 3,00 0,00 0,06 0,26 3,09 3,11 48,68

Utežnostno povprečje 100,00 2,51 2,01 0,00 0,31 0,19 2,60 2,89 43,25

Analiziranje porabljenih virov Tabela 31 prikazuje potrebne vire za izvajanje procesa naročanja polizdelkov. Vidimo, da je najdražja postavka planer proizvodnje (v nasprotju s “kot-je” modelom, kjer je bil to nabavni uslužbenec), ki izvaja eno zahtevo 0,15 dneva ter stane več kot polovico vseh povprečnih stroškov procesa.

Tabela 32: Viri in stroški virov izvajanja “naj-bo” procesa naročanja polizdelkov.


Strošek vira [EUR]


Direktor nabave 0,01 2,15 1 Nabavni uslužbenec 0,01 0,22 1 Planer proizvodnje 0,15 23,37 1 Tajnica 0,03 3,25 1 Ostalo (infrastruktura ipd.) 0,20 14,26 21

Skupaj: 0,20 43,25 Simulacija procesa naročanja polizdelkov

Simulacija je bila izvedena z enakimi parametri kot so navedeni v tabeli 19 na strani 74, razen za aktivnosti, navedene v tabeli 30 na strani 93, kjer so bile uporabljene vrednosti iz te tabele. Rezultati simulacije procesa naročanja polizdelkov z dejanskimi vrednostmi, dobljenimi iz izvajalnega okolja, so prikazani v tabeli 33.

95

Tabela 33: Rezultati simulacije resničnega procesa naročanja polizdelkov po aktivnostih.

Ime aktivnosti

Celotno trajanje

dela [dan]

Trajanje dela [dan]




Procesiranje izjeme 0,032 0,031 233,03 37 1 Pošiljanje dokumenta dobavitelju po faksu 0,000 0,000 88,05 88 0 Obvesti dobavitelja 0,031 0,031 6,30 1 0 Odobravanje dobave 0,033 0,031 1366,19 157 1 Pošiljanje dokumenta dobavitelju po faksu 01 0,000 0,000 57,03 57 0 Pregled zahteve za dobavo v ERP sistemu 0,156 0,156 15175,81 500 0 Izbiranje dobavitelja in načina pošiljanja 01 0,000 0,000 0,19 500 0 Pošiljanje dokumenta po EDI 0,000 0,000 565,09 113 0 Sprejemanje EDI dokumenta 0,000 0,000 565,09 113 0 B2B pošiljanje dokumenta 0,000 0,000 0,12 299 0 Sprejemanje B2B dokumenta 0,000 0,000 0,12 299 0 Pregledovanje odgovora in primerjava z zahtevo 01 0,000 0,000 0,19 500 0 Sprejemanje odgovorov in vnašanje podatkov 0,094 0,094 1169,36 88 0 Vnos podatkov v ERP ter izdelava naročilnice 0,000 0,000 0,32 310 0 Sprejemanje odgovorov in vnašanje podatkov 01 0,094 0,094 757,43 57 0 Pošiljanje dokumenta po EDI 01 0,000 0,000 340,05 68 0 B2B pošiljanje dokumenta 01 0,000 0,000 0,07 185 0 Sprejemanje B2B dokumenta 01 0,000 0,000 0,07 185 0 Sprejemanje EDI dokumenta 01 0,000 0,000 340,05 68 0 Vnašanje potrditve o dobavi v ERP 01 0,000 0,000 0,32 310 0 Ugotavljanje nepotrjenih zahtev 0,002 0,002 0,55 189 0 Dobaviteljev proces 3,000 3,000 0,00 88 0 Dobaviteljev proces 01 3,000 3,000 0,00 113 0 Dobaviteljev proces 02 0,010 0,010 0,00 299 0 Dobaviteljev proces 03 3,000 3,000 0,00 57 0 Dobaviteljev proces 04 3,000 3,000 0,00 68 0 Dobaviteljev proces 05 0,010 0,010 0,00 185 0

Tabela 34: Rezultati simulacije resničnega procesa naročanja polizdelkov po vlogah in oddelkih.

Vloga Oddelek Uporab-

ljenih virov

Čas zaposle-

nosti [dan]

Čas čakanja na delo [dan]

Izkoriš-čenost

[%]

Strošek čakanja

[EUR]

Celotni strošek

[EUR]

Planer proizvodnje Proizvodnja 1 78,13 177,25 30,59 27269,26 12019,20 Infrastruktura Proizvodnja 1 78,13 585,25 11,78 - 857,72 ERP sistem Proizvodnja 1 78,13 585,25 11,78 - 1430,85 Integracijska hrbtenica Proizvodnja 1 78,13 585,25 11,78 (6502,78) 868,05 Nabavni uslužbenec Nabava 1 1,19 254,19 0,47 39105,80 182,69 Direktor nabave Nabava 1 4,91 250,47 1,92 - 1132,21 Infrastruktura Nabava 1 6,09 1092,11 0,55 - 222,90 Integracijska hrbtenica Nabava 1 6,09 543,01 1,11 (6033,43) 67,71 Tajnica Fin-računovodski 1 13,59 241,78 5,32 - 1568,51 Infrastruktura Fin-računovodski 1 13,59 533,68 2,48 - 207,24 Integracijska hrbtenica Fin-računovodski 1 13,59 533,68 2,48 (5929,78) 151,04 ERP sistem Informatika 1 0,02 569,00 0,00 - 0,39 EDI sistem Informatika 1 0,01 564,51 0,00 6203,39 1810,13 Infrastruktura Informatika 1 0,01 547,74 0,00 - 145,02 Integracijska hrbtenica Informatika 2 0,16 1249,48 0,01 (13883,09) 1,74 Skupaj: 104.927,54 20.665,43

96

Ti rezultati so naslednji: • povprečni čas trajanja enega cikla 2,80 koledarskih dni, • povprečni strošek izvajanja posameznega primera procesa je 41,33 EUR, kar znese pri 500-tih

ponovitvah 20.665,00 EUR, • povprečni čas trajanja zunanjih aktivnosti je 1,97 dneva, • povprečni čas za izvajanje dela je 0,196 dneva, • indeks izkoriščenosti je največji pri planerju proizvodnje (30,59%). To pomeni, da planer

proizvodnje zmore še vsaj za 100% večjo obremenitev, kot jo ima sedaj (dve naročili na dan) oz. lahko dela druga dela,

• strošek čakanja virov na delo (brez infrastrukture in ERP sistema) znaša 104.927,54 EUR. Če od tega zneska odštejemo stroške integracijske hrbtenice, dobimo strošek čakanja virov 72.578,46 EUR. Nabavni uslužbenec je izkoriščen samo 0,47% svojega časa. Tudi strošek čakanja nabavnega uslužbenca in planerja proizvodnje lahko odštejemo, kajti dodeljene so jima bile dodatne zadolžitve. Tako znaša celotni realni strošek čakanja virov samo strošek EDI sistema, ki je 6203,39 EUR,

• celotni dejanski strošek procesa naročanja polizdelkov je seštevek stroškov čakanja in izvajanja procesa. Tako znaša ta strošek približno 27.000,00 EUR letno.

Študija povračila investicije glede na dejanske stroške Projekt uvedbe BPM koncepta na primeru procesa naročanja polizdelkov se ocenjuje na cca. 300.000,00 EUR, vendar za ta proces samo do ene tretjine. Vsako nadaljnje leto vzdrževanja in upravljanja BPMS se ocenjuje na 50.000,00 EUR letno. Strošek izvajanja 500-tih primerov procesa naročanja polizdelkov je pred prenovo znašala dobrih 200.000,00 EUR. Dejanski strošek izvajanja procesa je cca. 27.000,00 EUR, pri čemer lahko dodamo še stroške dodatnih dveh nabavnih uslužbencev (80.000,00 EUR na leto), ki jih sedaj v tem procesu ni več potrebno, ampak lahko opravljajo druga dela.

Enačba za izračun povračila investicije je naslednja:


Podjetje JPK želi oceniti v kolikšnem času bi se investicija povrnila, to je 100% ROI. Korist na leto je ocenjena na 253.000,00 EUR (200.000,00 – 27.000,00 + 80.000,00). Vložek je odvisen od števila let, zato je enak 300.000,00 / 3 + (leta – 1) * 50.000,00.

1 = leta * 253.000,00 – (100.000,00 + (leta -1) * 50.000,00) 100.000,00 + (leta -1) * 50.000,00

Iz te enačbe sledi, da se bo investicija povrnila v 13-tih mesecih.

97

4. ZAKLJUČEK

V devetdesetih letih prejšnjega stoletja se je poslovno okolje začelo spreminjati s silovito naglico. Vzroki za to so bili globalizacija, tehnološki razvoj, zahtevnejši kupci ipd.. Podjetja, ki so hotela preživeti ter ohraniti konkurenčno prednost, so uporabljala različne poslovne prijeme. Eden teh je tudi korenita prenova poslovnih procesov. Nekaterim podjetjem je korenita prenova prinesla veliko zmanjšanje stroškov, pri veliki večini podjetij pa je bila prenova neuspešna. Desetletje pozneje ugotavljamo vzroke tega pojava in zakaj je bilo temu tako in ugotovimo lahko, da je bolj kot korenita prenova, primernejša postopna prenova poslovnih procesov. Ena izmed vidnejših teorij in metodologij postopne prenove in nenehnega izboljševanja poslovnih procesov je management poslovnih procesov. Management poslovnih procesov obsega tako analizo obstoječega stanja kot tudi izvajanje in opazovanje izvajanja procesa ter njegovo korekcijo.

Cilj teoretičnega dela tega magistrskega dela je bil 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 prenova poslovnih procesov) in ki so komplementarne managementu poslovnih procesov (kot je koncept šest sigma).

Cilj praktičnega dela tega magistrskega dela je bil slovenski javnosti približati izvedbo celovitega primera metodologije managementa poslovnih procesov na primeru poslovnega procesa naročanja polizdelkov. Uporabljen je bil IBM BPMS, to je IBM WebSphere programska oprema.

V poglavju 1.4. Uporabljene metode dela, predpostavke, trditve in omejitve sem postavil 8 trditev. Poglejmo te trditve še enkrat in ugotovimo, v kolikšni meri držijo:

Trditev 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.

Ugotovitev 1: V “kot-je” procesu naročanja polizdelkov je vseh aktivnosti 18. Prikazane so v tabelah 10 in 18 na straneh 62 in 72. Vse te aktivnosti so ročne aktivnosti. Pri “naj-bo” procesu je vseh aktivnosti 20 (zaradi dodaje B2Bi komunikacijske poti jih je v bistvu več kot pri “kot-je” procesu). 15 od teh aktivnosti je popolnoma avtomatiziranih, medtem ko 5 aktivnosti ostaja ročnih. Vidimo, da je stopnja avtomatizacije aktivnosti “naj-bo” procesa naročanja polizdelkov 75%. S to ugotovitvijo se trditev 1 sprejme.

Trditev 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.

Ugotovitev 2: Iz tabele 14 in 15 lahko ugotovimo, da je strošek izvedbe procesa naročanja polizdelkov preko faksa 186,14 EUR ter preko EDI 249,50 EUR. Ugotovimo, da trditev 2 ne drži, saj ima EDI način

98

komunikacije višje stroške kot faks. Vzrok so veliki stroški vzdrževanja EDI sistema ter stroški plačevanja uporabe EDI sistema glede na količino prenesenih podatkov.

Trditev 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.

Ugotovitev 3: S simulacijo “kot-je” procesa naročanja polizdelkov v poglavju 3.3.2. Analiziranje “kot-je” procesa naročanja polizdelkov na strani 67, smo ugotovili, da za izvajanje “kot-je” procesa potrebujemo 6 človeških virov (tabela 18):

• planer proizvodnje, ki je izkoriščen 38,46%, • direktor nabave, ki je izkoriščen 11,10%, • tajnica, ki je izkoriščena 8,80% ter • trije nabavni uslužbenci, ki so izkoriščeni 55,61%.

Z simulacijo “naj-bo” procesa naročanja polizdelkov v poglavju 3.3.3. Predlog prenove “naj-bo” modela procesa naročanja polizdelkov na strani 73, smo ugotovili, da za izvajanje potrebujemo 4 človeške vire (tabela 25, stran 80):

• planer proizvodnje, ki je izkoriščen 32,30%, • direktor nabave, ki je izkoriščen 2,34%, • tajnica, ki je izkoriščena 7,33% ter • nabavni uslužbenec, ki je praktično neizkoriščen. Njegova izkoriščenost je 0,01%. Potreben je

samo pri obveščanju dobavitelja o nečitljivem faksu.

Iz zgoraj napisanega lahko ugotovimo, da je potreba po človeških virih pri “naj-bo” procesu dejansko manjša pri vseh človeških virih, največ pri nabavnih uslužbencih. Če razliko med procenti pretvorimo v ure lahko ugotovimo, da je celotni čas potrebnih človeških virov za izvedbo primera “naj-bo” procesa krajši za 21,76 delovnih dni. Ugotovimo, da trditev 3 drži.

Trditev 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.

Ugotovitev 4: Ugotovimo lahko, da trditev 4 drži, saj se aktivnost pošiljanje dokumenta dobavitelju po faksu dejansko lahko popolnoma avtomatizira s pomočjo integracijske hrbtenice in faks strežnika.

Trditev 5: Trdimo, da je lahko prenos dokumentov med aktivnostmi v “naj-bo” procesu naročanja polizdelkov popolnoma elektronski.

Ugotovitev 5: Iz “naj-bo” modela procesa (slika 27, stran 75) lahko ugotovimo, da je prenos podatkov med vsemi aktivnostmi elektronski, razen pri odgovoru dobavitelja v primeru faksa, to je med aktivnostjo

99

sprejemanje odgovorov in vnašanje podatkov. Ti podatki pridejo v finančno-računovodski oddelek v obliki faksa, ki ga mora tajnica pretipkati v aplikaciji vnos odgovora na zahtevo in vnos odgovora na naročilnico. Če bi želeli, da bi bili tudi ti dve aktivnosti avtomatski, bi bilo potrebno kupiti drago opremo za skeniranje in optično razpoznavanje znakov, kar pa v tem primeru ni smiselno. Tako lahko ugotovimo, da trditev 5 ne drži.

Trditev 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.

Ugotovitev 6: Za aktivnost pregledovanje odgovorov in primerjava z zahtevo smo v poglavju 3.4.3. Avtomatizacija aktivnosti in integracija uporabniških programov “naj-bo” procesa na strani 75, videli, da jo lahko popolnoma avtomatiziramo s pomočjo integracijske hrbtenice in WBI Message Broker orodja. Trditev 6 lahko sprejmemo.

Trditev 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.

Ugotovitev 7: Rezultati študije povračila investicije za proces naročanja polizdelkov so naslednji: 1. ocena povračila investicije za “kot-je” proces je 5 let, ob sledečih predpostavkah (stran 67, poglavje

3.3.2. Analiziranje “kot-je” procesa naročanja polizdelkov): • “naj-bo” proces naročanja polizdelkov je eden izmed treh procesov, ki se bodo istočasno

izvajali na BPM sistemu, • za izvajanje “naj-bo” procesa je potreben en nabavni uslužbenec manj, • stroški izvajanja “kot-je” procesa se s simulacijo ocenjuje na 200.000,00 EUR, • stroški “naj-bo” procesa bodo polovični stroški “kot-je” procesa.

2. ocena povračila investicije za “naj-bo” proces je 17 mesecev, zaradi sledečih rezultatov (stran 73, poglavje 3.3.3. Predlog prenove “naj-bo” modela procesa naročanja polizdelkov): • stroški izvajanja “naj-bo” procesa so 34.000,00 EUR letno, • pojavi se presežek človeških virov, ki lahko opravljajo druga dela. Odštejemo lahko strošek

dveh nabavnih uslužbencev, ki je 80.000,00 EUR, in predpostavk: • “naj-bo” proces naročanja polizdelkov je eden izmed treh procesov, • stroški izvajanja “kot-je” procesa se s simulacijo ocenjujejo na 200.000,00 EUR.

3. iz dejanskih rezultatov izvajanja procesa naročanja polizdelkov lahko izračunamo, da se bo investicija povrnila v 16. mesecih, ob naslednjih rezultatih (stran 91, poglavje 3.6.2. Analiziranje zgodovine izvajanja “naj-bo” procesa): • dejanski stroški izvajanja “naj-bo” procesa so 27.000,00 EUR letno, • pojavi se presežek človeških virov, ki lahko opravljajo druga dela. Odštejemo lahko strošek

dveh nabavnih uslužbencev, ki je 80.000,00 EUR,

100

in predpostavk: • “naj-bo” proces naročanja polizdelkov je eden izmed treh procesov, • stroški izvajanja “kot-je” procesa se s simulacijo ocenjujejo na 200.000,00 EUR.

Iz zgoraj naštetih časov povračil investicij lahko ugotovimo, da trditev 6 velja, saj je izračun pokazal, da se bo strošek investicije povrnil v 16. mesecih.

Trditev 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.

Ugotovitev 8: Utežnostna povprečja stroškov virov in časov trajanja procesa za “kot-je” in “naj-bo” procesa, dobljena s simulacijo ter z “naj-bo” izvajanjem procesa naročanja polizdelkov, dobljena iz resničnih podatkov, so prikazana v tabeli 35:

Tabela 35: Utežnostna povprečja stroškov virov in časa trajanja procesa naročanja polizdelkov

Proces naročanja polizdelkov

Čas trajanja procesa [dan]

Strošek virov [EUR]

“kot-je” (simulacija) 8,97 213,03 “naj-bo” (simulacija) 2,60 44,75 “naj-bo” (izvajanje) 2,51 43,25

Iz tabele 35 tako lahko ugotovimo, da je resnični proces v izvajanju v povprečju hitrejši za 6,46 dni oz. 357,00%. Povprečni stroški izvajanja primera procesa so nižji za 169,78 EUR oz. 492,50%. S tem je trditev 8 potrjena.

V tem magistrskem delu je prikazan pristop k prenovi poslovnih procesov na podlagi metodologije managementa poslovnih procesov. Doprinos znanosti predstavlja dejstvo, da je ta metodologija uporabljena na praktičnem primeru procesa naročanja polizdelkov. Na praktičnem primeru je prikazano modeliranje, analiziranje, ponovno snovanje, dajanje v izvajalno okolje, izvajanje in nadzorovanje ter analiziranje izvajanja poslovnega procesa. To je prvi tak primer uporabe celovitega BPM sistema (IBM WebSphere programska oprema) v Sloveniji.

Nadaljevanje praktičnega dela magistrskega dela bi lahko potekalo v dveh smereh. Prva smer bi lahko bila optimalizacija procesa naročanja polizdelkov, prenova ostalih procesov v nabavni verigi ter prenova procesov v ostalih oddelkih. Druga smer bi lahko bila bolj tehnične narave. IBM je pred kratkim izdal novo verzijo BPM sistema (IBM WebSphere Business Integration Server Foundation) in orodij za modeliranje (IBM WebSphere Business Integration Modeler V5). To je programska oprema, ki predstavlja novo generacijo BPM orodij, kodiranih in namenjenih za izvajanje v J2EE okolju. S pomočjo teh orodij bi bilo zanimivo še enkrat implementirati praktični primer procesa naročanja polizdelkov ter na koncu primerjati rezultate.

101

5. LITERATURA IN VIRI LITERATURA

1. Adams Cary W., Wilson Charles E., Reiger Perry spletna stran. 12.12.2004. [URL: http://www.adamssixsigma.com/Newsletters/TQM_six_sigma_differences_similarities.htm].

2. Attaran Mohsen, Attaran Sharmin: The rebirth of re-engineering: X-engineering. Business Process Management Journal, Bakersfield, School of Business and Public Administration, California State University, Volume 10, Number 4, 2004, str. 415-429.

3. Bajec A. et al.: Slovar slovenskega knjižnega jezika. SAZU in DZS, 1994. 1077 str.

4. Bosilj Vukšić Vesna, Kovačič Andrej: Upravljanje poslovnim procesima. Zagreb: Sinergija-nakladništvo d.o.o., 2004. 180 str.

5. Bosilj-Vukšić Vesna, Ćurko Katarina, Kovačič Andrej: Business Provess Restructuring in Croatioan and Slovenian Companies: A Comparison. Management Journal. Zagreb, Ekonomski fakultet, Volume 5, Number 1, 2000, [URL: http://www.efst.hr/management/ Vol5No1-2000/3-vuksic-slozeno.doc]

6. Česen Primož: Reinženiring poslovanja. Magistrsko delo. Ljubljana, Ekonomska fakulteta, 1998. 113 str.

7. Champy James: X-Engineering The Corporation: Reinventing Your Business In The Digital Age. New York: Warner Books, 2002. 232 str.

8. Davenport Thomas H, Short James E.: The New Industrial Engineering: Information Technology and Business Process Redesign. Sloan Management Review, Volume 31, Number 4, 1990, str. 11-27.

9. Davenport Thomas H.: Process Innovation: Reengineering Work through Information Technology. Boston: Harvard Business School Press, 1993. 336 str.

10. Davenport Thomas H., Harris Jeanne G., Cantrell Susan: Enterprise systems and ongoing process change. Business Process Management Journal. Cambridge, Volume 10, Number 1, 2004, str. 16-26.

11. Deborin Eugene et al.: Continous Business Process Management with Holosofx BPM Suite and IBM MQSeries Workflow. Research Triangle Park, North Carolina: IBM International Technical Support Organization, 2002. 534 str.

12. Eisner Howard: Reengineering Yourself and Your Company: From Engineer to Manager to Leader. Boston: Artech House, 2000. 289 str.

13. Gartner Group: Nine Reasons Why IS Organizations Do Not Do BPM. 5.12.1997 [URL: http://www4.gartner.com/DisplayDocument?ref=g_search&id=297270]

14. Gavin Lee et al.: A B2B Solution Using WebSphere Business Integration V4.1 and WebSphere Business Connection V1.1. Research Triangle Park, North Carolina: IBM International Technical Support Organization, 2003. 488 str.

15. Gavin Lee et al.: Business Integration Management Using WebSphere BI Modeler and Monitor: A real world case study. Research Triangle Park, North Carolina: IBM International Technical Support Organization, 2004, 287 str.

16. Geršak Peter: Razvoj informacijskega sistema za skladiščno poslovanje. Diplomsko delo. Ljubljana: Fakulteta za strojništvo, 1997, 131 str.

17. Hammer Michael, Champy James: Reengineering the Corporation: A Manifesto for Business Revolution. New York: Harper Business, 1993. 223 str.

102

18. Hammer Michael, Champy James: Reengineering the Corporation: A Manifesto for Business Revolution. New York: Harper Business, 2001. 257 str.

19. Hammer Michael: The Agenda: What Every Business Must Do to Dominate the Decade. New York: Crown Business, 2001. 269 str.

20. Hammer Michael: How to Sell Change. Optimize Magazine, december 2001, [URL: http://www.optimizemag.com/showArticle.jhtml?articleID=17700630]

21. Hammer Michael: Process Management and The Future Of Six Sigma. MIT Sloan Management Review. Winter 2002, str. 30-42.

22. Harrington James H., Esseling E. K. C., Nimwegen H. Van: Business Process Improvement Workbook: Documentation, Analysis, Design, and Management of Business Process Improvement. New York: McGraw-Hill, 1997. 314 str.

23. Harmon Paul: Business Process Change: A Manager's Guide to Improving, Redesigning and Automationg Proceses. San Francisco: Morgan Kaufmann Publishers, 2003. 529 str.

24. Harmon Paul: Business Processes at a New Company: What Do You Do First? Business Process Trends Newsletter, Volume 2, Number 9, 2004. 12. str.

25. Hayes Ian: BAM Keeps A Finger On The Pulse. Optimize Magazine, januar 2005, [URL: http://www.optimizemag.com/article/showArticle.jhtml?articleId=56200330&pgno=1]

26. Kovačič Andrej, Peček Bojan:Prenova in informatizacija delovnih procesov. Ljubljana: Visoka upravna šola, Univerza v Ljubljani, 2002. 124 str.

27. Kovačič Andrej et al.: Prenova in informatizacija poslovanja. Ljubljana: Ekonomska fakulteta, 2004. 354 str.

28. Kovačič Andrej: Business renovation: business rules (still) the missing link. Business Process Management Journal, Ljubljana, Faculty of Economics, Slovenia:, Volume 10, Number 2, 2004a, str. 158-170.

29. Kovačič Andrej. Spletna stran z gradivi za predavanja. 5.1.2005. [URL: http://www.ef.uni-lj.si/predmeti/_struktura/izpis.asp?vrsta=gradivo&id=61810]

30. Leavitt, H. J.: Allied Organizational Change in Industry: Structural, Technological and Humanistic Approaches. Handbook of Organizations. Chicago: Rand McNally, March 1965, str. 1144-1170.

31. Medling Jan, Neumann Gustaf, Nuettgents Markus: A Comparison of XML Interchange Formats for Business Process Modelling. Dunaj: Vienna University of Economics, 2004. 12 str.

32. Palmisano J. Samuel: The New Agenda – IBM And the New On-Demand. Armonk: IBM Headquarter, 2002. 29 str.

33. Peruško Fabris: Prenova poslovnega procesa s študijo primera Slovenije. Magistrsko delo. Ljubljana: Ekonomska fakulteta, 2003. 116 str.

34. Porter, Michael E.: Competitive Strategy: Techniques for Analyzing Industries and Competitors. New York: The Free Press, 1980. 396 str.

35. Porter, Michael E.: Competitive Advantage: Creating and Sustaining Superior performance. New York: The Free Press, 1985. 557 str.

36. Van de Putte Geert et al.: Intra-Enterprise Business Process Management. Research Triangle Park, North Carolina: IBM International Technical Support Organization, 2001. 424 str.

103

37. Pyzdek, Thomas: The Six Sigma Project Planner: A Step-by-Step Guide to Leading a Six Sigma Project Through DMAIC. New York: McGraw-Hill Companies, 2003. 232 str.

38. Rummler Geary A., Branch Alan P.: Improving Performance: How to Manage the White Space on the Organization Chart. San Francisco: Jossey-Bass, 1990. 227 str.

39. Rozman Rudi: Management. Ljubljana: Gospodarski vestnik, 1993. 312 str.

40. Ross Ronald: Principles of the Business Rules Approach. Boston: Addison Wesley, 2003. 372 str.

41. Russell Steve: Six Critical BPM Capabilities Close the Loop for Success. KMWorld Magazine, Volume 14, Issue 1, januar 2005, [URL: http://www.kmworld.com/publications/magazine/index.cfm?action= readarticle&article_id=1978&publication_id=126

42. El Sawy Omar A.: Redesiging Enterprise Processes for e-Business. New York: McGraw-Hill Companies, 2001. 206 str.

43. Slak Matjaž, Geršak Peter: Kako podpreti poslovne procese? Sistem. Ljubljana: Infomediji d.o.o., maj 2002, str. 14-16.

44. Smith Howard, Fingar Peter: Business Process Management – The Third Wave. Tampa: Meghan-Kiffer Press, 2003. 292 str.

45. Smith Howard et al.: The Emergence of Business Process Management. B.k: CSC Research Services, 2002. 89 str.

VIRI

1. Van der Aalst W.M.P. et al.: Workflow Patterns and Advanced Workflow Patterns. Eindhoven: University of Technology, B.l.. 82 str.

2. Van der Aalst W.M.P., Van Hee Kees: Workflow Management: Models, Methods and Systems. Cambridge: The Massachusetts Institute of Technology Press, 2002. 368 str.

3. Adizes Ichak et al.: Človeku prijazno in uspešno vodenje. Ljubljana: Panta Rhei–Sinteza, 1996. 404 str.

4. Americas Conference in Information Systems. AMCIS 2004 Workshop: Business Process Automation. New York. [URL: http://www.workflow-research.de/Tutorials/AMCIS2004/]

5. Brett Charles: The Five Axes of Business Application Integration. Winchester: Spectrum Reports Ltd., 2003. 121 str.

6. Business Integration Journal Online [URL: http://www.bijonline.com/Default.asp]

7. Business Performance Management Magazine [URL: http://www.bpmmag.net/]

8. Business Process Management Group [URL: http://www.bpmg.org/]

9. Domajnko Tomaž: Ključ je v povezovanju (Integracija sistemov). Sistem. Ljubljana: Infomediji d.o.o., julij 2002, str. 16-18.

10. Fingar Peter, Aronica Ronald: Ten Myths of the New Economy. The Business Integrator Journal, Winchester, Fall 2001, str. 14-22.

11. Finkelstein Clive: Information Engineering. Sidney: Addison-Wesley, 1992. 660 str.

12. Gartner Group: Drivers for BPM: 11 Money-Relevant Reasons to Start. 25.2.2004 [URL: http://mediaproducts.gartner.com/reprints/handysoft/119839.html]

104

13. Gilman Len, Schreiber Richard: Distributed Computing with IBM MQSeries. New York: John Wiley & Sons, 1997. 283 str.

14. The Henry Ford Museum [URL: http://www.hfmgv.org/exhibits/showroom/1908/model.t.html]

15. Hentrich Carsten: Patterns and Templates for WebSphere MQ Workflow Based Process Driven Architectures. Oxford: The University of Oxford, 2004. 114 str.

16. Hollingsworth David: The Workflow Reference Model. Winchester: Workflow Management Coalition, 1995. 55 str.

17. IBM: Operating Environment essentials for an on demand breakthrough. Marec 2004. 32 str. [URL: http://www-306.ibm.com/software/info/openenvironment/pdfs/on-demand-oe4.pdf]

18. IBM Patterns for e-Business [URL: http://www-106.ibm.com/developerworks/patterns/]

19. IBM programska oprema spletne strani [URL: http://www.ibm.com/software]

20. ISO 9000 in ISO 9000:2000 spletna stran [http://www.iso.org ali http://www.iso.ch]

21. James Martin: Information Engineering. Lancashire: Savant Research Studies, 1986. 107 str.

22. Java Business Process Management [URL: http://www.jbpm.org/].

23. Kalakota Ravi, Robinson Marcia: e-Business 2.0 – Roadmap for Success. Boston: Addison-Wesley, 2001. 520 str.

24. Khorshid Hassan: The Past, Present and Future of Business Process Management. The Business Integrator Journal, Winchester, Summer 2001, str. 32-34.

25. Lewis Ryhs: Advanced Message Applications with MSMQ and MQSeries. Indianapolis: Macmillan Computer Publishing, 1999. 512 str.

26. Leyman Frank, Roller Diether: Production Workflow – Concepts and Techniques. Upper Saddle River, New Jersey: Prentice-Hall, 2000, 479 str.

27. May Margaret: Business Process Management – Integration in a Web Enabled Environment. London: Pearson Education Limited, 2003. 252 str.

28. Možina Stane, Tavčar Mitja, Kneževič Ana Nuša: Poslovno komuniciranje. Maribor: Obzorja, 1998. 511 str.

29. zur Muehlen, Michael: Process Management Standards Overview.Stevens Institute of Technology, 2003. 10 str. [URL: http://www.wfmc.org/standards/docs/Process_Management_Standards_files/frame.htm]

30. Open Applications Group: Technology Standars [URL: http://www.openapplications.org/]

31. QPR Software Plc: What is Balanced Scorecard? [URL: http://www.qpr.com/balancedscorecard/balanced_scorecard_intro.html]

32. Šest sigma priročnik [URL: http://sixsigmatutorial.com/].

33. Slovar informatike, Ekonomska fakulteta [URL: http://www.islovar.org/iskanje_enostavno.asp].

34. Sraka Robert: Pošlji mi sporočilo. Sistem. Ljubljana: Infomediji d.o.o., april 2002, str. 24-25.

35. Valiris George, Glykas Michalis: Business analysis metrics for business process redesign. Business Process Management Journal, Chios, Department of Business Administration, University of Aegean, Greece, Volume 10, Number 4, 2004, str. 445-480.

105

36. Wackerlow Dieter, Adam Winfried, Burton Dallas: MQSeries Workflow for Windows NT for Beginners. Research Triangle Park, North Carolina: IBM International Technical Support Organization, 2001. 149 str.

37. Whatis spletne strani. Razlaga pojmov informacijske tehnologije [URL: http://www.whatis.com].

38. WinterGreen Research, Inc: Application Integration (EAI) Market Opportunities, Strategies, and Forecasts, 2002 to 2007. [URL: http://www.wintergreenresearch.com/reports/pdf/EAIIndustry2002-2007.pdf], 2002.

39. The Workflow Management Coallition: Technology Standars [URL: http://www.wfmc.org/].

40. Workflow and Reengineering International Association: Workflow Vendors [URL: http://www.waria.com/].

6. PRILOGE

6.1. Slovar slovenskih prevodov tujih izrazov

Angleški pomen Slovenski pomen Activity Based Costing analiza stroškov aktivnosti Activity Diagram diagram aktivnosti Application to Application Integration točkovna integracija aplikacij As-Is model model obstoječega stanja Atomicity atomarnost Automation avtomatizacija Benchmarking primerjava s konkurenco Bug napaka v programski kodi Business Activity Monitoring nadzorovanje poslovnih aktivnosti Business Inteligence poslovna inteligenca Business Process Definition Metamodel metamodel za definicijo poslovnih procesov Business Process Execution Language jezik ja izvajanje poslovnih procesov Business Process Improvement izboljševanje poslovnih procesov Business Process Management management poslovnih procesov Business Process Management Language jezik za modeliranje poslovnih procesov Business Process Management Notation notacija za poslovne procese Business Process Management System sistem za management poslovnih procesov Business Process Reengineering prenova poslovnih procesov Business Process Specification Schema specifikacija sheme za poslovni proces Business Rules poslovna pravila Business Scorecards celovit sistem kazalnikov Case primer, primer poti Collaborative Commerce sodelovalno trgovanje Composite Applications sestavljenje aplikacije

Computer Aided Software Engineering informacijska orodja, ki pomagajo obvladovati vse vidike informatizacije

Condition pogoj Consistency doslednost Content Management management vsebin Control Flow kontrolni tok Could model lahko model Customer Relationship Management management odnosov s strankami Data podatki

106

Angleški pomen Slovenski pomen Database podatkovna baza Database Management System sistem za management podatkovnih baz Data Flow Diagram diagram toka podatkov Data Handling rokovanje s podatki Deadlock mrtva zanka Deployment postavitev v izvajanje Diagram Cycle Activity diagram cikla aktivnosti Dramatic dramatičen Durability obstojnost e-Business elektronsko poslovanje Enterprise Application Integration povezovanje uporabniških programov Electronic Data Interchange elektronska izmenjava podatkov Electronic Data Interchange For Administration, Commerce and Transport

elektronska izmenjava podatkov za administracijo, trgovino in transport

Enterprise Resource Planning celovite programske rešitve Enterprise Service Bus vodilo za integracijo aplikacij Entity Relationship entitetna povezava Event dogodek Event-Driven Process Chain Dogodkovno voden proces Exception izjema Extensible Markup Language jezik XML Flow Definition Language FDL jezik za opis poslovnih procesov Fundamental temeljni General splošno Graphic Position grafičen prikazt Hiper Text Transport Protocol protokol za prenos podatkov po internetu Information Technology informacijka tehnologija Instance (Process) primer procesa Instance Handling rokovanje s primeri Integration Broker integracijski posrednik Integration Mode integracijski način

Internet Business to Business elektronsko poslovanje med podjetji z uporabo svetovnega spleta

Is model je model Isolation izolacija Java Message Service javanska sporočilna storitev Java Server Page javanski strežniški program Just-in-Time Manufacturing JIT proizvodnja Knowledge Management management znanja Lean Manufacturing vitka proizvodnja Learning Organization učeča se organizacija Legacy application zaledna aplikacija Location pozicija Loosely Coupled ohlapna povezava Message Broker posrednik sporočil Message Flow WBI Message Broker uporabniška aplikacija Message Flow Project WBI Message Broker projekt za uporabniško aplikacijo Message Queue sporočilna vrsta Message Queue Server strežnik za sporočilne vrste Messaging Backbone sporočilna hrbtenica Metric mera Middleware vmesno programje

107

Angleški pomen Slovenski pomen On-Demand na zahtevo On-Demand Architecture arhitektura On-Demand Outsourcing predajanje nestrateških procesov v zunanjim izvajalcem Partner Link Type tip partnerske povezave People ljudje Performance zmogljivost Process proces Process Oriented Architecture procesno orientira arhitektura Program Execution Server strežnik za izvajanje aplikacij Protocol protokol Pull Market Model potezni model tržišča Quality Attribute atribut kakovosti Radical korenit Repository Shramba podatkov Role vloga Service Oriented Architecture servisno orientirana arhitektura Service Oriented Enterprise storitveno orientirano podjetje Should model bo model Six Sigma šest sigma Six Sigma Black Belt šest sigma črni pas Six Sigma Green Belt šest sigma zeleni pas Six Sigma Master Black Belt šest sigma mojster črnega pasu Smart Middleware nteligentno vmesno programje Staff Assignment dodeljevanje osebja Statistical Data statistični podatki Statistical Process Control statistična kontrola procesa Storage Area Network diskovna polja Structure struktura Structured Query Language strukturiran jezik SQL za poizvedbe Supply Chain Management management oskrbovalne verige Table Space podatkovni prostor Task Naloga, enota dela Task Address naslov enote dela Technology tehnologija To-Be model kot naj bo model Top-Down od vrha navzdol Total Cost of Ownership skupni stroški lastništva Total Quality Management celovit management kakovosti Transaction transakcija Transaction Monitor nadzornik transakcij Unified Modeling Language poenoten jezik modeliranja User Program Execution Server uporabniški strežnik za izvajanje aplikacij Value Chain vrednostna veriga Web Application Server spletni aplikacijski strežnik WebSphere Business Integration WebSphere programska oprema za poslovno integracijo What If? Kaj če? Workflow delovni tok Workflow Management System sistem za management delovnega toka Workload razdelitev dela Web Services spletne storitve X-engineering X-inženiring Y2K Bug napaka drugega tisočletja

108

6.2. Opis uporabljenih kratic

Kratica Slovenski pomen Angleški opis A2A integracija aplikacij Application to Application Integration ABC analiza stroškov aktivnosti Activity Based Costing ACID atomarnost, doslednost, izolacija in obstojnost Atomicity, Consistency, Isolation, Durability BAM nadzorovanje poslovnih aktivnosti Business Activity Monitoring B2B oz. B2Bi

elektronsko poslovanje med podjetji z uporabo svetovnega spleta Internet Business to Business

BI poslovna inteligenca Business Inteligence BPDM metamodel za definicijo poslovnih procesov Business Process Definition Metamodel BPEL BPEL jezik ja izvajanje poslovnih procesov Business Process Execution Language BPI izboljševanje poslovnih procesov Business Process Improvement BPM management poslovnih procesov Business Process Management BPML BPML jezik za modeliranje poslovnih procesov Business Process Management Language BPMN notacija za poslovne procese Business Process Management Notation BPMS sistem za management poslovnih procesov Business Process Management System BPR prenova poslovnih procesov Business Process Reengineering BPSS specifikacija sheme za poslovni proces Business Process Specification Schema BSC celovit sistem kazalnikov Business Scorecards

CASE informacijska orodja, ki pomagajo obvladovati vse vidike informatizacije Computer Aided Software Engineering

CM management vsebin Content Management CRM management odnosov s strankami Customer Relationship Management DB podatkovna baza Database DBMS sistem za management podatkovnih baz Database Management System

DDL jezik za definicijo podatkov in relacijskih baz podatkov Data Definition Language

DFD diagram toka podatkov Data Flow Diagram

DML Jezik za manipulacijo podatkov v relacijskih bazah podatkov Data Manipulation Language

EAI povezovanje uporabniških programov Enterprise Application Integration

ebXML standarden jezik in določena XML struktura podatkov za elektronsko imenjavo podatkov po internetu

e-Business XML

EDI elektronska izmenjava podatkov Electronic Data Interchange

EDIFact elektronska izmenjava podatkov za administracijo, trgovino in transport

Electronic Data Interchange For Administration, Commerce and Transport

eEPC eEPC diagram poteka poslovnega procesa Extended Event Process Chain EPML EPML jezik za opis poslovnega procesa Event-Driven Process Chain Markup Language ER entitetna povezava Entity Relationship EPC Dogodkovno voden proces Event-Driven Process Chain ERP celovite programske rešitve Enterprise Resource Planning ESB vodilo za integracijo aplikacij Enterprise Service Bus FDL FDL jezik za opis poslovnih procesov Flow Definition Language HTTP HTTP protokol za prenos podatkov po internetu Hiper Text Transport Protocol IDEF IDEF jezik za modeliranje operacij v podjetju Integrated DEFinition IBM podjetje IBM International Business Machines IT informacijka tehnologija Information Technology J2EE javansko okolje za razvoj in izvajanje verzija 2 Java 2 Enterprise Edition JIT JIT proizvodnja Just-in-Time Manufacturing JMS javanska sporočilna storitev Java Message Service JSP javanski strežniški program Java Server Page

109

Kratica Slovenski pomen Angleški opis KM management znanja Knowledge Management MQ sporočilna vrsta Message Queue MQS strežnik za sporočilne vrste Message Queue Server OWL-S OWL-S jezik za opis poslovnega procesa Web Ontology Language - Service PES strežnik za izvajanje aplikacij Program Execution Server POA procesno orientira arhitektura Process Oriented Architecture

PNML jezik za modeliranje poslovnega proces na osnovi Petrijevih mrež Petri Net Markup Language

SADT SADT diagrami za opis poslovnega procesa Structured Analysis and Design Techniques SAN diskovna polja Storage Area Network SCM management oskrbovalne verige Supply Chain Management SOA servisno orientirana arhitektura Service Oriented Architecture SOAP jezik SOAP SOAP language SOE storitveno orientirano podjetje Service Oriented Enterprise SPC statistična kontrola procesa Statistical Process Control

SQL strukturiran jezik SQL za poizvedbe (po podatkovnih bazah) Structured Query Language

TCO skupni stroški lastništva Total Cost of Ownership TM nadzornik transakcij Transaction Monitor TQM celovit management kakovosti Total Quality Management UDDI opis, odkrivanje in integracija spletnih storitev Universal Description, Discovery and Integration UML poenoten jezik modeliranja Unified Modeling Language UPES uporabniški strežnik za izvajanje aplikacij User Program Execution Server URL enoznačno določen internetni naslov Uniform Resource Locator WAS spletni aplikacijski strežnik Web Application Server

WBI WebSphere programska oprema za poslovno integracijo WebSphere Business Integration

WF delovni tok Workflow WFMS sistem za management delovnega toka Workflow Management System WS spletne storitve Web Services WSCDL WSCDL jezik za koreografijo spletnih storitev Web Service Choreography Description Language WSCL WSCL jezik za koreografijo spletnih storitev Web Service Choreography Language WSCI interface za koreografijo spletnih storitev Web Service Choreography Interface WSDL jezik za definicijo spletnih storitev Web Services Definition Language WSFL WSFL jezik za opis poteka poslovnega procesa Web Service Flow Language XML jezik XML Extensible Markup Language XE X-inženiring X-engineering XLANG XLANG jezik za izvajanje poslovnih procesov eXecution LANGuage (MicroSoft) XPDL XPDL jezik za opis poslovnega procesa XML Process Definition Language Y2K leto 2000 Year 2000

110

6.3. Primeri poti "kot-je" procesa naročanja

Primer poti 1:

Primer poti 2:

111

Primer poti 3:

Primer poti 4:

112

Primer poti 5:

Primer poti 6:

113

Primer poti 7:

Primer poti 8:

114

Primer poti 9:

115

6.4. "Kot-je" model procesa naročanja polizdelkov

116

6.5. Primeri poti "naj-bo" procesa naročanja

Primer poti 1:

Primer poti 2:

117

Primer poti 3:

Primer poti 4:

118

Primer poti 5:

Primer poti 6:

119

Primer poti 7:

Primer poti 8:

120

Primer poti 9:

Primer poti 10:

121

Primer poti 11:

Primer poti 12:

122

Primer poti 13:

Primer poti 14:

123

Primer poti 15:

Primer poti 16:

124

6.6. "Naj-bo" model procesa naročanja polizdelkov

125

6.7. "Kot-je" in "naj-bo" modeli procesa naročanja polizdelkov

Oba modela procesa naročanja polizdelkov sta na CD-ROM mediju pripeta na zadnji platnici magistrskega dela.

6.8. Opis tabel v JPK bazi podatkov v DDL jeziku

-- Create Tables Create table JPK.DOBAVITELJ ( SFDOB Integer NOT NULL, NACINPOSIL Varchar(10) NOT NULL, IME Varchar(100) NOT NULL, ULICA Varchar(100) NOT NULL, MESTO Varchar(100) NOT NULL, POSTA Varchar(30) NOT NULL, DRZAVA Varchar(50) NOT NULL, TELEFON Varchar(20) NOT NULL, FAKS Varchar(20) NOT NULL, KONTAKT Varchar(100) NOT NULL, EPOSTA Varchar(100))

Create table JPK.POLIZDELKI ( SFPOLIZDJPK Integer NOT NULL, IMEPOLIZDJPK Varchar(100) NOT NULL, CENAJPK Decimal(10,2))

Create table JPK.NAROCILA ( SFNAR Integer NOT NULL, CASZIGZAH Varchar(30) NOT NULL, CASZIGZAHODG Varchar(30), CCENAZAHJPK Decimal(10,2) NOT NULL, CCENAZAHODG Decimal(10,2), KOLICINAZAH Integer NOT NULL, KOLICINADOB Integer, CENAZAHDOB Decimal(10,2), ZAHTEVANADOB Char(1), CASZIGNAR Varchar(30), CASZIGNARODG Varchar(30), CCENANARJPK Decimal(10,2), CCENANARODG Decimal(10,2), KOLICINANAR Integer, ODOBRENANAR Char(1), OPOMBA Varchar(200))

Create table JPK.DOB_POLIZD ( SFPOLIZDJPK Integer NOT NULL, SFDOB Integer NOT NULL,

Create table JPK.NAR_POLIZD ( SFNAR Integer NOT NULL, SFPOLIZDJPK Integer NOT NULL)

-- Create Primary Keys Alter table JPK.DOBAVITELJ add primary key (SFDOB,SFNAR) Alter table JPK.POLIZDELKI add primary key (SFPOLIZDJPK) Alter table JPK.NAROCILA add primary key (SFNAR) Alter table JPK.DOB_POLIZD add primary key (SFPOLIZDJPK,SFDOB) Alter table JPK.NAR_POLIZD add primary key (SFNAR,SFPOLIZDJPK)

-- Create Foreign Keys Alter table JPK.DOB_POLIZD add foreign key (SFDOB,SFNAR) references DOBAVITELJ (SFDOB,SFNAR) on update cascade on delete restrict Alter table JPK.DOB_POLIZD add foreign key (SFPOLIZDJPK) references POLIZDELKI (SFPOLIZDJPK) on update cascade on delete restrict Alter table JPK.NAR_POLIZD add foreign key (SFPOLIZDJPK) references POLIZDELKI (SFPOLIZDJPK) on update cascade on delete restrict Alter table JPK.DOBAVITELJ add foreign key (SFNAR) references NAROCILA (SFNAR) on update cascade on delete restrict

126

6.9. Opis vsebine tabel v JPK bazi podatkov v DML jeziku

INSERT INTO DOBAVITELJ (SFDOB, NACINPOSIL , IME , ULICA , MESTO , POSTA , DRZAVA, TELEFON , FAKS , KONTAKT , EPOSTA ) VALUES ( 1001, 'Faks', 'Perun d.d.', 'Perunova 1', 'Ajdovgrad', 'SI-098762', 'Slovenija', '+386 1234567890', '+386 1234567891', 'ga. Bogomila Ajd', '[email protected]' )

INSERT INTO DOBAVITELJ ( SFDOB, NACINPOSIL , IME , ULICA , MESTO , POSTA , DRZAVA, TELEFON , FAKS , KONTAKT , EPOSTA ) VALUES ( 1002, 'Faks', 'Fahrrad AG', 'Schwarzstrasse 1', 'Hannover', 'DE-94234', 'Deutschland', '+42 1234567890', '+42 1234567891', 'Mrs. Helga Hartl', '[email protected]' )

INSERT INTO DOBAVITELJ ( SFDOB, NACINPOSIL , IME , ULICA , MESTO , POSTA , DRZAVA, TELEFON , FAKS , KONTAKT , EPOSTA ) VALUES ( 1003, 'EDI', 'Valhalla Ltd.', 'Ferstuu 1', 'Helsinki', 'FI-549045', 'Soumi', '+32 1234567890', '+32 1234567891', 'Mrs. Asa Freya', '[email protected]' )

INSERT INTO DOBAVITELJ ( SFDOB, NACINPOSIL , IME , ULICA , MESTO , POSTA , DRZAVA, TELEFON , FAKS , KONTAKT , EPOSTA ) VALUES ( 1004, 'EDI', 'Krpan d.o.o.', 'Martinova 1', 'Krpan', 'SI-87653', 'Slovenija', '+386 1234567890', '+386 1234567891', 'Mrs. Jedrt Krvina', '[email protected]' )

INSERT INTO DOBAVITELJ ( SFDOB, NACINPOSIL , IME , ULICA , MESTO , POSTA , DRZAVA, TELEFON , FAKS , KONTAKT , EPOSTA ) VALUES ( 1005, 'B2B', 'A.H.O.J.', 'Bratislavska 1', 'Kosice', 'SK-76307', 'Slovak', '+361 1234567890', '+361 1234567891', 'Mrs. Marketa Panova', '[email protected]' )

INSERT INTO DOBAVITELJ ( SFDOB, NACINPOSIL , IME , ULICA , MESTO , POSTA , DRZAVA, TELEFON , FAKS , KONTAKT , EPOSTA ) VALUES ( 1006, 'B2B', 'Atom r.o.', 'Zagabria 1', 'Sisak', 'HR-4347', 'Hrvatska', '+385 1234567890', '+385 1234567891', 'Mr. Jankec Tudman', '[email protected]' )

INSERT INTO DOBAVITELJ ( SFDOB, NACINPOSIL , IME , ULICA , MESTO , POSTA , DRZAVA, TELEFON , FAKS , KONTAKT , EPOSTA ) VALUES ( 1007, 'B2B', 'Franco Co.', 'Hola 1', 'Madrid', 'SP-10230', 'Espania', '+36 1234567890', '+36 1234567891', 'Mr. Francisco Franco', '[email protected]' )

INSERT INTO DOBAVITELJ ( SFDOB, NACINPOSIL , IME , ULICA , MESTO , POSTA , DRZAVA, TELEFON , FAKS , KONTAKT , EPOSTA ) VALUES ( 1008, 'B2B', 'Chang Kaishek', 'Taipei 1', 'Taipei', 'TW-857636', 'Taivan', '+87 1234567890', '+87 1234567891', 'Mr. Chang Kai-shek', '[email protected]' )

INSERT INTO DOBAVITELJ ( SFDOB, NACINPOSIL , IME , ULICA , MESTO , POSTA , DRZAVA, TELEFON , FAKS , KONTAKT , EPOSTA ) VALUES ( 1009, 'B2B', 'Mao Zedong Ltd.', 'Yellow River 1', 'Beijing', 'A1B2C042', 'PR China', '+2 1234567890', '+2 1234567891', 'Mr. Mao Zedong', '[email protected]' )

INSERT INTO DOBAVITELJ ( SFDOB, NACINPOSIL , IME , ULICA , MESTO , POSTA , DRZAVA, TELEFON , FAKS , KONTAKT , EPOSTA ) VALUES ( 1010, 'B2B', 'BushMan Co.', 'Oil Street 1', 'Houston, Texas', 'TX-345676', 'United States of America', '+1 1234567890', '+1 1234567891', 'Mrs. Georgia Washington', '[email protected]' ) INSERT INTO POLIZDELKI ( SFPOLIZDJPK , IMEPOLIZDJPK , CENAJPK ) VALUES ( 10001, 'Gonilka, navadna 160 mm', 10 ) INSERT INTO POLIZDELKI ( SFPOLIZDJPK , IMEPOLIZDJPK , CENAJPK ) VALUES ( 10002, 'Gonilka, gorska 150 mm', 10 ) INSERT INTO POLIZDELKI ( SFPOLIZDJPK , IMEPOLIZDJPK , CENAJPK ) VALUES ( 10003, 'Pedalo tip 30', 10 ) INSERT INTO POLIZDELKI ( SFPOLIZDJPK , IMEPOLIZDJPK , CENAJPK ) VALUES ( 10004, 'Pedalo tip 20', 10 ) INSERT INTO POLIZDELKI ( SFPOLIZDJPK , IMEPOLIZDJPK , CENAJPK ) VALUES ( 10005, 'Kolo, navadno, aluminij 19"', 10 ) INSERT INTO POLIZDELKI ( SFPOLIZDJPK , IMEPOLIZDJPK , CENAJPK ) VALUES ( 10006, 'Kolo, gorsko, aluminij 24"', 10 ) INSERT INTO POLIZDELKI ( SFPOLIZDJPK , IMEPOLIZDJPK , CENAJPK ) VALUES ( 10007, 'Kolo, gorsko, aluminij 26"', 10 ) INSERT INTO POLIZDELKI ( SFPOLIZDJPK , IMEPOLIZDJPK , CENAJPK ) VALUES ( 10008, 'Kolo, navadno, jeklo 19"', 10 ) INSERT INTO POLIZDELKI ( SFPOLIZDJPK , IMEPOLIZDJPK , CENAJPK ) VALUES ( 10009, 'Kolo, gorsko, jeklo 24"', 10 ) INSERT INTO POLIZDELKI ( SFPOLIZDJPK , IMEPOLIZDJPK , CENAJPK ) VALUES ( 10010, 'Kolo, gorsko, jeklo 26"', 10 ) INSERT INTO DOB_POLIZD ( SFPOLIZDJPK , SFDOB ) VALUES ( 10001, 1001 ) INSERT INTO DOB_POLIZD ( SFPOLIZDJPK , SFDOB ) VALUES ( 10002, 1002 ) INSERT INTO DOB_POLIZD ( SFPOLIZDJPK , SFDOB ) VALUES ( 10003, 1003 ) INSERT INTO DOB_POLIZD ( SFPOLIZDJPK , SFDOB ) VALUES ( 10004, 1004 ) INSERT INTO DOB_POLIZD ( SFPOLIZDJPK , SFDOB ) VALUES ( 10005, 1005 ) INSERT INTO DOB_POLIZD ( SFPOLIZDJPK , SFDOB ) VALUES ( 10006, 1006 ) INSERT INTO DOB_POLIZD ( SFPOLIZDJPK , SFDOB ) VALUES ( 10007, 1007 ) INSERT INTO DOB_POLIZD ( SFPOLIZDJPK , SFDOB ) VALUES ( 10008, 1008 ) INSERT INTO DOB_POLIZD ( SFPOLIZDJPK , SFDOB ) VALUES ( 10009, 1009 ) INSERT INTO DOB_POLIZD ( SFPOLIZDJPK , SFDOB ) VALUES ( 10010, 1010 )

127

6.10. Opis "naj-bo" procesa naročanja polizdelkov v FDL jeziku /* * FDL definitions generated by MQ Workflow at 2005-04-29, 09:49:40. */ CODEPAGE 1252 FM_RELEASE V3R4 0 /* * STRUCTUREs */ UPDATE STRUCTURE 'NaslovDobavitelja' 'Sifra': STRING; 'Ime': STRING; 'Ulica': STRING; 'Mesto': STRING; 'Posta': STRING; 'Drzava': STRING; 'Telefon': STRING; 'Faks': STRING; 'Kontakt': STRING; END 'NaslovDobavitelja' UPDATE STRUCTURE 'ZahtevaPodatki' 'SifraJPK': STRING; 'ImeJPK': STRING; 'KolicinaJPK': STRING; 'CenaJPK': STRING; 'SifraDobavitelj': STRING; 'ImeDobavitelj': STRING; 'KolicinaDobavitelj': STRING; 'CenaDobavitelj': STRING; END 'ZahtevaPodatki' UPDATE STRUCTURE 'NarocilnicaPodatki' 'SifraJPK': STRING; 'ImeJPK': STRING; 'KolicinaJPK': STRING; 'CenaJPK': STRING; 'SifraDobavitelj': STRING; 'ImeDobavitelj': STRING; 'KolicinaDobavitelj': STRING; 'CenaDobavitelj': STRING; END 'NarocilnicaPodatki' UPDATE STRUCTURE 'ZahtevaPolizdelek' 'DatumInCas': STRING; 'DatumInCasOdgovor': STRING; 'CelotnaCenaJPK': STRING; 'CelotnaCenaDobavitelj': STRING; 'ZahtevanaDobava': STRING; 'ZahtevaPodatki': 'ZahtevaPodatki'; END 'ZahtevaPolizdelek' UPDATE STRUCTURE 'NarocilnicaPolizdelek' 'DatumInCas': STRING; 'DatumInCasOdgovor': STRING; 'CelotnaCenaJPK': STRING; 'CelotnaCenaDobavitelj': STRING; 'NarocilnicaOdobrena': STRING; 'NarocilnicaPodatki': 'NarocilnicaPodatki'; END 'NarocilnicaPolizdelek' UPDATE STRUCTURE 'S_NP' 'StDokumenta': STRING; 'NacinPosiljanja': STRING; 'NaslovDobavitelja': 'NaslovDobavitelja'; 'ZahtevaPolizdelek': 'ZahtevaPolizdelek'; 'NarocilnicaPolizdelek': 'NarocilnicaPolizdelek'; 'Opomba': STRING; END 'S_NP' /* * PROGRAMs */ UPDATE PROGRAM 'ERP sistem' ( 'S_NP', 'S_NP' ) NO STRUCTURES_FROM_ACTIVITY UNATTENDED EXECUTION_MODE NORMAL WINNT EXE PATH_AND_FILENAME "fmcnshow.exe" INHERIT ENVIRONMENT STYLE VISIBLE NO START FOREGROUND END 'ERP sistem' UPDATE PROGRAM 'EDI sistem' ( 'S_NP', 'S_NP' ) NO STRUCTURES_FROM_ACTIVITY UNATTENDED EXECUTION_MODE NORMAL WINNT EXE PATH_AND_FILENAME "fmcnshow.exe" INHERIT ENVIRONMENT STYLE VISIBLE NO START FOREGROUND END 'EDI sistem' UPDATE PROGRAM 'Integracijska hrbtenica' ( 'S_NP', 'S_NP' )

NO STRUCTURES_FROM_ACTIVITY UNATTENDED EXECUTION_MODE NORMAL WINNT EXE PATH_AND_FILENAME "fmcnshow.exe" INHERIT ENVIRONMENT STYLE VISIBLE NO START FOREGROUND END 'Integracijska hrbtenica' PROGRAM 'PregledZahteveZaDobavoVERP' ( 'S_NP', 'S_NP' ) DESCRIPTION "" NO STRUCTURES_FROM_ACTIVITY NOT UNATTENDED WINNT EXE PATH_AND_FILENAME "fmcnshow.exe" INHERIT ENVIRONMENT STYLE VISIBLE START FOREGROUND END 'PregledZahteveZaDobavoVERP' PROGRAM 'DobaviteljevProcesZahteva' ( 'S_NP', 'S_NP' ) DESCRIPTION "" NO STRUCTURES_FROM_ACTIVITY NOT UNATTENDED WINNT EXE PATH_AND_FILENAME "fmcnshox.exe" INHERIT ENVIRONMENT STYLE VISIBLE START FOREGROUND END 'DobaviteljevProcesZahteva' PROGRAM 'SprejemInVnosOdgovorov' DESCRIPTION "" STRUCTURES_FROM_ACTIVITY NOT UNATTENDED WINNT EXE PATH_AND_FILENAME "fmcnshow.exe" INHERIT ENVIRONMENT STYLE VISIBLE START FOREGROUND END 'SprejemInVnosOdgovorov' PROGRAM 'OdobritevNarocilnice' DESCRIPTION "" STRUCTURES_FROM_ACTIVITY NOT UNATTENDED WINNT EXE PATH_AND_FILENAME "fmcnshow.exe" INHERIT ENVIRONMENT STYLE VISIBLE START FOREGROUND END 'OdobritevNarocilnice' PROGRAM 'DobaviteljevProcesNarocilnica' DESCRIPTION "" STRUCTURES_FROM_ACTIVITY NOT UNATTENDED WINNT EXE PATH_AND_FILENAME "fmcnshow.exe" INHERIT ENVIRONMENT STYLE VISIBLE START FOREGROUND END 'DobaviteljevProcesNarocilnica' PROGRAM 'SprejemInVnosOdgovorov_01' DESCRIPTION "" STRUCTURES_FROM_ACTIVITY NOT UNATTENDED WINNT EXE PATH_AND_FILENAME "fmcnshow.exe" INHERIT ENVIRONMENT STYLE VISIBLE START FOREGROUND END 'SprejemInVnosOdgovorov_01' /* * PERSONs */ UPDATE PERSON 'ADMIN' AUTHORIZED_FOR STAFF AUTHORIZED_FOR AUTHORIZATION AUTHORIZED_FOR OPERATION AUTHORIZED_FOR TOPOLOGY AUTHORIZED_FOR PROCESS_MODELING AUTHORIZED_FOR PROCESS_CATEGORY ALL AS_ADMINISTRATOR AUTHORIZED_FOR WORKITEMS_OF ALL PASSWORD %F5E2FF2FA2F06A33133BEE48DB1ED773 IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'ADMIN' UPDATE PERSON 'NOVAK' LAST_NAME "Novak" FIRST_NAME "Janez" PASSWORD %CDD299F870888EE74CF9FCA89EA86D3C IS_NOT_ABSENT

128

DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'NOVAK' UPDATE PERSON 'BAGARA' LAST_NAME "Bagara" FIRST_NAME "Janez" PASSWORD %F0DF50647038DBA8E5A6143F90141804 IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'BAGARA' UPDATE PERSON 'STROJ' LAST_NAME "Stroj" FIRST_NAME "Janez" PASSWORD %63C8296C1B4AA196E12EE0C185A89363 IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'STROJ' UPDATE PERSON 'BAJT' LAST_NAME "Bajt" FIRST_NAME "Janez" PASSWORD %C6DE2BD1E58C86B21CAE1343D0B04049 IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'BAJT' UPDATE PERSON 'TOLAR' LAST_NAME "Tolar" FIRST_NAME "Liza" PASSWORD %8A544969D26AEF775AE86741F837FE45 IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'TOLAR' UPDATE PERSON 'BUCAR' LAST_NAME "Bucar" FIRST_NAME "Janez" PASSWORD %F1AD57992E5FBA047DC0C2AF82667F10 IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'BUCAR' UPDATE PERSON 'WFADMIN' LAST_NAME "WFADMIN" AUTHORIZED_FOR STAFF AUTHORIZED_FOR AUTHORIZATION AUTHORIZED_FOR OPERATION AUTHORIZED_FOR TOPOLOGY AUTHORIZED_FOR PROCESS_MODELING PASSWORD %542EF34B2C6973FE1C4CE255DB983A18 IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'WFADMIN' UPDATE PERSON 'AUTOMATIC' AUTHORIZED_FOR STAFF AUTHORIZED_FOR AUTHORIZATION AUTHORIZED_FOR OPERATION AUTHORIZED_FOR TOPOLOGY AUTHORIZED_FOR PROCESS_MODELING AUTHORIZED_FOR PROCESS_CATEGORY ALL AS_ADMINISTRATOR AUTHORIZED_FOR WORKITEMS_OF ALL PASSWORD %8E3D5677655870206C03C51565E7DA53 IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'AUTOMATIC' UPDATE PERSON 'STRUCKO' LAST_NAME "Strucko" FIRST_NAME "Janez" SUBSTITUTE 'BAJT' PASSWORD %84277111F7CC9673939F23F6292F797D IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'STRUCKO' UPDATE PERSON 'TRDINA' LAST_NAME "TRDINA"

FIRST_NAME "JANEZ" SUBSTITUTE 'BUCAR' PASSWORD %02AD91F1F76AFBD6DF9962B195570CC6 IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'TRDINA' UPDATE PERSON 'TIPKA' LAST_NAME "Tipka" FIRST_NAME "Liza" SUBSTITUTE 'TOLAR' PASSWORD %AB1A23DA4F4EC154CC268716DCE7D68C IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'TIPKA' UPDATE PERSON 'ZABEL' LAST_NAME "Zabel" FIRST_NAME "Janez" PASSWORD %DCC35AFA37B5C0EA887B0C26683FD72E IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'ZABEL' UPDATE PERSON 'GORSE' LAST_NAME "Gorse" FIRST_NAME "Janez" SUBSTITUTE 'ZABEL' PASSWORD %801041FBA5041FE55E236A6BA6FC699D IS_NOT_ABSENT DO NOT RESET_ABSENT GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'GORSE' UPDATE PERSON 'ZABEL' SUBSTITUTE 'GORSE' GROUP 'FMCGRP' SYSTEM 'FMCSYS' END 'ZABEL' /* * ROLEs */ UPDATE ROLE 'System administrator' RELATED_PERSON 'ADMIN' END 'System administrator' UPDATE ROLE 'Planer proizvodnje' RELATED_PERSON 'BAGARA' END 'Planer proizvodnje' UPDATE ROLE 'Nabavni usluzbenec' RELATED_PERSON 'GORSE' 'ZABEL' END 'Nabavni usluzbenec' UPDATE ROLE 'Tajnica' RELATED_PERSON 'TIPKA' END 'Tajnica' UPDATE ROLE 'Informatik' RELATED_PERSON 'STRUCKO' 'WFADMIN' END 'Informatik' UPDATE ROLE 'Direktor nabave' RELATED_PERSON 'NOVAK' END 'Direktor nabave' UPDATE ROLE 'Direktor razvoja' RELATED_PERSON 'BUCAR' END 'Direktor razvoja' UPDATE ROLE 'Financno racunovodski direktor' RELATED_PERSON 'TOLAR' END 'Financno racunovodski direktor' UPDATE ROLE 'Direktor informatike' RELATED_PERSON 'BAJT' END 'Direktor informatike' UPDATE ROLE 'Direktor proizvodnje' RELATED_PERSON 'STROJ' END 'Direktor proizvodnje' UPDATE ROLE 'Automatic' RELATED_PERSON 'AUTOMATIC' END 'Automatic' /* * ORGANIZATIONs */

129

UPDATE ORGANIZATION 'Oddelek nabave' MANAGER 'NOVAK' RELATED_PERSON 'GORSE' 'NOVAK' 'ZABEL' END 'Oddelek nabave' UPDATE ORGANIZATION 'Oddelek razvoja' MANAGER 'BUCAR' RELATED_PERSON 'BUCAR' 'TRDINA' END 'Oddelek razvoja' UPDATE ORGANIZATION 'Oddelek proizvodnje' MANAGER 'STROJ' RELATED_PERSON 'BAGARA' 'STROJ' END 'Oddelek proizvodnje' UPDATE ORGANIZATION 'Oddelek informatike' MANAGER 'BAJT' RELATED_PERSON 'BAJT' 'STRUCKO' 'WFADMIN' END 'Oddelek informatike' UPDATE ORGANIZATION 'Financno racunovodski oddelek' MANAGER 'TOLAR' RELATED_PERSON 'TIPKA' 'TOLAR' END 'Financno racunovodski oddelek' /* * SERVERs */ UPDATE SERVER 'IZBRDOB' DESCRIPTION "Izbira dobavitelja in nacin posiljanja" RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "IZBIRA.DOB.NAC.POS" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'IZBRDOB' UPDATE SERVER 'PRGLDZAH' DESCRIPTION "Pregled zahteve za dobavo v ERP" RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "PREGLED.ZAHTEVE.ERP" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'PRGLDZAH' UPDATE SERVER 'ZAHFAKS' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "POSIL.ZAHTEVA.FAKS" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'ZAHFAKS' UPDATE SERVER 'ZAHEDI' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "POSIL.ZAHTEVA.EDI" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'ZAHEDI' UPDATE SERVER 'ZAHB2B' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "POSIL.ZAHTEVA.B2B" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'ZAHB2B' UPDATE SERVER 'ZAHSEDI' DESCRIPTION "Zahteva sprejem EDI"

RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "SPREJ.ZAHTEVA.EDI" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'ZAHSEDI' UPDATE SERVER 'ZAHSB2B' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "SPREJ.ZAHTEVA.B2B" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'ZAHSB2B' UPDATE SERVER 'NEPOTZAH' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "NEPOTRJENE.ZAHTEVE" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'NEPOTZAH' UPDATE SERVER 'NAREDI' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "POSIL.NAROCIL.EDI" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'NAREDI' UPDATE SERVER 'NARB2B' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "POSIL.NAROCIL.B2B" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'NARB2B' UPDATE SERVER 'NARFAKS' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "POSIL.NAROCIL.FAKS" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'NARFAKS' UPDATE SERVER 'NARSEDI' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "SPREJ.NAROCIL.EDI" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'NARSEDI' UPDATE SERVER 'NARSB2B' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "SPREJ.NAROCIL.B2B"

130

QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'NARSB2B' UPDATE SERVER 'NARERP' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "VNOS.NAROCIL.ERP" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'NARERP' UPDATE SERVER 'ZAHERP' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "VNOS.PODATKOV.ERP" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'ZAHERP' SERVER 'IZJEMA' RELATED_GROUP 'FMCGRP' RELATED_SYSTEM 'FMCSYS' TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER MQSYSTEM MQSERIES MESSAGE_FORMAT XML PHYSICAL_QUEUE_NAME "IZJEMA" QUEUE_MANAGER_NAME "FMCQM" VERSION 3 RELEASE 4 LEVEL 0 END 'IZJEMA' /* * PROCESSes */ /* * PROCESS NarocanjePolizdelkov */ UPDATE PROCESS 'NarocanjePolizdelkov' ( 'S_NP', 'S_NP' ) DO NOT PROMPT_AT_PROCESS_START VALID_FROM '2003-03-06 13:00:00' WINDOW ZOOM_FACTOR 70 WINDOW VIEW_REFERENCE_POINT XPOS -1350 YPOS 6023 WINDOW PAPERSIZE WIDTH 20000 HEIGHT 20000 WINDOW SHOW ALL CONNECTORS WINDOW SHOW NO CONDITIONS SOURCE 1 XPOS -9700 YPOS 9400 SINK 1 XPOS -1700 YPOS 9400 PROGRAM_ACTIVITY 'DobaviteljevProces' ( 'S_NP', 'S_NP' ) DESCRIPTION "DobaviteljevProcesZahteva.jsp" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -7400 YPOS 9400 NAME_POSITION XPOS -7400 YPOS 9325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'DobaviteljevProcesZahteva' SYNCHRONIZATION NESTED END 'DobaviteljevProces' PROGRAM_ACTIVITY 'DobaviteljevProces_01' ( 'S_NP', 'S_NP' ) DESCRIPTION "DobaviteljevProcesZahteva.jsp" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -7400 YPOS 9100 NAME_POSITION XPOS -7400 YPOS 9025 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'DobaviteljevProcesZahteva' SYNCHRONIZATION NESTED END 'DobaviteljevProces_01' PROGRAM_ACTIVITY 'DobaviteljevProces_02' ( 'S_NP', 'S_NP' ) DESCRIPTION "DobaviteljevProcesZahteva.jsp" START MANUAL WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -7400 YPOS 8800 NAME_POSITION XPOS -7400 YPOS 8725 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'DobaviteljevProcesZahteva' SYNCHRONIZATION NESTED END 'DobaviteljevProces_02'

PROGRAM_ACTIVITY 'DobaviteljevProces_03' ( 'S_NP', 'S_NP' ) DESCRIPTION "DobaviteljevProcesNarocilnica.jsp" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -3400 YPOS 9400 NAME_POSITION XPOS -3400 YPOS 9325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'DobaviteljevProcesNarocilnica' SYNCHRONIZATION NESTED END 'DobaviteljevProces_03' PROGRAM_ACTIVITY 'DobaviteljevProces_04' ( 'S_NP', 'S_NP' ) DESCRIPTION "DobaviteljevProcesNarocilnica.jsp" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -3400 YPOS 9100 NAME_POSITION XPOS -3400 YPOS 9025 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'DobaviteljevProcesNarocilnica' SYNCHRONIZATION NESTED END 'DobaviteljevProces_04' PROGRAM_ACTIVITY 'DobaviteljevProces_05' ( 'S_NP', 'S_NP' ) DESCRIPTION "DobaviteljevProcesNarocilnica.jsp" START MANUAL WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -3400 YPOS 8800 NAME_POSITION XPOS -3400 YPOS 8725 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'DobaviteljevProcesNarocilnica' SYNCHRONIZATION NESTED END 'DobaviteljevProces_05' PROGRAM_ACTIVITY 'IzbiranjeDobInNacPosiljanja' ( 'S_NP', 'S_NP' ) DESCRIPTION "IzbiranjeDobInNacPosiljanja" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -8800 YPOS 9400 NAME_POSITION XPOS -8800 YPOS 9325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'IZBRDOB' SYNCHRONIZATION NESTED END 'IzbiranjeDobInNacPosiljanja' PROGRAM_ACTIVITY 'ObvestiDobZaPonovnoPosiljanje' ( 'S_NP', 'S_NP' ) DESCRIPTION "ObvestiDobZaPonovnoPosiljanje" START MANUAL WHEN AT_LEAST_ONE CONNECTOR TRUE EXIT AUTOMATIC LAYOUT XPOS -5500 YPOS 8200 NAME_POSITION XPOS -5500 YPOS 8125 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'ObvestiDobZaPonovnoPosiljanje ' SYNCHRONIZATION NESTED END 'ObvestiDobZaPonovnoPosiljanje' PROGRAM_ACTIVITY 'OdobritevNarocilnice' ( 'S_NP', 'S_NP' ) DESCRIPTION "OdobritevNarocilnice.jsp" START MANUAL WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -5500 YPOS 9600 NAME_POSITION XPOS -5500 YPOS 9525 PRIORITY 0 DONE_BY ORGANIZATION 'Oddelek nabave' MEMBERS_ONLY DONE_BY MEMBER OF ROLE 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'OdobritevNarocilnice' SYNCHRONIZATION NESTED END 'OdobritevNarocilnice' PROGRAM_ACTIVITY 'PosiljanjeDokDob_B2B' ( 'S_NP', 'S_NP' ) DESCRIPTION "PosiljanjeDokDob_B2B" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -8100 YPOS 8800 NAME_POSITION XPOS -8100 YPOS 8725 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'ZAHB2B.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'PosiljanjeDokDob_B2B' PROGRAM_ACTIVITY 'PosiljanjeDokDob_B2B_01' ( 'S_NP', 'S_NP' ) DESCRIPTION "PosiljanjeDokDob_B2B_01" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -4100 YPOS 8800 NAME_POSITION XPOS -4100 YPOS 8725 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike'

131

PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'NARB2B.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'PosiljanjeDokDob_B2B_01' PROGRAM_ACTIVITY 'PosiljanjeDokDob_EDI' ( 'S_NP', 'S_NP' ) DESCRIPTION "PosiljanjeDokDob_EDI" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -8100 YPOS 9100 NAME_POSITION XPOS -8100 YPOS 9025 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' SUPPORT_TOOL 'Integracijska hrbtenica' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'ZAHEDI.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'PosiljanjeDokDob_EDI' PROGRAM_ACTIVITY 'PosiljanjeDokDob_EDI_01' ( 'S_NP', 'S_NP' ) DESCRIPTION "PosiljanjeDokDob_EDI_01" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -4100 YPOS 9100 NAME_POSITION XPOS -4100 YPOS 9025 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'NAREDI.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'PosiljanjeDokDob_EDI_01' PROGRAM_ACTIVITY 'PosiljanjeDokDob_Faks' ( 'S_NP', 'S_NP' ) DESCRIPTION "PosiljanjeDokDob_Faks" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -8100 YPOS 9400 NAME_POSITION XPOS -8100 YPOS 9325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Tajnica' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'ZAHFAKS.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'PosiljanjeDokDob_Faks' PROGRAM_ACTIVITY 'PosiljanjeDokDob_Faks_01' ( 'S_NP', 'S_NP' ) DESCRIPTION "PosiljanjeDokDob_Faks_01" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -4100 YPOS 9400 NAME_POSITION XPOS -4100 YPOS 9325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Tajnica' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'NARFAKS.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'PosiljanjeDokDob_Faks_01' PROGRAM_ACTIVITY 'PregledOdgovoraInPrimerjava' ( 'S_NP', 'S_NP' ) DESCRIPTION "PregledOdgovoraInPrimerjava" START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE EXIT AUTOMATIC LAYOUT XPOS -6000 YPOS 9400 NAME_POSITION XPOS -6000 YPOS 9325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'PRGLDZAH.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'PregledOdgovoraInPrimerjava' PROGRAM_ACTIVITY 'PregledZahteveZaDobavoVERP' ( 'S_NP', 'S_NP' ) DESCRIPTION "PregledZahteveZaDobavoVERP.jsp" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -9400 YPOS 9400 NAME_POSITION XPOS -9400 YPOS 9325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Planer proizvodnje' 'Informatik' 'Direktor nabave' 'Direktor informatike' 'Direktor proizvodnje' PROGRAM 'PregledZahteveZaDobavoVERP' SYNCHRONIZATION NESTED END 'PregledZahteveZaDobavoVERP' PROGRAM_ACTIVITY 'ProcesiranjeIzjeme' ( 'S_NP', 'S_NP' ) DESCRIPTION "ProcesiranjeIzjeme" START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE EXIT AUTOMATIC LAYOUT XPOS -6000 YPOS 8700 NAME_POSITION XPOS -6000 YPOS 8625 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'IZJEMA.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'ProcesiranjeIzjeme' PROGRAM_ACTIVITY 'SprejemanjeB2BDokumenta' ( 'S_NP', 'S_NP' ) DESCRIPTION "SprejemanjeB2BDokumenta"

START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -6700 YPOS 8800 NAME_POSITION XPOS -6700 YPOS 8725 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'ZAHSB2B.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'SprejemanjeB2BDokumenta' PROGRAM_ACTIVITY 'SprejemanjeB2BDokumenta_01' ( 'S_NP', 'S_NP' ) DESCRIPTION "SprejemanjeB2BDokumenta_01" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -2700 YPOS 8800 NAME_POSITION XPOS -2700 YPOS 8725 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'NARSB2B.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'SprejemanjeB2BDokumenta_01' PROGRAM_ACTIVITY 'SprejemanjeEDIDokumenta' ( 'S_NP', 'S_NP' ) DESCRIPTION "SprejemanjeEDIDokumenta" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -6700 YPOS 9100 NAME_POSITION XPOS -6700 YPOS 9025 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' SUPPORT_TOOL 'Integracijska hrbtenica' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'ZAHSEDI.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'SprejemanjeEDIDokumenta' PROGRAM_ACTIVITY 'SprejemanjeEDIDokumenta_01' ( 'S_NP', 'S_NP' ) DESCRIPTION "SprejemanjeEDIDokumenta_01" START AUTOMATIC WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -2700 YPOS 9100 NAME_POSITION XPOS -2700 YPOS 9025 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'NARSEDI.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'SprejemanjeEDIDokumenta_01' PROGRAM_ACTIVITY 'SprejemInVnosOdgovorov' ( 'S_NP', 'S_NP' ) DESCRIPTION "SprejemInVnosOdgovorov.jsp" START MANUAL WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -6700 YPOS 9400 NAME_POSITION XPOS -6700 YPOS 9325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Tajnica' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'SprejemInVnosOdgovorov' SYNCHRONIZATION NESTED END 'SprejemInVnosOdgovorov' PROGRAM_ACTIVITY 'SprejemInVnosOdgovorov_01' ( 'S_NP', 'S_NP' ) DESCRIPTION "SprejemInVnosOdgovorov_01.jsp" START MANUAL WHEN ALL CONNECTORS TRUE EXIT AUTOMATIC LAYOUT XPOS -2700 YPOS 9400 NAME_POSITION XPOS -2700 YPOS 9325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Tajnica' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'SprejemInVnosOdgovorov_01' SYNCHRONIZATION NESTED END 'SprejemInVnosOdgovorov_01' PROGRAM_ACTIVITY 'UgotavljanjeNepotrjenihZahtev' ( 'S_NP', 'S_NP' ) DESCRIPTION "UgotavljanjeNepotrjenihZahtev" START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE EXIT AUTOMATIC LAYOUT XPOS -5500 YPOS 9900 NAME_POSITION XPOS -5500 YPOS 9825 PRIORITY DEFINED_IN INPUT_CONTAINER DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'NEPOTZAH.FMCSYS.FMCGRP' SYNCHRONIZATION CHAINED END 'UgotavljanjeNepotrjenihZahtev' PROGRAM_ACTIVITY 'UgotavljanjeNepotrjenihZahtev_01' ( 'S_NP', 'S_NP' ) DESCRIPTION "UgotavljanjeNepotrjenihZahtev_01" START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE EXIT AUTOMATIC

132

LAYOUT XPOS -5500 YPOS 9200 NAME_POSITION XPOS -5500 YPOS 9125 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'NEPOTZAH.FMCSYS.FMCGRP' SYNCHRONIZATION CHAINED END 'UgotavljanjeNepotrjenihZahtev_01' PROGRAM_ACTIVITY 'UgotavljanjeNepotrjenihZahtev_02' ( 'S_NP', 'S_NP' ) DESCRIPTION "UgotavljanjeNepotrjenihZahtev_02" START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE EXIT AUTOMATIC LAYOUT XPOS -5500 YPOS 8900 NAME_POSITION XPOS -5500 YPOS 8825 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'NEPOTZAH.FMCSYS.FMCGRP' SYNCHRONIZATION CHAINED END 'UgotavljanjeNepotrjenihZahtev_02' PROGRAM_ACTIVITY 'UgotavljanjeNepotrjenihZahtev_03' ( 'S_NP', 'S_NP' ) DESCRIPTION "UgotavljanjeNepotrjenihZahtev_03" START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE EXIT AUTOMATIC LAYOUT XPOS -5500 YPOS 8700 NAME_POSITION XPOS -5500 YPOS 8625 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'NEPOTZAH.FMCSYS.FMCGRP' SYNCHRONIZATION CHAINED END 'UgotavljanjeNepotrjenihZahtev_03' PROGRAM_ACTIVITY 'UgotavljanjeNepotrjenihZahtev_04' ( 'S_NP', 'S_NP' ) DESCRIPTION "UgotavljanjeNepotrjenihZahtev_04" START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE EXIT AUTOMATIC LAYOUT XPOS -5500 YPOS 8400 NAME_POSITION XPOS -5500 YPOS 8325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'NEPOTZAH.FMCSYS.FMCGRP' SYNCHRONIZATION CHAINED END 'UgotavljanjeNepotrjenihZahtev_04' PROGRAM_ACTIVITY 'VnasanjePotrditveODobaviVERP _01' ( 'S_NP', 'S_NP' ) DESCRIPTION "VnasanjePotrditveODobaviVERP _01" START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE EXIT AUTOMATIC LAYOUT XPOS -2000 YPOS 9400 NAME_POSITION XPOS -2000 YPOS 9325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'NARERP.FMCSYS.FMCGRP' SYNCHRONIZATION CHAINED END 'VnasanjePotrditveODobaviVERP _01' PROGRAM_ACTIVITY 'VnosVERPInIzdelavaNarocilnice' ( 'S_NP', 'S_NP' ) DESCRIPTION "VnosVERPInIzdelavaNarocilnice" START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE EXIT AUTOMATIC LAYOUT XPOS -5000 YPOS 9400 NAME_POSITION XPOS -5000 YPOS 9325 PRIORITY 0 DONE_BY MEMBER OF ROLE 'Nabavni usluzbenec' 'Informatik' 'Direktor nabave' 'Direktor informatike' SUPPORT_TOOL 'ERP sistem' PROGRAM 'Integracijska hrbtenica' PROGRAM_EXECUTION_UNIT 'ZAHERP.FMCSYS.FMCGRP' SYNCHRONIZATION NESTED END 'VnosVERPInIzdelavaNarocilnice' CONTROL FROM 'DobaviteljevProces' TO 'SprejemInVnosOdgovorov' CONTROL FROM 'DobaviteljevProces_01' TO 'SprejemanjeEDIDokumenta' CONTROL FROM 'DobaviteljevProces_02' TO 'SprejemanjeB2BDokumenta' CONTROL FROM 'DobaviteljevProces_03' TO 'SprejemInVnosOdgovorov_01' CONTROL FROM 'DobaviteljevProces_04' TO 'SprejemanjeEDIDokumenta_01' CONTROL FROM 'DobaviteljevProces_05' TO 'SprejemanjeB2BDokumenta_01' CONTROL FROM 'IzbiranjeDobInNacPosiljanja' TO 'PosiljanjeDokDob_B2B' WHEN "NacinPosiljanja= ""B2B"" " XPOS -8400 YPOS 9122 LAYOUT XPOS -8400 YPOS 9400

XPOS -8400 YPOS 8800 XPOS -8400 YPOS 8800 CONTROL FROM 'IzbiranjeDobInNacPosiljanja' TO 'PosiljanjeDokDob_EDI' WHEN "NacinPosiljanja= ""EDI""" XPOS -8400 YPOS 9272 LAYOUT XPOS -8400 YPOS 9400 XPOS -8400 YPOS 9100 CONTROL FROM 'IzbiranjeDobInNacPosiljanja' TO 'PosiljanjeDokDob_Faks' WHEN "NacinPosiljanja= ""Faks"" " XPOS -8450 YPOS 9401 CONTROL FROM 'OdobritevNarocilnice' TO 'UgotavljanjeNepotrjenihZahtev' WHEN "(NarocilnicaPolizdelek.NarocilnicaOdobrena= ""N"" )" XPOS -5507 YPOS 9725 CONTROL FROM 'OdobritevNarocilnice' TO 'VnosVERPInIzdelavaNarocilnice' WHEN "(NarocilnicaPolizdelek.NarocilnicaOdobrena= ""D"" )" XPOS -5200 YPOS 9525 LAYOUT XPOS -5200 YPOS 9600 XPOS -5200 YPOS 9400 CONTROL FROM 'SprejemanjeB2BDokumenta_01' TO 'VnasanjePotrditveODobaviVERP _01' LAYOUT XPOS -2300 YPOS 8800 XPOS -2300 YPOS 9400 CONTROL FROM 'SprejemanjeEDIDokumenta' TO 'PregledOdgovoraInPrimerjava' LAYOUT XPOS -6300 YPOS 9100 XPOS -6300 YPOS 9400 CONTROL FROM 'SprejemanjeEDIDokumenta_01' TO 'VnasanjePotrditveODobaviVERP _01' LAYOUT XPOS -2300 YPOS 9100 XPOS -2300 YPOS 9400 CONTROL FROM 'SprejemInVnosOdgovorov' TO 'PregledOdgovoraInPrimerjava' LAYOUT XPOS -6400 YPOS 9400 XPOS -6300 YPOS 9400 XPOS -6300 YPOS 9400 CONTROL FROM 'SprejemInVnosOdgovorov_01' TO 'VnasanjePotrditveODobaviVERP _01' LAYOUT XPOS -2400 YPOS 9400 XPOS -2200 YPOS 9400 CONTROL FROM 'VnosVERPInIzdelavaNarocilnice' TO 'PosiljanjeDokDob_B2B_01' WHEN "NacinPosiljanja= ""B2B""" XPOS -4600 YPOS 9022 LAYOUT XPOS -4600 YPOS 9400 XPOS -4600 YPOS 8800 CONTROL FROM 'VnosVERPInIzdelavaNarocilnice' TO 'PosiljanjeDokDob_EDI_01' WHEN "NacinPosiljanja= ""EDI""" XPOS -4600 YPOS 9172 LAYOUT XPOS -4600 YPOS 9400 XPOS -4600 YPOS 9100 CONTROL FROM 'VnosVERPInIzdelavaNarocilnice' TO 'PosiljanjeDokDob_Faks_01' WHEN "NacinPosiljanja= ""Faks""" XPOS -4550 YPOS 9353 CONTROL FROM 'PosiljanjeDokDob_B2B' TO 'DobaviteljevProces_02' CONTROL FROM 'PosiljanjeDokDob_B2B_01' TO 'DobaviteljevProces_05' CONTROL FROM 'PosiljanjeDokDob_EDI' TO 'DobaviteljevProces_01' CONTROL FROM 'PosiljanjeDokDob_EDI_01' TO 'DobaviteljevProces_04' CONTROL FROM 'PosiljanjeDokDob_Faks' TO 'DobaviteljevProces' CONTROL FROM 'PosiljanjeDokDob_Faks_01' TO 'DobaviteljevProces_03' CONTROL FROM 'PregledOdgovoraInPrimerjava' TO 'OdobritevNarocilnice' WHEN "(ZahtevaPolizdelek.ZahtevanaDobava= ""P"" ) AND (ZahtevaPolizdelek.CelotnaCenaJPK<>ZahtevaPolizdelek.CelotnaCenaDobavitelj)" XPOS -5800 YPOS 9525 LAYOUT XPOS -5800 YPOS 9400 XPOS -5800 YPOS 9600 CONTROL

133

FROM 'PregledOdgovoraInPrimerjava' TO 'UgotavljanjeNepotrjenihZahtev_01' WHEN "(ZahtevaPolizdelek.ZahtevanaDobava= ""D"" )" XPOS -5849 YPOS 9175 LAYOUT XPOS -6000 YPOS 9200 XPOS -5900 YPOS 9200 CONTROL FROM 'PregledOdgovoraInPrimerjava' TO 'VnosVERPInIzdelavaNarocilnice' WHEN "(ZahtevaPolizdelek.ZahtevanaDobava= ""P"" ) AND (ZahtevaPolizdelek.CelotnaCenaJPK=ZahtevaPolizdelek.CelotnaCenaDobavitelj)" XPOS -5499 YPOS 9375 LAYOUT XPOS -5100 YPOS 9400 CONTROL FROM 'PregledOdgovoraInPrimerjava' TO 'ProcesiranjeIzjeme' WHEN "(ZahtevaPolizdelek.ZahtevanaDobava= ""I"" )" XPOS -6022 YPOS 9025 CONTROL FROM 'PregledZahteveZaDobavoVERP' TO 'IzbiranjeDobInNacPosiljanja' CONTROL FROM 'ProcesiranjeIzjeme' TO 'ObvestiDobZaPonovnoPosiljanje' WHEN "(NacinPosiljanja= ""Faks"") AND (Opomba= ""Necitljiv"")" XPOS -6000 YPOS 8175 LAYOUT XPOS -6000 YPOS 8200 CONTROL FROM 'ProcesiranjeIzjeme' TO 'UgotavljanjeNepotrjenihZahtev_02' WHEN "NacinPosiljanja= ""B2B""" XPOS -5850 YPOS 8875 LAYOUT XPOS -6000 YPOS 8900 CONTROL FROM 'ProcesiranjeIzjeme' TO 'UgotavljanjeNepotrjenihZahtev_03' WHEN "NacinPosiljanja= ""EDI""" XPOS -5750 YPOS 8675 CONTROL FROM 'ProcesiranjeIzjeme' TO 'UgotavljanjeNepotrjenihZahtev_04' WHEN "(NacinPosiljanja= ""Faks"") AND (Opomba= """")" XPOS -5899 YPOS 8375 LAYOUT XPOS -6000 YPOS 8400 CONTROL FROM 'SprejemanjeB2BDokumenta' TO 'PregledOdgovoraInPrimerjava' LAYOUT XPOS -6300 YPOS 8800 XPOS -6300 YPOS 9400 DATA FROM 'ProcesiranjeIzjeme' TO 'UgotavljanjeNepotrjenihZahtev_04' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -5600 YPOS 8500 DATA FROM SOURCE 1 TO 'PregledZahteveZaDobavoVERP' MAP '_STRUCT' TO '_STRUCT' DATA FROM 'SprejemInVnosOdgovorov' TO 'PregledOdgovoraInPrimerjava' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -6300 YPOS 9500 DATA FROM 'SprejemanjeB2BDokumenta' TO 'PregledOdgovoraInPrimerjava' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -6100 YPOS 9300 DATA FROM 'PregledOdgovoraInPrimerjava' TO 'UgotavljanjeNepotrjenihZahtev_01' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -5700 YPOS 9300 XPOS -5700 YPOS 9300 DATA FROM 'PregledOdgovoraInPrimerjava' TO 'VnosVERPInIzdelavaNarocilnice' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -5400 YPOS 9300 XPOS -5400 YPOS 9300 DATA FROM 'ProcesiranjeIzjeme' TO 'UgotavljanjeNepotrjenihZahtev_02' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -5800 YPOS 9000 DATA FROM 'ProcesiranjeIzjeme' TO 'UgotavljanjeNepotrjenihZahtev_03' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -5800 YPOS 8800 XPOS -5800 YPOS 8800 DATA FROM 'PregledOdgovoraInPrimerjava' TO 'ProcesiranjeIzjeme' MAP '_STRUCT' TO '_STRUCT' LAYOUT

XPOS -6100 YPOS 9000 DATA FROM 'ProcesiranjeIzjeme' TO 'ObvestiDobZaPonovnoPosiljanje' MAP '_STRUCT' TO '_STRUCT' DATA FROM 'VnasanjePotrditveODobaviVERP _01' TO SINK 1 MAP '_STRUCT' TO '_STRUCT' DATA FROM 'UgotavljanjeNepotrjenihZahtev' TO SINK 1 MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -1700 YPOS 9900 DATA FROM 'ObvestiDobZaPonovnoPosiljanje' TO SINK 1 MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -5000 YPOS 8200 XPOS -5000 YPOS 8400 XPOS -1700 YPOS 8400 DATA FROM 'UgotavljanjeNepotrjenihZahtev_04' TO SINK 1 MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -1700 YPOS 8400 DATA FROM 'UgotavljanjeNepotrjenihZahtev_03' TO SINK 1 MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -5000 YPOS 8700 XPOS -5000 YPOS 8400 XPOS -1700 YPOS 8400 DATA FROM 'UgotavljanjeNepotrjenihZahtev_02' TO SINK 1 MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -5000 YPOS 8900 XPOS -5000 YPOS 8400 XPOS -1700 YPOS 8400 DATA FROM 'UgotavljanjeNepotrjenihZahtev_01' TO SINK 1 MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -5000 YPOS 9200 XPOS -5000 YPOS 8400 XPOS -1700 YPOS 8400 DATA FROM 'PosiljanjeDokDob_Faks' TO 'DobaviteljevProces' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -7700 YPOS 9500 DATA FROM 'PregledOdgovoraInPrimerjava' TO 'OdobritevNarocilnice' MAP '_STRUCT' TO '_STRUCT' DATA FROM 'OdobritevNarocilnice' TO 'VnosVERPInIzdelavaNarocilnice' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -5200 YPOS 9500 DATA FROM 'OdobritevNarocilnice' TO 'UgotavljanjeNepotrjenihZahtev' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -5400 YPOS 9700 DATA FROM 'PosiljanjeDokDob_EDI_01' TO 'DobaviteljevProces_04' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -3700 YPOS 9200 DATA FROM 'VnosVERPInIzdelavaNarocilnice' TO 'PosiljanjeDokDob_EDI_01' MAP '_STRUCT' TO '_STRUCT' DATA FROM 'DobaviteljevProces_04' TO 'SprejemanjeEDIDokumenta_01' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -3000 YPOS 9200 DATA FROM 'SprejemanjeEDIDokumenta_01' TO 'VnasanjePotrditveODobaviVERP _01' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -2200 YPOS 9300 DATA FROM 'DobaviteljevProces' TO 'SprejemInVnosOdgovorov' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -7000 YPOS 9500 DATA FROM 'PosiljanjeDokDob_EDI' TO 'DobaviteljevProces_01' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -7800 YPOS 9200 DATA FROM 'PosiljanjeDokDob_B2B' TO 'DobaviteljevProces_02' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -7800 YPOS 8900

134

DATA FROM 'DobaviteljevProces_01' TO 'SprejemanjeEDIDokumenta' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -7000 YPOS 9200 DATA FROM 'DobaviteljevProces_02' TO 'SprejemanjeB2BDokumenta' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -7000 YPOS 8900 DATA FROM 'IzbiranjeDobInNacPosiljanja' TO 'PosiljanjeDokDob_EDI' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -8300 YPOS 9200 DATA FROM 'IzbiranjeDobInNacPosiljanja' TO 'PosiljanjeDokDob_B2B' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -8700 YPOS 9300 DATA FROM 'PregledZahteveZaDobavoVERP' TO 'IzbiranjeDobInNacPosiljanja' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -9100 YPOS 9500 XPOS -9100 YPOS 9500 DATA FROM 'IzbiranjeDobInNacPosiljanja' TO 'PosiljanjeDokDob_Faks' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -8400 YPOS 9500 DATA FROM 'PosiljanjeDokDob_B2B_01' TO 'DobaviteljevProces_05' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -3700 YPOS 8900 DATA FROM 'SprejemInVnosOdgovorov_01' TO 'VnasanjePotrditveODobaviVERP _01' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -2300 YPOS 9500 DATA FROM 'VnosVERPInIzdelavaNarocilnice' TO 'PosiljanjeDokDob_Faks_01' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -4500 YPOS 9500 XPOS -4500 YPOS 9500 DATA FROM 'VnosVERPInIzdelavaNarocilnice' TO 'PosiljanjeDokDob_B2B_01' MAP '_STRUCT' TO '_STRUCT' DATA FROM 'PosiljanjeDokDob_Faks_01' TO 'DobaviteljevProces_03' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -3700 YPOS 9500 DATA FROM 'DobaviteljevProces_03' TO 'SprejemInVnosOdgovorov_01' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -3000 YPOS 9500 DATA FROM 'DobaviteljevProces_05' TO 'SprejemanjeB2BDokumenta_01' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -3000 YPOS 8900 DATA FROM 'SprejemanjeB2BDokumenta_01' TO 'VnasanjePotrditveODobaviVERP _01' MAP '_STRUCT' TO '_STRUCT' DATA FROM 'SprejemanjeEDIDokumenta' TO 'PregledOdgovoraInPrimerjava' MAP '_STRUCT' TO '_STRUCT' LAYOUT XPOS -6200 YPOS 9300 END 'NarocanjePolizdelkov'

Documents

Peter gersak Management poslovnih procesov · 2005. 5. 31. · Storitveno orientirana arhitektura .....50 2.3.2. Sistem za management poslovnih procesov ... Prikaz in analiza izvajanja