Izpitni centri ECDL ECDL (European Computer Driving License), ki ga v Sloveniji imenujemo evropsko računalniško spričevalo, je standardni program usposabljanja uporabnikov, ki da zaposlenim potrebno znanje za delo s standardnimi računalniškimi programi na informatiziranem delovnem mestu, delodajalcem pa pomeni dokazilo o usposobljenosti. V Evropi je za uvajanje, usposabljanje in nadzor izvajanja ECDL pooblaščena ustanova ECDL Foundation, v Sloveniji pa je kot član CEPIŠ (Council of European Professional Informatics Societies) to pravico pridobilo Slovensko društvo INFORMATIKA. V državah Evropske unije so pri uvajanju ECDL močno angažirane srednje in visoke šole, aktivni pa so tudi različni vladni resorji. Posebej pomembno je, da velja spričevalo v več 140-tih državah, ki so vključene v program ECDL. Doslej je bilo v svetu izdanih že več kot 5,5 milijonov indeksov, v Sloveniji okoli 4000 in več kot 2000 podeljenih spričeval. Za izpitne centre ECDL so se v Sloveniji usposobile organizacije, katerih logotipi so natisnjeni na tej strani. B ML Mf SB Atl-MA ustvarjalne komunikacije VIZIJA RAZVOJA SOFT IZOBRAŽEVANJE INFORMACIJSKE STORITVE £ELES = ICES UNIVERZA V LJUBLJANI j; [ j EauuN Fakulteta za pomorstvo in promet Idi INFORMACIJSKE TEHNOLOGIJE f r ) /ČOPA GžHž) LJUDSKA UNIVERZA KOPER UNIVERSIT A POPOLARE CAPODISTRIA l ■ LJUDSKA CEUE Cinlumm uliti 1 3066 Celie Slovenila TcIcIuh (031 «8 6110 Telelai 1031 «167-31 i mm Mim«.kh sobota Mucih • ^Micro jjBfip ^nske Konjice ' ^ spin SRCSI sistemske integracije n ŠOLSKI CENTER Novo mesto ŠOLSKI CENTER VELENJE UPI UUDSKA UNIVERZA ŽALEC Jfl/a /ispaz/uA flot// Jjr GO/npu.Ce.r-S' PRAH UOBRAitVALNI CIN TIR Rogaika slatina ww*.piah.tl LASER Informacijska tehnologija, d.o.o. Informacijska tehnologija, d.o.o. f -T t(33^2 VSEBINA UPORABNA INFORMATIKA 2007 ŠTEVILKA 1 JAN/FEB/MAR LETNIK XV ISSN 1318-1882 B Uvodnik B Razprave Matjaž B. Jurič, Marjan Heričko, Ivan Rozman: Raziskava o uporabi storitvenih arhitektur v Sloveniji 4 Jurij Jaklič, Tatjana Huber, Marko Svetina, Mojca Indihar štemberger: Menedžment poslovnih procesov v oskrbovalni verigi - Primer Merkur 11 Katja Harej, Tatjana VVelzer Družovec: Upravljanje znanja - informacijska podpora ali sistem za ohranjanje znanja? 22 Marko Tekavc, Marjan Heričko: Uporaba metrik pri identifikaciji smiselnih preoblikovanj programske kode 30 Borut Žnidar, Aleš Groznik: Upravljanje neprekinjenega poslovanja v slovenskih organizacijah 41 B Poročila Luka Babnik: Uvedba podatkovnega skladišča v Banki Slovenije 47 B Koledar prireditev *3LoOl 2^53 UPORABNA INFORMATIKA 2007 ŠTEVILKA 1 JAN/FEB/MAR LETNIK XV ISSN 1318-1882 Ustanovitelj in izdajatelj Slovensko društvo INFORMATIKA Vožarski pot 12 1000 Ljubljana Predstavnik Niko Schlamberger Odgovorni urednik Andrej Kovačič Uredniški odbor Marko Bajec, Vesna Bosilj Vukšič, Dušan Caf, Janez Grad, Jurij Jaklič, Milton Jenkins, Andrej Kovačič, Tomaž Mohorič, Katarina Puc, Vladislav Rajkovič, Heinrich Reinermann, Ivan Rozman, Niko Schlamberger, John Taylor, Ivan Vezočnik, Mirko Vintar, Tatjana VVelzer - Družovec Recenzenti prispevkov za objavo v reviji Uporabna informatika Marko Bajec, Tomaž Banovec, Vladimir Batagelj, Marko Bohanec, Vesna Bosilj Vukšič, Dušan Caf, Srečko Devjak, Tomaž Erjavec, Matjaž Gams, Izidor Golob, Tomaž Gornik, Janez Grad, Miro Gradišar, Jože Gričar, Joszef Gyorkos, Marjan Heričko, Jurij Jaklič, Milton Jenkins, Andrej Kovačič, Iztok Lajovic, Katarina Puc, Vladislav Rajkovič, Heinrich Reinermann, Ivan Rozman, Niko Schlamberger, Ivan Vezočnik, Mirko Vintar, Tatjana VVelzer -Družovec, Franc Žerdin Tehnična urednica Mira Turk Škraba Ublikovanje Bons Prelom Dušan VVeiss, Ada Poklač Tisk Prograf Naklada 700 izvodov Naslov uredništva Slovensko društvo INFORMATIKA Uredništvo revije Uporabna informatika Vožarski pot 12,1000 Ljubljana www.drustvo-informatika.si/posta Revija izhaja četrtletno. Cena posamezne številke je 20,86 € (5.000 SIT). Letna naročnina za podjetja 83,46 € (20.000 SIT), za vsak nadaljnji izvod 58,48 € (14.000 SIT), za posameznike 33,81 € (8.000 SIT), za študente 14,61 e(3.500SIT). Revijo sofinancira Ministrstvo za visoko šolstvo, znanost in tehnologijo. Revija Uporabna informatika je od številke 4/VII vključena v mednarodno bazo INSPEC. Revija Uporabna informatika je pod zaporedno številko 666 vpisana v razvid medijev, ki ga vodi Ministrstvo za kulturo. © Slovensko društvo INFORMATIKA Navodila avtorjem Revija Uporabna informatika objavlja izvirne prispevke domačih in tujih avtorjev na znanstveni, strokovni in informativni ravni. Namenjena je najširši strokovni javnosti, zato je zaželeno, da so tudi znanstveni prispevki napisani čim bolj poljudno. Članke objavljamo praviloma v slovenščini, prispevke tujih avtorjev v angleščini. Prispevki so obojestransko anonimno recenzirani. Vsak članek za rubriko Razprave mora za objavo prejeti dve pozitivni recenziji. O objavi samostojno odloča uredniški odbor. Prispevki naj bodo lektorirani, v uredništvu opravljamo samo korekturo. Po presoji se bomo posvetovali z avtorjem in članek tudi lektorirali. Prispevki za rubriko Razprave naj imajo dolžino do 40.000, prispevki za rubrike Rešitve, Poročila do 30.000, Obvestila pa do 8.000 znakov. Naslovu prispevka naj sledi ime in priimek avtorja, ustanova, kjer je zaposlen, in elektronski naslov. Članek naj ima v začetku do 10 vrstic dolg izvleček v slovenščini in angleščini, v katerem avtor opiše vsebino prispevka, dosežene rezultate raziskave. Abstract se začne s prevodom naslova v angleščino. Članku dodajte kratek avtorjev življenjepis (do 8 vrstic), v katerem poudarite predvsem delovne dosežke. Pišite v razmaku ene vrstice, brez posebnih ali poudarjenih črk, za ločilom na koncu stavka napravite samo en prazen prostor, ne uporabljajte zamika pri odstavkih. Revijo tiskamo v črno-beli tehniki s folije, zato barvne slike ali fotografije kot originali niso primerne. Objavljali tudi ne bomo slik zaslonov, razen če niso nujno potrebne za razumevanje besedila. Slike, grafikoni, organizacijske sheme ipd. naj imajo belo podlago. Po možnosti jih pošiljajte posebej, ne v datoteki z besedilom članka. Disketi z besedom priložite izpis na papirju. Prispevke pošiljajte po elektronski ali navadni pošti na naslov uredništva revije: ui@drustvo-informatika.si, Slovensko društvo INFORMATIKA, Vožarski pot 12, 1000 Ljubljana; na teh naslovih dobite tudi vse dodatne informacije. Po odločitvi uredniškega odbora o objavi članka bo avtor prejel pogodbo, s katero bo prenesel vse materialne avtorske pravice na Slovensko društvo INFORMATIKA. Po izidu revije pa bo prejel nakazilo avtorskega honorarja po veljavnem ceniku ali po predlogu odgovornega urednika. UVODNIK Spoštovane bralke in spoštovani bralci, pred nami je novo vsakoletno posvetovanje Dnevi slovenske informatike DSI2007, ki bo v Portorožu potekalo med 11. in 13. aprilom 2007. Rdečo nit posvetovanja nakazuje že naslov »Z informatiko do novih poslovnih priložnosti«. Sam naslov, predvsem pa vsebine prispevkov in okroglih miz dajejo slutiti, da je slovenska informatika končno (!) le prešla pretežno tehnološko (računalniško) obravnavo informatike in se usmerila v njeno strateško in poslovno vlogo pri prenovi in informatizaciji poslovanja. Takšnemu premiku, ki predstavlja poslovno priložnost tudi za slovenska informacijska podjetja, v prvi vrsti botrujejo poslovne potrebe uporabnikov, podjetij in uprave. Zato bo prvi dan konference organizirana okrogla miza z naslovom »Nove poslovne priložnosti slovenskih podjetij IT?« Na njej bodo udeleženci spregovorili o dosedanjih izkušnjah, uspehih in težavah ter možnostih slovenskih podjetij informacijske dejavnosti. Naj poudarim nekatera temeljna tematska izhodišča razprave oz. vprašanja na tej okrogli mizi: • Storitvena naravnanost informatike, prenova in informatizacija poslovanja ter na drugi strani izločanje informatike (outsourcing) kot poslovne strategije naročnikov na področju zagotavljanja informacijskih storitev. Trendi, izkušnje in priložnost za ponudnike? . Poslovna strategija in prilagajanje poslovnih modelov ponudnikov na področju informacijske tehnologije. Ali slovenski ponudniki lahko dolgoročno preživijo z žal že predolgo uveljavljeno strategijo »tehnološke naravnanosti« ter majhnosti in samozadostnosti? Kaj pa prenova poslovnih procesov in izboljšanje poslovna uspešnosti z uporabo informacijske tehnologije, pa povezovanje s ciljem »globalnih priložnosti« oz. uveljavljanje strategije sodelovanje, grozdenja, mrežnega organiziranja ipd.? Zakaj se pri nas te strategije počasi uveljavljajo ali so v mnogih primerih neuspešne? . Obravnava primerov uspešne strateške prenove podjetij s področja informacijske tehnologije in uveljavljanje novih poslovnih modelov. Kaj se iz teh primerov lahko naučimo, kako se organizirati in delovati s ciljem »biti konkurenčen in uspešen« v globalnem poslovnem okolju? Kot pravijo organizatorji, vas »največja neodvisna strokovna konferenca, ki v celoti pokriva področje informatike« zagotovo ne bo razočarala. Ugotavljajo, da so jim številni prispevki strokovnjakov iz slovenskih podjetij in ustanov omogočili sestavo res zanimivega in kakovostnega programa. V to ne dvomim, morda so poskrbeli tudi za zanimiv družabni program, tu imajo po navadi še nekaj rezerv. No, bomo videli... Andrej Kovačič, odgovorni urednik RAZPRAVE B Raziskava o uporabi storitvenih arhitektur v Sloveniji Matjaž B. Jurič, Marjan Heričko, Ivan Rozman Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko, Inštitut za informatiko matjaz.juric@uni-mb.si Povzetek Prispevek naslavlja področje storitvenih arhitektur (SOA - Service Oriented Architecture). Poleg identifikacije namenov in ciljev storitvenih arhitektur bomo v prispevku prikazali rezultate raziskave o uporabi storitvenih arhitektur v Sloveniji, v katero so bili vključeni ponudniki rešitev informacijske tehnologije in srednja ter velika podjetja z lastnimi oddelki za informacijsko tehnologijo. V okviru raziskave smo identificirali pogled slovenskih podjetij na SOA, ključne faktorje tveganja in glavne planirane aktivnosti pri vpeljavi. Raziskava je razkrila ključna poslovna in tehnološka pričakovanja vpeljave storitvenih arhitektur ter dala vpogled v uporabo tehnologij in platform. Pokazala je, da storitvene arhitekture preraščajo meje informacijskih oddelkov, saj predstavljajo pomemben način izboljšanja učinkovitosti in konkurenčne prednosti celotnega podjetja. Abstract Service Oriented flrchitectures Survey in Slovenia This article focuses on the Service Oriented Architectures (SOA). In addition to identifying aims, objectives, and goals of introducing SOA, the article presents the results of the survey on SOA usage in major Slovenian companies. In the survey IT solution providers and medium and large enterprises with their own IT departments h a ve been included. The expectations and objectives of Slovenian enterprises related to introduction of SOA have been gathered, and the major risk factors and planned activities for SOA introduction have been identified. The survey has revealed key business and technology expectations tovvards SOA and given insight into the usage of technologies and softvvare platforms. The general conclusion of the survey has been that SOA has outgrovvn the limits of IT departments and is seen as an important approach for improving the efficiency and competitive position of the companies. 1 Uvod Razvoj informacijske podpore, ki bo organizacijam omogočala celovito podporo poslovnih procesom, je z uporabo današnjih pristopov in tehnologij zapleten in dolgotrajen postopek. Če k temu dodamo še dejstvo, da so poslovni procesi v večini organizacij agilni, da se hitro spreminjajo in da se organizacije trudijo poslovne procese prilagoditi strankam ter jih optimizirati in s tem izboljšati odzivnost same organizacije, postane težavnost razvoja ustrezne informacijske podpore še večja. Izvirni greh se skriva v dejstvu, da strokovnjaki za informacijsko tehnologijo potrebujemo določen čas, da informacijski sistem prilagodimo spremembam -novim potrebam, ki so se pojavile v poslovnih procesih. Ta tako imenovani »IT gap« je z vidika agilnosti same organizacije smiselno skrčiti, kolikor se le da. Le organizacije, v katerih je informacijska podpora zasnovana tako, da se hitro in učinkovito prilagaja poslovnim spremembam, lahko delujejo konkurenčno v globalni ekonomiji. Storitvene arhitekture (SOA - Service Oriented Architecture) so zadnji, najnovejši arhitekturni pristop, ki omogoča rešitve omenjenih težav, s katerimi se soočamo informatiki pri razvoju in vzdrževanju ko- mpleksnih informacijskih sistemov. V prispevku bomo prikazali rezultate raziskave o uporabi storitvenih arhitektur v Sloveniji. Podjetja in organizacije smo spraševali o njihovem pogledu na storitvene arhitekture, o prednostih - poslovnih in tehnoloških, ki jih pričakujejo od vpeljave storitvenih arhitektur, ključnih tveganjih in aktivnostih, ki jih planirajo pri sami vpeljavi. Poleg poslovnih in tehnoloških pričakovanj smo v raziskavo vključili tudi pregled uporabe tehnologij in programskih platform. Podatki, zbrani v okviru raziskave, so omogočili izluščiti nekaj pomembnih zaključkov in smernic ter identifikacijo ključnih tveganj, ki jih podajamo v prispevku. 2 Storitvene arhitekture Storitvene arhitekture so množica splošno sprejetih smernic in postopkov za načrtovanje in implementacijo informacijskih sistemov v naslednjih desetih letih. Storitvene arhitekture so prerasle okvire arhitekture informacijskih sistemov in postajajo pomemben koncept za izboljšanje učinkovitosti poslovanja podjetij in za izboljšanje njihovega konkurenčnega položaja. Storitvene arhitekture in njene izpeljanke, storitveno usmerjena informacijska tehnologija, storitveno usmerjeno računalništvo in storitveno usmerjena ekonomija, so zato našli mesto tudi v poslovnem besedišču in potrjujejo, da informatika, informacijski sistemi in infomacijsko-komunikacijska tehnologija postajajo sestavni del poslovanja vsake organizacije. SOA omogoča podjetjem, da zagotovijo celovito podporo poslovnim procesom z uporabo obstoječega informacijskega sistema in aplikacij [3, 4]. Ta podpora je prilagodljiva in omogoča večjo fleksibilnost poslovanja in hitrejše odzivanje na spremembe, kar podjetju kot celoti omogoča hitrejše prilagajanje in reagiranje na zahteve tržišča. Postopek, ki ga uporablja SOA za doseganje omenjenih ciljev, je razmeroma preprost. V nekoliko poenostavljeni obliki bi lahko govorili o dveh ključnih korakih [1,2]: « prvi korak je izpostavljanje funkcionalnosti obstoječih aplikacij v obliki storitev (najpogosteje spletnih storitev, v kompleksnejših sistemih pa uporabimo ESB - Enterprise Service Bus); ■ drugi korak je kompozicija storitev v poslovne procese, za kar najpogosteje uporabimo BPEL (Business Process Execution Language). Svojo pravo vrednost pokaže storitvena arhitektura šele po realizaciji drugega koraka, ki eksplicitno definira povezave in sodelovanje storitev v poslovnih procesih ter sodelovanje procesov v poslovnih protokolih [6]. Tehnološki gradniki za realizacijo storitvene arhitekture že obstajajo in so dosegli zadostno zrelost za uporabo v velikih, kompleksnih sistemih. Sem štejemo tehnologije spletnih storitev, sklad dopolnilnih specifikacij spletnih storitev, storitvena vodila (ESB) in predvsem BPEL - jezik za kompozicijo spletnih storitev [5, 7). V prihodnosti pričakujemo še dodatno podporo opisu sodelovanj med organizacijami z VVS-CDL (Choreography Description Language). Že danes pa je jasno, da vpeljava storitvenih arhitektur, razvoj storitev in njihova kompozicija v procesnem smislu, organizaciji prinese bolj učinkovito in bolj prilagodljivo informacijsko infrastrukturo in s tem prispeva k lažji in hitrejši realizaciji poslovnih ciljev [8, 9]. V tem smislu ponuja storitvena arhitektura dejanske in oprijemljive koristi za podjetja. V obdobju petih let po implementaciji večine (vsaj 70 %) poslovnih procesov je mogoče prihraniti vsaj 10 % sredstev, potrebnih za informatiko, ter hkrati povečati obseg in kakovost storitev, ki jih informatika ponuja. V to niso vštete posredne koristi storitvene arhitekture, kot npr. boljša dostopnost do informacij, povečana kakovost poslovnih odločitev, boljša informiranost partnerjev in povečanje njihovega zadovoljstva ipd. 3 Raziskava Raziskavo o uporabi storitvenih arhitektur v Sloveniji je spomladi 2006 izvedel Inštitut za informatiko na pobudo podjetja Oracle. Osnovni namen je bil ugotoviti, kako na SOA gledajo slovenska podjetja, kaj so naredila do sedaj in kakšne načrte imajo v prihodnosti. V ta namen so bila v raziskavo vključena tista slovenska podjetja in organizacije, ki razvijajo informacijske rešitve, večja podjetja drugih panog, ki imajo lastne oddelke za informacijsko tehnologijo in podjetja, ki ponujajo storitve informacijske tehnologije. Vabilo je bilo poslano 373 identificiranim kandidatom. V raziskavi je sodelovalo 178 udeležencev, od tega 64,5 % razvijalcev infomacijskotehnoloških rešitev, 30 % organizacij z lastnim oddelkom za informacijsko tehnologijo in 5,5 % drugih organizacij. Slovenske organizacije pričakujejo, da bo čez štiri leta znaten do pretežni del njihovih aplikacij temeljil na storitveni arhitekturi. Kar dobrih 40 % jih je prepričanih, da bo čez tri leta 40 do 70 % njihovih aplikacij že temeljilo na storitveni arhitekturi, kar prikazuje slika 1. % danes čez 2 leti čez 4 leta I I 0-10 % □ 10-40 % □ 40-70 % □ 70-100 % Slika 1 Delež aplikacij, ki temelji na storitveni arhitekturi 3.1. Vpeljava storitvene arhitekture Slovenske organizacije se v pretežni meri zavedajo, da je vpeljava storitvene arhitekture potrebna. Četrtina anketiranih organizacij ima že izdelan načrt vpeljave SOA in ustrezno izobrazbo, kar prikazuje slika 2. Do- datnih 28 % se je že ustrezno izobrazilo. 44 % se zaveda pomena storitvene arhitekture, vendar se še niso izobraževali in le 3 % organizacij ne pozna pomena storitvene arhitekture. Slovenske organizacije pričakujejo, da bo čez štiri leta znaten do pretežni del njihovih aplikacij temeljil na storitveni arhitekturi. Tretjina organizacij načrtuje uvedbo storitvene arhitekture v naslednjih 12 mesecih. 2,7 % 25,5 % 28,2 % V podjetju imamo že izdelan načrt za vpeljavo SOA in ustrezno izobrazbo | | SOA je zelo pomembna in smo se v ta namen tudi ustrezno izobrazili |—| V organizaciji se zavedamo pomena SOA, vendar se do sedaj nismo izobraževali HI SOA ne poznamo Slika 2: Načrt in pripravljenost na vpeljavo storitvene arhitekture 3.2 Tveganja Slovenske organizacije ocenjujejo kot ključni faktor tveganja pri vpeljavi storitvene arhitekture pomanj- Pomanjkanje znanja in razumevanja poslovnih prednosti SOA Pomanjkanje tehničnega znanja o SOA Premalo podpore dobaviteljev programske opreme Premalo obstoječega znanja in izkušenj Prednosti, ki jih prinaša SOA, ne upravičujejo vlaganj % I I Zelo pomembno 1 I Pomembno I I Ni pomembno Slika 3 Ključni faktorji tveganja kanje znanja. Najpomembnejše je pomanjkanje znanja in razumevanja poslovnih prednosti storitvene arhitekture (49 %). Sledi premalo obstoječega znanja in izkušenj (36 %) in pomanjkanje tehničnega znanja (31 %), kar prikazuje slika 3. Omenjeno pomanjkanje znanja lahko naredi poslovno vrednost vpeljave storitvene arhitekture premalo razpoznavno, kar lahko ogrozi celoten projekt vpeljave storitvene arhitekture SOA zaradi premajhne podpore vodstva. Ena ključnih nalog pri vpeljavi storitvene arhitekture mora zato biti jasna definicija poslovnih vrednosti storitvene arhitekture in ustvarjanje zadostne razpoznavnosti in podpore s strani vodstva podjetja. Ta bojazen je še posebej prisotna zaradi dejstva, da kar v 70 % slovenskih organizacij vpeljavo storitvene arhitekture nadzira in koordinira informatik (vodja informatike - 25 %, arhitekt informacijske tehnologije - 35 %, vodja razvoja - 10 %), kar je v nasprotju s priporočili (slika 4). Največja bojazen pri tem je, da informatik ne bo znal dovolj jasno artikulirati poslovne prednosti ter ne bo pridobil zadostne podpore vodstva. Vpeljave storitvene arhitekture se mora zavedati vsa organizacija in jo ustrezno podpirati. Brez podpore je uspešnost resno ogrožena. Drugo Direktor 10,0% 15,0% Zunanji partner 1,0% Vodja razvoja 4,0 % Vodja razvojne IT skupine 10,0% Vodja oddelka za informatiko 25,0 % IT arhitekt 35,0% Slika 4 Nadzor in koordinacija vpeljave storitvene arhitekture Poleg omenjenih tveganj so slovenske organizacije identificirale kot glavno prepreko pri vpeljavi storitvene arhitekture pomanjkanje znanja o storitveni arhitekturi znotraj organizacije (54 %) in premalo dobrih praks in izkušenj (55 %). Tem tveganjem se poskušajo izogniti z izobraževanjem (57 %), izdelavo pilotnih projektov (57 %) in sistematičnim načrtovanjem (40 %). 3.3 Aktivnosti vpeljave Izobraževanje, izdelava pilotnih projektov in načrtovanje so ključne aktivnosti vpeljave storitvene arhitekture v slovenskih organizacijah. Te aktivnosti posredno razkrivajo dejstvo, da so slovenske organizacije z vpeljavo storitvene arhitekture šele na začetku, kar pa je glede na čas obstoja storitvene arhitekture pričakovano in primerljivo s tujino. Slovenske organizacije so v dobršni meri zaposlene že seznanile z vizijo (41 %) in izvedle izobraževanje ključnih kadrov (40 %). Načrtujejo pa še naslednje aktivnosti: izdelavo načrta storitvene arhitekture (65 %), oceno potrebnih stroškov (58 %), pripravo strateškega načrta in vizije (56 %), izdelavo pilotnih projektov (55 %) in imenovanje ekipe za razvoj storitvene arhitekture ter izdelavo organizacijske strukture (51 %), kar prikazuje slika 5. % 0 20 40 60 80 100 Seznanjanje zaposlenih z vizijo Izobraževanje ključnih IT kadrov Priprava strateškega načrta in vizije Izdelava pilotnih projektov Izdelava načrta storitvene arhitekture Ovrednotenje obstoječih aplikacij Razširjanje vpliva S0A izven IT oddelka Iskanje zunanjih izvajalcev (outsorcing) za izvedbo S0A Ocena potrebnih stroškov Imenovanje ekipe za razvoja S0A ter izdelava organizacijske strukture storitev in proizvodov v smislu storitveno usmerjene ekonomije. 3.4 Poslovni cilji Slovenske organizacije ocenjujejo kot najpomembnejše poslovne cilje vpeljave storitvene arhitekture izboljšano učinkovitost poslovnih procesov (54 % zelo pomembno), hitrejšo odzivnost na spremembe in boljšo prilagodljivost poslovnih procesov (56 % zelo pomembno) in boljšo usklajenost med informacijsko tehnologijo in poslovnimi zahtevami (46 % zelo pomembno), kar prikazuje slika 6. Kot pomembno je ocenjena še boljša učinkovitost informacijske tehnologije in manjše potrebe po vlaganjih v prihodnosti, medtem ko enostavnejšemu razvoju aplikacij in razgradnji v storitve ter boljši integraciji ni pripisan tolikšen pomen. % 0 20 40 60 80 100 Izboljšano učinkovitost poslovnih procesov Boljšo usklajenost med IT in poslovnimi zahtevami Boljšo učinkovitost IT in manjše potrebe po vlaganjih v prihodnosti Hitrejšo odzivnost na spremembe in boljšo prilagodljivost poslovnih procesov Enostavnejši razvoj aplikacij Razgradnjo IT v storitve in boljšo integracijo I I Smo že izvedli I I Načrtujemo I I Ne bomo/ne načrtujemo Slika 5: Aktivnosti vpeljave storitvene arhitekture I I Zelo pomembno EZ1 Pomembno I I Ni pomembno Slika 6 Poslovni cilji vpeljave storitvene arhitekture Ključni izziv vpeljave storitvene arhitekture se skriva v razpoznavanju poslovnih prednosti, to je v izboljšanju učinkovitosti poslovanja, ki ga storitvena arhitektura omogoča skozi direktno podporo poslovnih procesov, večjo prilagodljivost in hitrejšo odzivnost na spremembe in dopolnitve. Hkrati storitvena arhitektura omogoča spremembo fokusa informatike iz tehnološkega v storitvenega. Udejanjanje informatike kot storitve z uporabo odprtih storitvenih arhitektur in organsko povezavo poslovanja organizacije in informacijske tehnologije bo naredilo informatiko bolj predvidljivo in omogočilo vzpostavitev storitveno usmerjene informacijske tehnologije. Slednji pa bo omogočal organizacijam razvoj novih Potreba po izboljšanju učinkovitosti poslovanja je kot eden najpomembnejših ciljev skladna s kriteriji učinkovitosti informatike, kot jih merijo v slovenskih organizacijah. Raziskava je sicer pokazala, da 16 % sodelujočih organizacij učinkovitosti informatike sploh ne meri, 34 % pa le enkrat letno. Druga polovica najpogosteje meri učinkovitost mesečno (23 %). Pri merjenju je najpomembnejši kriterij povečanje učinkovitosti poslovanja (54 %), sledijo pa kriteriji, vezani na stroške, kar prikazuje slika 7. 3.5 Tehnološki cilji in integracija sistemou Poslovne prednosti storitvene arhitekture je mogoče realizirati le na osnovi implementacije ustreznih 5,5 % 20,0 % 12,7% I I Stroški razvoja novih aplikacij kot delež celotnega proračuna IT I I Stroški vzdrževanja sistema kot delež celotnega proračuna IT I I IT proračun kot delež celotnega prometa podjetja I I Povečanje učinkovitosti poslovanja m Odstotek proračuna, namenjen razvoju IT Slika 7: Kriteriji učinkovitosti informatike tehnoloških prednosti, prek katerih lahko podjetja dosežejo hitrejše in enostavnejše prilagajanje aplikacij, boljšo integracijo, lažjo namestitev in - najpomembnejše - večjo stopnjo ponovne uporabe. Slovenske organizacije se dobro zavedajo tehnoloških prednosti storitvene arhitekture. Več kot dve tretjini (68 %) slovenskih organizacij razpoznava visoko povezanost med storitveno arhitekturo in integracijo informacijskih sistemov. Več kot tri četrt (79 %) organizacij se z integracijo ukvarja že več kot 24 mesecev, več kot 5,2% 3'4% 0,9% 3 18,1 % 11,2% 21,6 % 23,3 % Slika 8: Storitvena arhitektura in stopnja integracije informacijskega sistema 11 - najslabše, 10 - najboljše) polovica jih ocenjuje stopnjo integracije kot dobro (slika 8). Slovenske organizacije kot glavne tehnološke prednosti vpeljave storitvene arhitekture identificirajo predvsem: boljšo integracijo obstoječih in novih sistemov, bolj fleksibilno in prilagodljivo arhitekturo informacijske tehnologije in zmanjšanje kompleksnosti informacijskih rešitev, kar prikazuje slika 9. % 0 20 40 60 80 100 Zmanjšanje kompleksnosti informacijskih rešitev Bolj učinkovit razvoj novih storitev oz. proizvodov Zmanjševanje/nadziranje stroškov za IT in e-poslovanje Boljša integracija obstoječih in novih sistemov Bolj fleksibilna in prilagodljiva IT arhitektura Hitrejši razvoj in vzdrževanje obstoječih rešitev Boljša prilagojenost IT-ja poslovnim procesom Bolj učinkovito in hitrejše prilagajanje spremembam Zaščita invest. zaradi uporabe industrijskih standardov I I Zelo pomembno I I Pomembno I I Ni pomembno Slika 9 Tehnološki cilji vpeljave storitvene arhitekture 3.B Tehnologije in platforme V ta namen organizacije razpoznavajo kot ključne tehnologije predvsem XML, spletne storitve, varnostne storitve in tehnologije za podporo poslovnim procesom. Rezultati raziskave kažejo, da kar 87 % slovenskih organizacij že uporablja XML, 71 % jih že uporablja spletne storitve in skoraj 73 % varnostne storitve. Kljub temu, da se kar 51 % slovenskih organizacij zaveda pomena tehnologij za podporo poslovnih procesov, pa jih le 10 % že uporablja ključno tehnologijo v ta namen - BPEL (Business Process Execution Language). Še slabše je zavedanje o pomenu storitvenih vodil ESB (Enterprise Service Bus), ki ga uporablja samo 5,2 % podjetij, kar prikazuje slika 10. Kot glavno platformo za realizacijo storitvene arhitekture je 42 % slovenskih organizacij izbralo Java Enterprise Edition, 33 % Microsoft .NET in kar 13 % obe platformi (slika 11). 12 % organizacij predvideva uporabo drugih platform, kot npr. C/C+ +, Smalltalk, % XML Spletne ESB BREL Varnostne storitve storitve Že uporabljamo I I Smo v fazi vpeljave I I Načrtujemo uporabo v prihodnosti I I Ne uporabljamo I I Ne poznamo Slika 10: Tehnologije za realizacijo storitvene arhitekture LUMP (Linux, MySQL, PHP) ali sporočilne vrste. Iz izpolnjenih anket je razvidno, da v skupini Java EE glede na obstoječe stanje prevladuje Oracle (30 %) pred IBM (23 %) in JBoss (16 %). Glede na načrte slovenski podjetij pa se bo prednost družbe Oracle povečala na 37 % pred IBM (16 %) in BEA (13 %). 12,2% 32,5 % l~~l Java EE □ NET □ Obe Q Drugo Slika 11: Platforme za realizacijo storitvene arhitekture 4 Primerjava s tujino Slovenija na področju storitvene arhitekture ne zaostaja veliko za ZDA. Na podlagi dostopnih podatkov iz konca leta 2005 ugotavljamo, da so poslovni in tehnološki cilji vpeljave storitvene arhitekture zelo podobni, prav tako identificirani riziki in prepreke [10, 11 ]. Slovenska podjetja v primerjavi s podjetji iz ZDA izkazujejo nekoliko manj izkušenj s konkretnimi projekti storitvene arhitekture. V Sloveniji namreč le redke organizacije lahko pokažejo več kot en delujoč sistem, skladen s storitveno arhitekturo, v ZDA pa je precej takih, ki jih lahko pokažejo tri ali več. To je posledica velikih razlik v obsegu finančnih sredstev, namenjenih informatiki, ki jih v ZDA namenijo vsaj za faktor 2- do 3-krat več kot v Sloveniji. Še bolj očitna je razlika med sredstvi, ki jih v Sloveniji in ZDA podjetja namenijo razvoju inovacij in novih storitev na področju informatike, pri čemer je razlika za faktor od 4-do 5-krat v prid ZDA. Slovenska podjetja prav tako izkazujejo slabšo seznanjenost s ključnimi tehnologijami za kompozicijo poslovnih procesov (BPEL) in s storitvenimi vodili (ESB). Posledica tega je tudi manjša prednost tržnega deleža ključnih ponudnikov teh rešitev v Sloveniji v primerjavi z ZDA. 5 Sklepi in priporočila Projekt vpeljave storitvene arhitekture je dolgoročen. Organizacije ne morejo pričakovati poslovnih koristi, dokler se oddelki za informacijsko tehnologijo ne bodo ustrezno izobrazili in izdelali načrtov vpeljave in implementacije storitvene arhitekture. Vpeljava storitvene arhitekture ni zgolj tehnološki projekt, ampak vključuje tudi organizacijsko in poslovno komponento. Vpeljave storitvene arhitekture se mora zavedati celotna organizacija in jo ustrezno podpirati. Brez podpore je uspešnost resno ogrožena, kar ocenjujemo kot najpomembnejši faktor tveganja v slovenskih organizacijah. Zaradi tega morajo vodje projektov vpeljave storitvene arhitekture nujno povečati razpoznavnost poslovnih koristi storitvene arhitekture in zagotoviti ustrezno podporo vodstva. Storitvena arhitektura bo postala nova ključna kompetenca organizacij. To bo dosegla skozi združitev poslovnih zahtev z zmožnostmi informacijskih tehnologij. Pri tem uporablja storitvena arhitektura tehnologije, ki omogočajo izvajanje, konfiguriranje in prilagajanje poslovnih procesov na podlagi kompozicije storitev. Te tehnologije bodo omogočile večjo in bolj celovito poravnavo informacijskih tehnologij in podjetja, kar bo povečalo učinkovitost informatike in omogočilo znatne prihranke denarja ob hkratnem iz- boljšanju storitev, ki jih ponuja informatika. To bo omogočilo vodjem informatike, da bodo prihranke usmerili v razvoj novih storitev ali proizvodov, ki bodo pomembno vplivali na učinkovitost podjetja. S tem storitvena arhitektura naslavlja tudi enega najpomembnejših splošnih ciljev informatike: nameniti več sredstev inovacijam in razvoju novih storitev (in ne le vzdrževanju obstoječih aplikacij in sistemov). Storitvena arhitektura udejanja tudi spremembo načina razvoja aplikacij. Iz modela načrtovanj a/kodiranja/testiranja/nameščanja prehajamo v model sestavljanja/konfiguriranja/testiranja/nadzora. To omogočajo poslovne storitve, ki morajo biti izdelane na ustreznem nivoju granularnosti in so najpomembnejši katalizator povezovanja poslovnih zahtev z zmožnostmi informatike. Zato predstavlja razvoj storitev prvi ključni korak v smeri realizacij storitvene arhitekture. Tega koraka se dobro zavedajo slovenske organizacije in ga v dobršni meri že udejanjajo. Pri tem uporabljajo XML in spletne storitve ter ustrezne varnostne mehanizme. Vendar je treba upoštevati, da se celotni potencial storitvene arhitekture uresniči šele z vpeljavo druge faze - podpore poslovnih procesov. Slovenske organizacije se morajo začeti pripravljati nanjo in se pri tem izobraziti na tehnoloških področjih, povezanih s kompozicijo poslovnih procesov (BPEL) in storitvenimi vodili (ESB). Šele s to fazo bo organizacijam uspelo uresničiti najpomembnejše cilje storitvene arhitekture: izboljšati učinkovitost poslovnih procesov, omogočiti hitrejšo odzivnost na spremembe in boljšo prilagodljivost, bolje integrirane in fleksibilne informacijske sisteme ter zmanjšati kompleksnost informacijskih sistemov. Ker storitvena arhitektura v slovenskih podjetjih še ni celovito implementirana, še ni spremenila modela delovanja informatike, ki se bo prav tako moral spremeniti in se preusmeriti iz tehnološkega fokusa na poslovno-storitveni. Udejanjanje informatike kot storitve z uporabo odprtih storitvenih arhitektur in organsko povezavo poslovanja organizacije in informacijske tehnologije bo naredilo informatiko bolj predvidljivo in omogočilo vzpostavitev storitveno usmerjene informacijske tehnologije. Storitveno usmerjena informacijska tehnologija omogoča delovanje informatike v smislu poslovnih storitev, ki jih menedžerji lahko razumejo. Zaradi tega bo treba ločiti poslovni nivo storitev od tehnološkega nivoja in omogočiti učinkovito sestavljanje storitev, kar bo omogočilo hiter razvoj zahtevanih funkcionalnosti. Literatura [1] Matjaž B. Jurič with Benny Mathew, R Sarang: Business Process Execution Language for Web Services, 2nd Edition, Packt Publishing, January 2006. [2] Erič Pulier, Hugh Taylor, Paul Gaffney: Understanding Enterprise SOA, Manning Publications, 2005. [3] Dirk Krafzig, Karl Banke, Dirk Slama: Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall, 2004. [4] World Wide Web Consortium, Service Oriented Architecture, Web Services Architecture Group, 2003. [5] Matjaž B. Jurič, DougTodd: BPEL Processes and Human VVorkflovv, SOA Web Services Journal, 2006. [6] Matjaž B. Jurič: BPEL: Service composition for SOA, Java World, July 2006. [7] Matjaž B. Jurič: BPEL and Java, theServerSide.com, 2005. [8] Matjaž B. Jurič, Marjan Heričko: J2EE, EAI & Web Services, Web Services Journal, May 2002, Vol 2, Issue 5. [9] Matjaž B. Jurič, Maja Pušnik: Sklad tehnologij za spletne storitve, Objektna tehnologija v Sloveniji, Zbornik konference, 2004. [10] Massimo Pezzini: A Service-Oriented Architecture Maturity Model: VVhere Do You Stand? VVhere Do You VVant to Go?, Gartner Group, 2006. [11] Pušnik, Maja, Jurič, Matjaž B.: Electronic Business Framevvork Evaluation, Informacijska družba 2003, Ljubljana, oktober 2003, str. 178-181. Matjaž B. Jurič je izredni profesor na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Ukvarja se s storitvenimi arhitekturami, kompozicijo poslovnih procesov, integracijo, elektronskim poslovanjem, spletnimi storitvami in optimizacijo zmogljivosti. Je avtor oz. soavtor več knjig, izdanih pri mednarodnih založbah, sodeloval je pri razvoju RMI-IIOP, sestavnega dela Jave in je član BPEL Advisory Boarda. Marjan Heričko je izredni profesor in namestnik predstojnika Inštituta za informatiko na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Njegova področja dela pokrivajo vse vidike objektne tehnologije s poudarkom na upravljanju znanja, sodobnih arhitekturah, metrikah in kakovosti. Svoje izkušnje je predstavil v številnih prispevkih na konferencah in v revijah. Je tehnični koordinator GOT in predsednik konferenc OTS. V zadnjih petnajstih letih je vodil številne projekte in je avtor več kot 300 publikacij. Ivan Rozman je redni profesor in rektor Univerze v Mariboru ter predstojnik Inštituta za informatiko na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Njegovo področje raziskav obsega programsko inženirstvo, načrtovanje informacijskih sistemov, metodologije razvoja programske opreme, proces razvoja programske opreme in kakovost. Je vodja GOT in avtor več kot 500 publikacij. RAZPRAVE Menedžment poslovnih procesov v oskrbovalni verigi - Primer Merkur Jurij Jaklič1, Tatjana Huber9, Marko Svetina9 in Mojca Indihar štemberger1 1 Univerza v Ljubljani, Ekonomska fakulteta 2 Merkur, d. d., Naklo jurij.jaklic@ef.uni-lj.si, tatjana.huber@merkur.si, marko.Svetina©merkur.si, mojca.štemberger@ef.uni-lj.si Povzetek Danes tekmovanje na trgu ne poteka več le med posameznimi podjetji, ampak tudi med celotnimi oskrbovalnimi verigami. V članku prikazujemo, da je za uspešnost oskrbovalne verige potrebna informatizacija, vendar so še pomembnejši drugi vidiki, predvsem organizacijske spremembe in integracija poslovnih procesov, kar vodi do bolj zrelih procesov v vsakem od sodelujočih podjetij in na nivoju oskrbovalne verige. To pomeni potrebo po celovitem menedžmentu poslovnih procesov na nivoju oskrbovalne verige, kar vključuje ugotavljanje zrelosti procesov, modeliranje, sprotno nadzorovanje, spremljanje (merjenje), stalne izboljšave itd. Predstavljeni koncepti so ilustrirani z Merkurjevo oskrbovalno verigo, na kateri z uporabo simulacijskega modeliranja ter metode za ugotavljanje zrelosti procesov analiziramo že izvedene spremembe ter ocenjujemo prednosti izboljšav, ki bi jih bilo mogoče v izvajanju procesov še narediti. Ključne besede: menedžment oskrbovalne verige, menedžment poslovnih procesov, elektronsko poslovanje, procesna usmerjenost, prenova poslovnih procesov, zrelost procesov, simulacijsko modeliranje, študija primera Abstract Business Process Management in a Supply Chain - Čase Merkur In today's global market the main focus of competition is not only betvveen different companies but also betvveen supply chains. The paper shovvs that technological changes are important for effective supply chain management (SCM), hovvever, the main cause of SCM improvements are organizational changes and an integration of business processes that lead to more mature processes in ali involved companies and at the supply chain level. It ca n be realized by using effective business process management methods that include estimation of process maturity, modelling, process analysis and performance measurement, continuous improvement etc. The con-cepts are illustrated with a čase study of Merkur supply chain in vvhich already introduced changes are evaluated with simulation modelling and process maturity measurement methods. Besides that several possible future improvements are analysed. Keyuuords: Supply Chain Management, Business Process Management, E-Business, Process Orientation, Business Process Renova-tion, Process Maturity, Simulation Modelling, Čase Study 1 Uuod Danes se na trgu za kupce in stranke ne borijo več samo posamezna podjetja, ampak celotne oskrbovalne verige. Oskrbovalna veriga je omrežje povezanih, neodvisnih organizacij, ki medsebojno sodelujejo z namenom kontrole, menedžmenta in izboljševanja materialnega in informacijskega toka od dobaviteljev do končnega uporabnika (Supply Chain Coun-cil). Vključene organizacije niso samo proizvajalci in njihovi dobavitelji, ampak tudi prevozniki, skladiščna podjetja ter trgovci na debelo in drobno (Siau in Tian, 2004). Da bodo oskrbovalne verige lahko uspešne, morajo njihovi členi poskrbeti za nemoten materialni in informacijski tok, pri čemer je izredno pomembno, da povežejo svoje poslovne procese, npr. dobavitelj svoj prodajni proces z nabavnim procesom naslednjega podjetja v verigi. Veliko podjetij izboljšuje svoje poslovne procese z različnimi metodami menedžmenta poslovnih procesov (Kovačič in Bosilj - Vukšič, 2005), od stalnega, postopnega izboljševanja do korenitih, enkratnih izboljšav. Največkrat podjetja uporabljajo kombinacijo različnih metod. Tudi v primeru menedžmenta oskrbovalne verige gre predvsem za menedžment poslovnih procesov, ki potekajo skozi več podjetij. Da je povezovanje možno, morajo biti podjetja na to pripravljena, procesi znotraj podjetij morajo biti dobro definirani in dovolj zreli, da jih je mogoče integrirati. Namen članka je pokazati, da je za uspešnost oskrbovalne verige potrebna informatizacija, vendar so vsaj toliko pomembni tudi drugi vidiki, predvsem organizacijske spremembe, ki vodijo do bolj zrelih procesov v oskrbovalni verigi. V članku pokažemo, da je za to potrebno uporabiti metode za menedžment poslovnih procesov na nivoju oskrbovalne verige. V naslednjem razdelku so opisani ključni izzivi menedžmenta oskrbovalne verige, v tretjem razdelku pa menedžment poslovnih procesov kot vzvod za povečanje zrelosti procesov v oskrbovalni verigi. Koncepti so v četrtem razdelku ilustrirani z Merkurjevo oskrbovalno verigo, na kateri z uporabo modeliranja in simulacije ter metode za ugotavljanje zrelosti procesov analiziramo že izvedene spremembe ter ocenjujemo prednosti izboljšav, ki bi jih bilo mogoče v izvajanju procesov še narediti. 2 Ključni izzivi menedžmenta oskrbovalne verige Prav gotovo je za uspešen menedžment oskrbovalne verige pomembna informatizacija. Tako lahko podjetja izbirajo izdelke iz elektronskih katalogov, ki so dostopni na različnih portalih, izmenjujejo podatke (naročila, dobavnice, računi ipd.) v elektronski obliki bolj ali manj avtomatizirano. Uporabljajo lahko tudi orodja za krmiljenje delovnih procesov, ki skrbijo za avtomatizacijo izvajanja nekaterih aktivnosti (npr. različna obveščanja) ter uporabnike opozarjajo na opravila, ki jih morajo opraviti. Tudi razširjene rešitve ERP imajo nadgradnje za menedžment oskrbovalne verige, tako imenovane sisteme SCM. Vendar pa večina problemov pri menedžmentu oskrbovalne verige izhaja iz različnih negotovosti ali pa iz nezmožnosti za koordinacijo številnih aktivnosti in partnerjev. Eden od najpogosteje omenjenih je t. i. učinek volovskega biča (angl. bulhvhip effect). Majhna nihanja v povpraševanju ali stopnji zalog pri zadnjem podjetju v verigi se namreč prenašajo prek celotne verige (Forrester, 1958). Pri tem se povečujejo, saj ima praviloma vsako podjetje v verigi nepopolne informacije o potrebah svojih kupcev in se na to negotovost odzove s prevelikim povečanjem v ravni zalog in posledično še večjim nihanjem za podjetja, ki so nižje v verigi (Trkman et al., 2005). Negotovosti ni mogoče odpraviti samo s pomočjo informacijske tehnologije (IT), ampak je treba deliti informacije, npr. tako da podjetje omogoči dobaviteljem vpogled v stanje svojih zalog (Vendor Managed In-ventory - VMI). To je lahko veliko večji izziv kot informatizacija, saj mnoga podjetja tega niso pripravljena narediti, ker se bojijo, da bodo tako izgubila svojo moč in neodvisnost (Terzi, Cavalieri, 2004). Pomanjkanje zaupanja med poslovnimi partnerji je nasploh eden od glavnih zaviralcev sodelovanja v oskrbovalni verigi (Ireland in Bruce, 2000; Barrat, 2004). Razen tega je eden od glavnih izzivov menedžmenta oskrbovalne verige, kako doseči, da podjetja ne bodo optimizirala samo svojega poslovanja, ne da bi pri tem upoštevala, kako se bodo spremembe odražale pri poslovanju celotne oskrbovalne verige. Pri menedžmentu oskrbovalne verige gre torej predvsem za integriranje ključnih poslovnih procesov v vseh podjetjih v oskrbovalni verigi od končnega uporabnika do prvega dobavitelja. Treba je poskrbeti, da so procesi znotraj posameznih podjetij in na nivoju celotne verige čim učinkovitejši ter posledično stroški nižji, pretočni časi pa krajši. Da je povezovanje partnerjev sploh mogoče, je treba najprej vzpostaviti partnerstvo in tesnejše odnose v obliki dolgoročnih pogodb ter infrastrukturo, ki bo omogočila povezovanje. V literaturi je veliko člankov, ki opisujejo primere integracije in informatizacije poslovnih procesov v oskrbovalnih verigah, tako npr. Muffatto in Payaro (2004) analizirata informatizacijo nabavnih in prodajnih procesov v oskrbovalnih verigah, v katere so vključena nekatera večja italijanska podjetja (Aprillia, Carraro Group, Ducati in Fischer Italia). Prikazujejo različne stopnje integriranosti poslovnih procesov v teh verigah ter vlogo informatike, ki je v nekaterih primerih samo orodje za komunikacijo ter izmenjavo podatkov, v drugih pa omogoča dejansko integracijo procesov. Tudi VVilliamson et al. (2004) analizirajo vlogo informacijske tehnologije v oskrbovalni verigi ter ugotavljajo, da so razen informatizacije, ki izboljša tok informacij med partnerji v verigi, pomembni tudi organizacijski vidiki, zlasti spremembe poslovnih procesov. Čeprav sta ustrezna infrastruktura in informacijska tehnologija pogoj za uspešen menedžment oskrbovalne verige, so glavni izzivi v spremembah poslovnih procesov, ki omogočajo prednosti za vse partnerje v oskrbovalni verigi. 3 Menedžment poslovnih procesov kot vzvod povečevanja zrelosti oskrbovalne verige Pristopi k menedžmentu oskrbovalne verige so v zgodnejših obdobjih poudarjali lokalno optimizacijo vsake aktivnosti v verigi oziroma bolj natančno zniževanje stroškov in povečanje nivoja storitev na vsakem koraku (Steckel et al., 2004). Končni kupec pa dojema izhod iz verige kot enovit produkt oziroma storitev, zato je nujno povezovanje procesov med podjetji, ki sodelujejo v oskrbovalni verigi. To večinoma ni mogoče brez celovite prenove, poenostavitve in standardizacije obstoječih poslovnih procesov na nivoju celotne verige. Prehod pri dejanski integraciji procesov na nivoju celotne oskrbovalne verige je torej podoben prehodu s funkcijske na procesno usmerjenost pri poslovanju znotraj posameznega podjetja. Medorganizacijski procesi morajo biti oblikovani tako, da se lahko celotna veriga ustrezno odzove na spremembe v potrebah strank, na nove poslovne modele konkurentov in na nove tehnološke priložnosti (Wil-liamson et al., 2004). To pomeni potrebo po celovitem menedžmentu poslovnih procesov na nivoju verige, kar vključuje sprotno nadzorovanje, spremljanje (merjenje), stalne izboljšave itd. Integracija poslovnih procesov oskrbovalne verige praviloma ni preprosta. Razlog tiči predvsem v razvoju oskrbovalne verige, ki se praviloma začne kot povezovanje parov podjetij oziroma aktivnosti in se kasneje razširi na večnivojsko verigo. Prehod od medorga-nizacijskih povezav k procesni usmerjenosti na nivoju verige ima lahko več oblik. Prenova procesov v bolj ali manj radikalni obliki je najbolj pogosta oblika organizacijskih sprememb (Smith, 2003). Vključuje analiziranje in spreminjanje poslovnih procesov, ki je lahko radikalno (Business process reengineering, BPR) ali postopno (Continues Process Improvement, CP1). Predvsem v prvem primem je ključni dejavnik uspeha ustrezen menedžment sprememb. Danes najbolj obetajoč pristop k izboljšavam procesov je celovit menedžment poslovnih procesov (Business Process Management, BPM), ki združuje prenovo poslovnih procesov z avtomatizacijo aktivnosti, krmiljenjem delovnih procesov, spremljanjem in nad- Analiziranje in modeliranje poslovnih procesov Informatiziranje procesov Izvajanje poslovnih procesov Spremljanje rezultatov in nadziranje Slika 1 Menedžment poslovnih procesov (Kovačič, Bosilj - Vukšic, 20051 zorovanjem izvajanja procesov (Smith in Fingar, 2003), katerega ključni elementi so prikazani na sliki 1. 3.1 Zrelost procesov v oskrbovalni verigi Pomemben pogoj za uspešno povezovanje procesov in menedžment oskrbovalne verige je procesna usmerjenost (Business Process Orientation, BPO) sodelujočih podjetij. O procesni usmerjenosti podjetij lahko govorimo, kadar v podjetju prevladuje procesni pogled namesto funkcijskega oz. hierarhičnega v vseh razmišljanjih in načinu poslovanja (Škrinjar et al., 2005). Pri tem so posebno pomembni rezultati procesov in zadovoljstvo strank. Empirična raziskava (Mc-Cormack in Johnson, 2001) je potrdila povezavo med procesno usmerjenostjo podjetij in uspešnostjo poslovanja. Osnovna načela procesne usmerjenosti, ki predstavljajo tudi njene ključne značilnosti, so (Ostroff, 1999): ■ Delo je organizirano okrog medfunkcijskih poslovnih procesov in v obliki timov, kar spodbuja ustvarjalno iskanje rešitev problemov. Poudarjene so kompetence in stalno izobraževanje ter usposabljanje zaposlenih. Ustvarja se organizacijska kultura odprtosti in sodelovanja. ■ Lastniki in menedžerji procesov so opredeljeni in imajo dovolj velika pooblastila in odgovornosti. . Odpravlja se delo, ki ne dodaja vrednosti, zmanjšujejo se hierarhije, povečuje se opolnomočenost. ■ Informacijska tehnologija se uporablja za podporo pri doseganju ciljev in ustvarjanju vrednosti za stranke. . Povečuje se povezovanje s kupci in dobavitelji. . Merijo se rezultati procesov, zadovoljstvo strank, zaposlenih in finančnih kazalnikov. Tako dobijo podjetja pravo sliko o uspešnosti poslovanja, saj ta ni več le enostransko predstavljena s preteklim poslovanjem (kar v resnici pokažejo finančni kazalniki). V zvezi s procesno usmerjenostjo lahko govorimo tudi o zrelosti procesov. Znanih je več modelov zrelosti procesov (Harmon, 2003). Vsebujejo stopnje, ki jih dosega podjetje (ali oskrbovalna veriga), ko se razvija od nezrelega do zrelega v smislu procesne usmerjenosti. Namen modela je ocena stopnje zrelosti, na kateri se nahaja podjetje in/ali oskrbovalna veriga, hkrati pa omogoča načrtovanje poti za doseganje višjih stopenj zrelosti. Zrelost oskrbovalne verige je torej odraz zrelosti procesov v njen. Raziskava (Lockamy in McCormack, 2004) je pokazala močno povezanost med zrelostjo oskrbovalne verige in njeno učinkovitostjo ter uspešnostjo. V modelu so opredeljene naslednje stopnje zrelosti procesov v oskrbovalni verigi (McCormack in Johnson, 2001): • (1) Adhoc: Procesi v oskrbovalni verigi so nestruk-turirani in slabo definirani. Mer uspešnosti procesov se ne uporablja, delovna mesta in organizacijska struktura ne temeljijo na horizontalnih procesih. Stroški oskrbovalne verige so visoki, stopnja zadovoljstva strank nizka. . (2) Definirani: Osnovni procesi oskrbovalne veri- ge so definirani in dokumentirani. Delovna mesta in organizacijska struktura vključujejo tudi procesni vidik, vendar so še vedno pretežno funkcijska. . (3) Povezani: Vzpostavljeno je sodelovanje med organizacijskimi enotami, dobavitelji in kupci. Ta stopnja prestavlja dejanski preboj pri doseganju procesne usmerjenosti. Stroški oskrbovalne verige pričnejo padati, opazno je tudi povečanje zadovoljstva strank. • (4) Integrirani: Podjetje sodeluje z dobavitelji in strankami na nivoju procesov. Delovna mesta in strukture temeljijo na procesih. Tradicionalne funkcijske enote so izenačene, včasih celo podrejene procesom oskrbovalne verige. Vzpostavljeni so napredni načini sodelovanja v verigi, na primer skupno napovedovanje. Stroški oskrbovalne verige se bistveno zmanjšajo. ■ (5) Razširjeni: Tekmovalnost temelji na oskrboval- nih verigah. Sodelovanje med podjetji v oskrbovalni verigi je na najvišji stopnji. Obstojajo medorga-nizacijski timi s skupnimi procesi, cilji in širokimi pooblastili. Za določitev stopnje zrelosti procesov oziroma oskrbovalne verige so razvili merske instrumente (McCormack in Johnson, 2001; Lockamy in McCormack, 2004), ki so preizkušeni in preverjeni. Za namen študije primera, ki je predstavljena v naslednjem razdelku, smo uporabili kombinacijo dveh instrumentov (tabela 1). S prvim smo želeli ovrednotiti procesno usmerjenost (del A) znotraj podjetja Merkur in s tem pripravljenost na integracijo procesov na nivoju oskrbovalne verige, drugi pa kaže na stopnjo zrelosti obravnavane oskrbovalne verige (del B). Pri vseh vprašanjih so mogoči odgovori: 1 [sploh ne drži], 2 [pretežno ne drži], 3 [niti drži niti ne drži], 4 [pretežno drži) ter 5 [popolnoma drži]. Tabela 1: Uporabljeni vprašalnik za merjenje stopnje zrelosti procesov in oskrbovalne verige [prilagojen po McCormack in Johnson, 2001; Lockamg in McCormack, 20041 fl.l Procesni pogled 1 Povprečni zaposleni vidi poslovanje podjetja kot niz povezanih procesov. 2 V organizaciji se pogosto uporabljajo izrazi kot so proces, vhod procesa (input, vložek), izhod procesa (output, izložek, rezultat) in skrbnik (lastnik) procesa. 3 Procesi znotraj organizacije so definirani in dokumentirani z jasno opredeljenimi vhodi/izhodi za naše kupce in dobavitelje. 4 Poslovni procesi so definirani tako, da večina zaposlenih razume, kako potekajo. 5 Informatizacija poslovanja temelji na procesih (ne na poslovnih funkcijah). fl.ll Delovna mesta 1 Delovna mesta zahtevajo opravljanje širokega spektra večdimenzionalnih nalog (ne le enostavna opravila). 2 Zaposleni imajo dovolj pristojnosti za reševanje problemov na delovnem mestu. 3 Zaradi sprememb procesov se zaposleni neprestano učijo. fl.lll Menedžment in merjenje procesov 1 V podjetju merimo učinkovitost (čas, stroški ...) poslovnih procesov. 2 Mere učinkovitosti procesov so definirane. 3 Razporejanje virov temelji na procesih (ne na poslovnih funkcijah). 4 Postavljeni so konkretni cilji za posamezne mere učinkovitosti procesa. 5 V podjetju merimo kakovost izhodov (rezultatov) procesov. 6 Vzpostavljena je sprotna kontrola kakovosti podatkov v procesih. 7 Pretok informacij skozi proces poteka nemoteno in učinkovito (npr. ni potreben večkraten vnos istih podatkov). B.l Procesi v oskrbovalni verigi 1 Procesi v oskrbovalni verigi so definirani. 2 Procesi v oskrbovalni verigi so dokumentirani. 3 Zaposleni v oskrbovalni verigi so usmerjeni k strankam. 4 Informacijski sistem dobro podpira procese v oskrbovalni verigi. 5 Organizacijske strukture v oskrbovalni verigi so popolnoma procesne. 6 Uporabljamo mere uspešnosti za procese na nivoju oskrbovalne verige. 3.2 Merjenje ter simulacijsko modeliranje procesou Kot smo ugotovili, je pri menedžmentu procesov oskrbovalne verige oziroma za doseganje višje stopnje njene zrelosti pomembno definiranje procesov, predvidevanje učinkov sprememb pri radikalnejši prenovi in sprotnem izboljševanju procesov ter sprotno merjenje procesov. Za doseganje najvišjih stopenj zrelosti je treba definirati procese in jih spremljati na nivoju celotne oskrbovalne verige (Barrat, 2004; Lengnick-Hall, 1996), saj lahko le tako globalno optimiramo poslovanje verige, ne le za vsako posamezno sodelujoče podjetje. Metrike se ne uporabljajo samo za primerjalno analiziranje trenutnega in scenarijev prenovljenih poslovnih procesov. Procese je treba neprestano meriti in nadzorovati ter na podlagi tega neprestano izboljševati, pravočasno ukrepati v primeru neoptimalne-ga izvajanja procesov in dogodkov v poslovnem okolju, ki zahtevajo odziv. Sprotno merjenje izvajanja procesov oskrbovalne verige omogoča tudi strateške prednosti poleg izboljšav na operativnem in taktičnem nivoju. Hitrejše zaznavanje sprememb v vzorcih povpraševanja, uvajanje novih produktov/storitev, povečanje zadovoljstva strank so le nekateri primeri tovrstnih prednosti sprotnega in dolgoročnega merjenja procesov. Najpomembnejši kazalniki za uspešnost oskrbovalne verige so zadovoljstvo strank ter učinkovitost in uspešnost verige. Ker pa je omenjene dejavnike težko meriti, se ponavadi uporabljajo bolj operativni kazalniki, pri čemer pa je treba poiskati vzročno-posledične povezave med operativnimi kazalniki ter učinkovitostjo in uspešnostjo verige. Na operativnem nivoju lahko uporabljamo kazalnike, kot so celotni stroški, kakovost in čas izvajanja (Persson in Olhager, 2002). Raziskava med vrhnjim menedžmentom je pokazala, da so pretočnost, čas izvajanja ter učinkovita raba virov med najpomembnejšimi (Tatsiopoulos et al., 2002). Kljub različnim pogledom na pomembnost posameznih kazalnikov lahko ugotovimo, da so ključni nizki stroški, kratki časi izvajanja ter prilagodljivost. Pri merjenju in načrtovanju sprememb procesov si lahko tudi v primeru oskrbovalne verige pomagamo s simulacijskem modeliranjem procesov, ki omogoča ovrednotenje različnih scenarijev izboljševanja procesov oziroma primerjavo med različnimi postavitvami procesov (Bosilj-Vuksic et al., 2002; Giaglis et al., 1999). S simulacijskim modeliranjem po navadi podrobneje analiziramo različne vidike (čas/stroški/viri) izvajanja obstoječih procesov (npr. identifikacijo ozkih grl) in primerjavo alternativnih scenarijev prenove. Najprimernejša vrsta simulacije poslovnih procesov je simulacija diskretnih dogodkov (discrete-event simulation, DES) (Seila et al., 2003). Za modeliranje poslovnih procesov je na voljo več tehnik, v študiji primera smo uporabili tehniko procesnih diagramov poteka, saj se je izkazala izredno preprosta za razumevanje (Indihar Štemberger et al., 2004). 4 Študija primera: Oskrbovalna veriga podjetja Merkur, d. d. Predstavljene koncepte lahko ilustriramo s študijo primera, ki obravnava del oskrbovalne verige, v kateri sodeluje podjetje Merkur. Obravnavamo Merkurjev prodajni proces, ki vključuje tudi druga podjetja v oskrbovalni verigi, to so partner, dobavitelj, prevoznik. Partner predstavlja katero koli podjetje, ki pri Merkurju naroča izdelke, prevoznik je podjetje, ki izvaja prevoz blaga, dobavitelj pa je podjetje, ki opravi dobavo v primeru tranzitnega naročila. Modelirali smo tri različice procesa, to je proces pred uvedbo e-poslovanja (AS-VVAS), sedanji proces (AS-IS) in predlog prenove (TO-BE), ki vsebuje tudi nekatere smele, teže uresničljive ideje. V nadaljevanju predstavljamo vse različice procesa z opisi in modeli. Učinke že izvedene prenove in informatizacije ter predlogov dodatne prenove smo ocenili s pomočjo simulacije. Z uporabo vprašalnika za ugotavljanje procesne usmerjenosti smo ocenili tudi stopnjo zrelosti procesa pred uvedbo e-poslovanja in sedanjega procesa. Ob koncu razdelka navajamo tudi ugotovitve o tem, kaj je treba narediti za povečanje zrelosti procesa, ki bo omogočala izvedbo predloga prenove. 4.1 Proces pred uvedbo e-poslovanja Proces (slika 2) se je začel z odločitvijo partnerja o pošiljanju naročila ali povpraševanja v Merkur. Odločitev je bila odvisna od urejenosti komercialnih pogojev med partnerjem in Merkurjem. V primeru, da komercialni pogoji niso bili ustrezno določeni (v približno 40 % primerov), je partner v Merkur posredoval povpraševanje, in sicer največkrat po telefonu, faksu ali elektronski pošti, včasih pa tudi osebno. Na podlagi prejetega povpraševanja je Merkur v informacijskem sistemu izdelal ponudbo in jo po telefonu, faksu ali elektronski pošti posredoval partnerju. Part- ner je pregledal ponudbo in se odločil, ali bo blago naročil. Če se je partner odločil, da bo neposredno naročil blago oz. ga naroča na podlagi prejete ponudbe, je naročilo posredoval v Merkur (po telefonu, faksu ali elektronski pošti). Merkur je prejeto naročilo ročno vnesel v informacijski sistem, naročilo potrdil in partnerju po faksu posredoval potrditev naročila. Merkur naročila ločuje na naročila za odpremo iz lastnega skladišča in naročila za odpremo v tranzitu. V primeru naročila za odpremo iz lastnega skladišča je Merkur na podlagi potrjenega naročila kreiral komisionirni list, ki predstavlja nalog skladišču za komisioniranje in odpremo blaga. Ko je bil komision blaga pripravljen, so v skladišču pripravili prevozni list in ga po faksu posredovali prevozniku. Prevoznik Povpraševanje Povpraševanje/ naročilo? Priprava vpraševanja Pripravljanje javnega narot povpra evanja Prevzemanje blaga Izdelava ilamacijskec zapisnika Reklamacija? Likvidacija računa Sprejemanje povpraševanja Pripravljanje ponudbe Pošiljanje ponudbe Komisioniranje blagi pripravljanje prevozn Pošiljanje prevoznega lista tranzitnega naročil i dobropisa partnerji tranzitnega nar ilovanje nalog? i izdelovanje partnerja :ija ________ Dobavitelj Pripravljanje komisionirnega dobropisa Prevoznik Slika 2: Model procesa pred ouedbo e-poslovanja (AS-VIIAS1 v skladu s prevoznim listom izvede transport blaga do partnerja. V primeru naročila za odpremo blaga v tranzitu Merkur oblikuje tranzitno naročilo in ga posreduje dobavitelju, ki pripravi pošiljko blaga, prevozni list in se s prevoznikom dogovori za prevoz blaga do partnerja. Partner sprejme prispelo pošiljko blaga, preveri količinsko in kakovostno ustreznost pošiljke ter blago ročno ali na podlagi svojega naročila prevzame v skladišče. V primeru količinskih ali kakovostnih neskladij sproži postopek reklamacije. Postopek reklamacije poteka tako, da partner ročno izdela reklamacijski zapisnik in ga po faksu posreduje v Merkur. Merkur sprejme reklamacijski zapisnik, ga ročno vnese v informacijski sistem in reši reklamacijo. Merkur na podlagi odpreme blaga ali reklamacije izdela račun ali dobropis računa ter ga po pošti pošlje partnerju. Partner prejeti račun/dobropis ročno zajame v seznam prejetih računov, ga likvidira (primerja račun s prevzemom blaga) ter ob roku zapadlosti izdela in pošlje plačilni nalog za plačilo blaga Merkurju v banko. Merkur prejeto plačilo primerja z izdanim računom in s tem zaključi prodajo. V primeru tranzitnega naročila Merkur prejme račun/dobropis od dobavitelja in na tej podlagi izdela račun/dobropis partnerju. Merkur dobaviteljev račun/dobropis likvidira in na tej podlagi ob roku zapadlosti pošlje plačilni nalog za plačilo dobavitelju. Vse aktivnosti v procesu smo še natančneje modelirali tako, da smo zbrali podatke o času njihovega iz- Tabela 2: Rezultati simulacije procesa pred uvedbo e-poslovanja IRS-WASI Čas v urah Povprečni čas izvajanja celotnega procesa (ur) 32,16 Čas od začetka procesa do dobave blaga partnerju (ur) 29,63 Stroški v EUR1 Stroški ene izvedbe procesa 181 Stroški dobavitelja 14 Stroški Merkurja 28 Stroški partnerja 42 Stroški prevoznika 105 1 Zneski so zaokro'eni na 1 evro natančno. Skupni povprečni stroški ene izvedbe procesa niso enaki vsoti povprečnih stroškov izvedbe procesa za sodelujoča podjetja, saj pri nekaterih izvedbah procesa ne sodelujejo vsi partnerji (npr. dobavitelj sodeluje le pri tranzitnem naročilu). vajanja (npr. 5 do 60 minut za aktivnost pripravljanje ponudbe, ki jo izvaja Merkur) ter stroških dela njihovih izvajalcev. Nato smo s pomočjo orodja za simulacijsko modeliranje poslovnih procesov iGrafx Pro-cess izvedli simulacijo 20-dnevnega izvajanja procesa, pri čemer smo na podlagi izkušenj predpostavili, da partnerji tvorijo novo naročilo oz. povpraševanje vsakih 30 sekund. Ocenjevali smo povprečne čase izvajanja procesa ter stroške dela. Ostali stroški v simulacijah niso zajeti. Rezultati simulacije izvajanja procesa pred uvedbo e-poslovanja so prikazani v tabeli 2, ki prikazuje čas izvajanja celotnega procesa do dobave blaga partnerju. Razen tega tabela prikazuje še stroške izvedbe procesa za celoten proces ter za posamezna, v procesu udeležena podjetja. 4.2 Sedanji proces Proces je bil v zadnjih letih informatiziran in ob tem tudi delno prenovljen z rešitvijo za e-poslovanje - uvedena je spletna B2B trgovina Merkur Partner. Zaradi tega je izvedba procesa preprostejša in hitrejša, česar na prvi pogled iz grafičnega dela modela procesa ni videti, zato tudi slike ne prikazujemo ponovno. Postopki pri pošiljanju in sprejemanju povpraševanj in naročil partnerja so hitrejši (npr. čas izvajanja aktivnosti pošiljanje povpraševanja, ki jo opravlja partner, je skrajšan iz 2 minut na 1 minuto). Ker ima partner dostop do podatkov o prodajnem programu in prodajnih pogojih prek spletne rešitve, ni več potrebno izdelovati povpraševanj v tolikšnem obsegu kot prej (samo v 30 % primerov). Razen tega poteka obdelava naročila v Merkurju veliko hitreje (npr. čas izvajanja Merkujeve aktivnosti potrjevanje naročila je skrajšan s 5-10 minut na 3-5 minut), ker so v Merkurjev informacijski sistem iz spletne trgovine preneseni vsi podatki o naročilu partnerja. Po prenosu naročila v Merkurjev informacijski sistem se avtomatsko ločijo tudi naročila za odpremo iz lastnega skladišča in naročila za odpremo v tranzitu. Vse druge aktivnosti v procesu se izvajajo na isti način kot prej. Rezultati simulacije izvajanja sedanjega procesa in primerjava z rezultati za proces pred uvedbo e-poslovanja so prikazani v tabeli 3. V fazi preverjanja veljavnosti modela smo ocenili, da rezultati ustrezajo dejanskemu stanju. Vidimo, da se je čas izvajanja procesa skrajšal, prav tako so se znižali stroški, pri čemer je izmed sodelujočih podjetij največ pridobilo podjetje Merkur, ki so se mu stroški dela znižali kar za četrtino. Tabela 3: Rezultati simulacije sedanjega procesa IflS-IS) in primerjava s procesom pred uvedbo e-poslovanja (AS-IAfAS) Čas v urah Skrajšanje glede na AS-UVAS Povprečni čas izvajanja celotnega procesa 30,21 -6% Čas od začetka procesa do dobave blaga partnerju 27,57 -7% Stroški v EUR Znižanje stroškov glede na flS-WflS Stroški ene izvedbe procesa 170 -6% Stroški dobavitelja 13 -6% Stroški Merkurja 20 -26 % Stroški partnerja 38 -8% Stroški prevoznika 105 0% S pomočjo odgovorov na vprašalnik za ocenjevanje zrelosti procesov v oskrbovalni verigi, prikazanega v tabeli 1, smo ocenili tudi povečanje procesne usmerjenosti. Zbirni rezultati so prikazani v tabeli 4. Glede na odgovore lahko ocenimo, da je bila stopnja zrelosti procesa pred uvedbo e-poslovanja med 2 (definiran) in 3 (povezan). Po informatizaciji se je zrelost procesa povečala, zlasti na področju procesnega načina razmišljanja. Vendar pa še ne moremo govoriti o integriranih procesih v oskrbovalni verigi, niti o pravem menedžmentu procesov, kar kažejo najnižje povprečne ocene teh dveh sklopov vprašanj. Ocenjujemo, da je zrelost zdajšnjega procesa na stopnji 3 (povezan). Tabela 4: Zbirni rezultati samoocenjevanja procesne usmerjenosti AS-IS AS-UVAS A.l Procesni pogled 4 2,8 A.II Delovna mesta 3 2,6 A.III Menedžment in merjenje procesov 2,9 2,3 B.l Procesi v oskrbovalni verigi 3 2,2 Čeprav so opisane spremembe skrajšale čas izvajanja procesa ter znižale stroške dela, samo hitrejši tok informacij med podjetji v oskrbovalni verigi, ki ga omogoča informatizacija, še ne prinaša vseh možnih izboljšav. 4.3 Predlog prenove V prihodnje namerava podjetje Merkur proces še bolj radikalno spremeniti v smeri poenostavitve, hitrejše izvedbe in znižanja stroškov poslovanja za vse udele- žence v procesu. Za dosego teh sprememb bo treba temeljito organizacijsko in informacijsko spremeniti področje poslovnih procesov. Predlagane spremembe so smele, zato bo za njihovo uvedbo potrebna velika podpora na vseh vodstvenih ravneh. Organizacijske spremembe, ki jih predlagamo, so: . B2B portal Merkur Partner mora omogočiti dostop do vseh relevantnih informacij, na podlagi katerih se partner odloča o naročilu blaga. S tem povpraševanja partnerja in ponudbe Merkurja niso več potrebni. . S čim večjim številom partnerjev sklenemo prodajne pogodbe, ki pogoje poslovanja opredeljujejo natančno do te mere, da z uporabo dogovorjenih pogojev maksimalno avtomatiziramo prodajni proces. • Celovita uvedba elektronske izmenjave podatkov na vseh relevantnih tipih sporočil, tako na nabavni kot na prodajni strani. Poleg spletne B2B trgovine Merkur Partner se bo v procesu elektronske prodaje izmenjevalo še več podatkov: . Nabavno naročilo (partner-Merkur). Prodajni pogoji bodo vnaprej točno opredeljeni, zato povpraševanje partnerja pri posamezni transakciji ne bo več potrebno. • Potrditev naročila (Merkur-partner) ■ Prevozni list (Merkur-prevoznik-partner) . Tranzitno naročilo (Merkur-dobavitelj) . Račun (dobavitelj-Merkur-partner) Model predloga prenove je prikazan na sliki 3. Vidimo, da je model precej poenostavljen, saj zaradi sprememb veliko aktivnosti ni več potrebnih, preostale pa večinoma potekajo hitreje. Izvedli smo tudi ponovno simulacijo izvajanja procesa in dobili rezultate, ki so prikazani v tabeli 5. Vidimo, da je prenova procesa omogoča dodatno skrajšanje časa in dodatno znižanje stroškov. Iz tabele je razvidno, da koristi prenove niso enake za vsa podjetja. Tako se npr. stroški dela prevoznika znižajo minimalno, saj jih prinaša predvsem izvajanje prevoza, prihranki drugih treh sodelujočih podjetij pa so precej visoki, pri čemer je dodatno znižanje stroškov dela zaradi prenove zanimivo predvsem za Merkur. Predlagane spremembe prinašajo prihranke pri izvajanju obravnavanega procesa vsem sodelujočim podjetjem, kar je pogoj za pridobitev interesa za sodelovanje v projektu prenove pri vseh sodelujočih podjetjih, saj predlagane organizacijske spremembe, ki so potrebne Slika 3: Model predlaga prenove procesa (TO-BE) ( Začetek)— Sprejemanje revoznega lista in Pripravljanje nabavnega naročila Preverjanje količinske/kakovostne ustreznosti Pošiljanje nabavnega naročila Pošiljanje reklamacijskega zapisnika Izdelava reklamacijske« zapisnika Prevzemanje blaga Sprejemanje računa/dobropis: Likvidacija računa Pošiljanje plačilnega naloga Sprejemanje nabavnega naročila Pošiljanje računa/dobropisi partnerju Sprejemanje reklamacijskega zapisnika Reševanje reklamacije partnerja Pošiljanje prevoznega lista Komisioniranje blaga ir pripravljanje prevozneg Pripravljanje komisionirnega Izdelovanje računa/ dobropisa Pošiljanje plačilnega naloga 'čilo? - tranzitnega naročil i Likvidiacija računa dobropisa Posredovanje ranzitnega naročil i ‘US? (Konec) Sprejemanje tranzitnega naročila °r£r Izdelovanje računa/ dobropisa Pošiljanje prevoznega lista Komisioniranje blaga irj pripravljanje prevozneg*— Pripravljanje komisionirnega Sprejemanji prevoznega t za integracijo procesa, zadevajo vse. Največji interes pa je pričakovati pri partnerjih, saj bodo spremembe pomenile poleg znižanja stroškov tudi skrajšanje časa do dobave ter zmanjšanje števila reklamacij, kar pomeni višjo kakovost storitve. Mogoče bi bilo tudi znižati stroške prevoznika, npr. z uporabo metod za optimizacijo transporta. Ocenjujemo, da bi navedeni predlogi povečali zrelost procesa na stopnjo 4 (integriran), ki je pravzaprav tudi pogoj za predlagane spremembe. Seveda pa to zahteva v podjetju Merkur in partnerskih podjetjih večje spremembe v smislu povečevanja procesne usmerjenosti, npr. delovna mesta in strukture, temelječe na procesih. Vzpostaviti je treba tesnejše sodelovan- je in višji nivo zaupanja med v verigi sodelujočimi podjetji. Uvedba takšnih sprememb je praviloma precej zahtevnejša od informatizacije v smislu uvajanja nove informacijske tehnologije. Tabela 5: Rezultati simulacije predloga prenove ITD-BE) ter primerjava s sedanjim stanjem (flS-IS) in procesom pred uvedbo e-poslovanja IflS-UUflS) Čas v urah Skrajšanje glede na AS-IS Skrajšanje glede AS-1AJAS Povprečni čas izvajanja celotnega procesa 25,94 -14% -19% Čas od začetka procesa do dobave blaga partnerju 25,50 -8% -14% Stroški v EUR Znižanje stroškov glede na AS-IS Znižanje stroškov glede na AS-IA/AS Stroški ene izvedbe procesa 142 -16% -22% Stroški dobavitelja g -29% -33% Stroški Merkurja 8 -63% -73% Stroški partnerja 25 -34% -39% Stroški prevoznika 104 -1 % -1 % 5 Sklep Na podlagi prikazane študije primera vidimo, da menedžment poslovnih procesov na nivoju oskrbovalne verige prinaša prednosti za vsa sodelujoča podjetja. Zmanjšanje stroškov dela in skrajšanje časa izvajanja procesa se pojavi že, ko je proces povezan in ustrezno informatiziran, saj se na ta način pohitri in poenostavi informacijski tok. To poveča tudi procesno usmerjenost, vendar samo z informatizacijo ne moremo dosegati stopnje zrelosti procesa višje od 3 (povezan). Za doseganje višjih stopenj zrelosti, kot npr. v zgornjem primeru stopnje 4 (integriran) so potrebne tudi večje organizacijske spremembe, npr. omogočanje vpogleda v stanje zalog dobavitelja. Za to je potrebno povečanje zaupanja med sodelujočimi podjetji in sklepanje dolgoročnega sodelovanja. Kot smo s pomočjo simulacijskega modeliranja pokazali na primeru Merkurjeve oskrbovalne verige, so učinki takšnih sprememb v smislu skrajšanja izvajanja procesov in znižanja stroškov dela lahko kar veliki. Prikazani primer zaradi želje po ne pretirani kompleksnosti sicer ne obravnava celotne oskrbovalne verige, vendar prikazane koncepte na popolnoma enak način lahko uporabimo tudi v primeru več sodelujočih podjetij. Literatura [1] Barrat, M. (2004). Understanding the Meaning of Collaboration in the Supply Chain, Supply Chain Management: An International Journal, 9(1): 30-42. [2] Bosilj - Vukšič, V., Indihar Štemberger, M., Jaklič, J., & Kovačič. A. (2002). Assessment of E-Business Transformation Using Simulation Modelling, Simulation, 78(12): 731-744. [3] Forrester, J.W. (1958). Industrial Dynamics: a Major Breakthrough for Decision Makers, Harvard Business Review, 36(4): 37-66. [4] Giaglis, G. M., Paul, R. J., & Hlupic, V. (1999). Integrating Simulation in Organizational Design Studies, International Journal of Information Management, 19(3): 219-236. [5] Harmon, R (2003). Business Process Change: A Manager’s Guide to Improving, Redesigning, and Automating Processes, Morgan Kaufmann Publishers, San Francisco. [6] Indihar Štemberger, M., Jaklič, J., & Popovič, A. (2004). Suitability of process maps for business process simulation in business process renovation projects, 16th European Simulation Symposium, Budapest, October 17-20,2004. Proceedings of the 2004 European Simulation Symposium, Uredila: Lipovszky, G., & Molnar, I. Budapest, October 17-20, 2004. San Diego: SCS, 197-205. [7] Ireland, R., & Bruce, R. (2000). CPFR: 0nly the Beginning of Collaboration, Supply Chain Management Review, 4(4): 80-87. [8] Kovačič, A., & Bosilj - Vukšič, V. (2005). Management poslovnih procesov, GV založba, Ljubljana. [9] Lengnick-Hall, C. A. (1996). Customer Contributions to Quality a Different View of the Customer-Oriented Firm, Academy of Management Revievv, 21(3): 791-824. [10] Lockamy, A., & McCormack, K. (2004). The Development of a Supply Chain Management Process Maturity Model Using the Concepts of Business Process Orientation, Supply Chain Management: An International Journal, 9(4): 272-278. [11] McCormack, K., & Johnson, W. (2001). Business Process Orientation: Gaining the E-Business Competitive Advantage, St Lucie Press, Delray Beach, FL. [12 Muffatto, M., & Payaro, A. (2004). Integration of Web-Based Procurement and Fulfillment: A Comparison of Čase Studies, International Journal of Information Management, 24(4): 295-311. [13 Ostroff, F. (1999). The Horizontal Organization, 0xford University Press, Oxford. [14] Persson, F., & Olhager, J. (2002). Performance Simulation of Supply Chain Designs, International Journal of Production Economics, 77(3): 231-245. [15] Seila, A.F., Ceric, V., & Tadikamalla, R (2003). Applied Simulation Modeling, Thomson Learning, Southbank, Australia. [16] Siau, K., &Tian, Y. (2004). Supply Chains Integration: Architecture and Enabling Technologies, Journal of Computer Information Systems, 44(3): 67-72. [17] Smith, H., & Fingar, R (2003). Business Process Management: The Third 1/Vave. Meghan-Kiffer Press, Tampa. [18] Smith, M. (2003). Business Process Design: Correlated of Success and Failure, The Quality Management Journal, 10(2): 38-49. [19] Steckel, J., Gupta, S., & Banerji, A. (2004). Supply Chain Decision Making: Will Shorter Cycle Times and Shares Point-of-Sale Information Necessarily Help? Management Science, 50(4): 458-464. [20] Škrinjar, R., Indihar Štemberger, M., Dimovski, V., & Škerlavaj, M. (2005) Procesna usmerjenost - temelj uspešnega poslovanja, Uporabna informatika, 13(3): 136-145. [21] Tatsiopoulos, I. R, Panayiotou, N. A., & Ponis, S. T. (2002). A Modeling and Evaluation Methodology for E-Commerce Enabled BPR, Computers in lndustry, 49(1): 107-121. [22] Terzi, S., & Cavalieri, S. (2004). Simulation in the Supply Chain Context: a Survey, Computers in lndustry, 53(1): 3-16. [23] Trkman, R, Jaklič, J., Indihar Štemberger, M., & Groznik, A. (2005). Vloga učinkovite izmenjave informacij pri integraciji procesov znotraj oskrbovalne verige, Zbornik posvetovanja DSI - Dnevi slovenske informatike 2005. Uredili: Novakovi, A. et al. Portorož, 13.-15. april 2005. Ljubljana: Slovensko društvo Informatika, 21-26. [24] VVilliamson, E. A., Harrison, D. K., & Jordan, M. (2004). Information Systems Development within Supply Chain Management, International Journal of Information Management, 24(5): 375-385. Jurij Jaklič je izredni profesor poslovne informatike na Ekonomski fakulteti v Ljubljani. Osrednja področja zanimanja njegovega pedagoškega in raziskovalnega dela so poslovna inteligenca, menedžment poslovnih procesov in menedžment podatkov, Je član Inštituta za poslovno informatiko pri Ekonomski fakulteti, v okviru katerega je sodeloval pri več raziskovalnih in svetovalnih projektih v slovenskih organizacijah. Tatjana Huber je zaposlena kot vodja projektov v Merkur, d.d., Naklo, kjer se ukvarja z razvojem in implementacijo sistemov za e-poslovanje. Diplomirala je leta 1996 na Fakulteti za organizacijske vede v Kranju. Na tej fakulteti nadaljuje magistrski študij, smer elektronsko poslovanje. Aktivno se udeležuje raznih strokovnih konferenc in je avtorica ter soavtorica več strokovnih člankov in referatov. Marko Svetina je zaposlen kot vodja projektov v Merkur, d. d., Naklo, kjer se ukvarja z razvojem sistemov za poslovno inteligenco in sistemov e-poslovanja. Diplomiral je leta 1991 na Fakulteti za organizacijske vede v Kranju. Na tej fakulteti je nadaljeval z magistrskim študijem, ki ga je zaključil leta 1996. Aktivno se udeležuje raznih strokovnih konferenc in je avtor ter soavtor več strokovnih člankov in referatov. Mojca Indihar Štemberger je izredna profesorica za poslovno informatiko na Ekonomski fakulteti v Ljubljani, kjer predava na dodiplomskem in podiplomskem študiju. Njeno raziskovalno delo pokriva menedžment poslovnih procesov in tudi druga področja poslovne informatike; objavila je več znanstvenih in strokovnih člankov v tujih in domačih revijah ter prispevkov na konferencah. Sodelovala je pri aplikativnih projektih s področja prenove poslovnih procesov in strateškega načrtovanja informatike, ki jih je izvajal Inštitut za poslovno informatiko na Ekonomski fakulteti. Od leta 2000 aktivno sodeluje pri pripravi programa posvetovanja Dnevi slovenske informatike, nekaj let je bila predsednica organizacijskega in programskega odbora. Je članica programskega odbora mednarodne poslovne konference Management poslovnih procesov in predsednica mednarodne znanstvene konference InSITE 2007, ki bo junija 2007 na Ekonomski fakulteti v Ljubljani. RAZPRAVE 0 Upravljanje znanja - informacijska podpora ali sistem za ohranjevanje znanja? Katja Harej, Tatjana VVelzer Družovec, Romana Vajde Horvat Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko, Inštitut za informatiko katja.harej@uni-mb.si Povzetek Organizacijsko znanje in upravljanje znanja postajata vse bolj pomembna kot ključna vira konkurenčne prednosti. Vse prevečkrat pa se zdi, da upravljanje znanja prepoznamo kot informacijski sistem za podporo procesu ohranjanja znanja v organizaciji. Zato želimo v članku predstaviti pojem upravljanja znanja, konkurenčne prednosti, ki jih lahko dosežemo z dobro definiranim procesom upravljanja znanja, in kako se izogniti nevšečnostim, ki pretijo pri uvedbi procesa. Na koncu bomo predstavili še splošni model, ki narekuje upravljanje znanja v organizaciji v sklopu petih faz. Abstract Knovvledge Management Should Be More than Just an Information Support Organizational knovvledge and knovvledge management are receiving more and more attentiveness as key resources for competitive advantage. Hovvever, it often seems that knovvledge management is recognized as an information system for keeping the knovvledge vvithin the organization. Thus, the term Knovvledge Management is presented in the paper. VVhat are the benefits of a vvell defined knovvledge management process and hovv to avoid process implementation failure is also presented. At the end, a particular attention is given to general five steps model for knovvledge management. 1 UVOD Upravljanje znanja v organizaciji je podporni proces dela, v katerem sodelujejo vsi zaposleni. Ti naj bi pri procesu upravljanja znanja sodelovali na podlagi lastne odločitve. Vsaka organizacija si namreč želi ohraniti znanje, pridobljeno na specifičnem delovnem mestu znotraj korporativnega obsega. To pomeni, da organizacija želi, da vse pridobljeno znanje posameznega zaposlenega (tudi vodstva) trajno prenesemo v organizacijski spomin in ga poskusimo čim večkrat ponovno uporabiti. Podjetja, ki uspešno upravljajo znanje, vidijo v zajemanju tihega znanja zaposlenih konkurenčno prednost, ki se kaže v obliki inovacij. Zato zaposlene spodbujajo in nagrajujejo za sodelovanje pri procesu upravljanja znanja. Najpogostejše vprašanje je, kako prepričati zaposlene, da svoje znanje in izkušnje prenesejo v organizacijsko bazo znanja. Odgovor na to je v večini primerov sprememba organizacijske kulture, ki vključuje način poslovanja, kakor tudi kulturo mišljenja organizacije, stanje medsebojnih odnosov, poklicno etiko in vrednote posameznikov, ki se združene odražajo v vrednotah organizacije. Spremembe v organizaciji se večinoma težko sprejemajo. Za vsak nov proces dela v organizaciji je potreben čas. Za učinkovitejši proces upravljanja znanja v organizaciji si poskušamo pomagati tudi z informacijsko tehnologijo (IT), ki pa je predvsem za male in srednje velike organizacije cenovno težko dostopna ali celo nedostopna. V tem primeru lahko te organizacije podrobneje definirajo proces upravljanja znanja, ki je lahko podobno učinkovit tudi brez celovite podpore IT. V večjih organizacijah, v katerih količina informacij in novo pridobljenega znanja eksponentno narašča iz dneva v dan, je podpora IT zelo koristna in potrebna. Pred predstavitvijo procesa upravljanja znanja si poglejmo podrobnejšo definicijo upravljanja znanja in prednosti, ki jih le-to lahko prinese v organizacijo. 2 UPRAVLJANJE ZNANJA U ORGANIZACIJI Pojem upravljanje znanja lahko obravnavamo ločeno glede na besedi, ki ga sestavljata. Večkrat se uporabljajo tudi termini, kot npr. izmenjava znanja, organizacijsko učenje ali upravljanje pridobivanja intelek-tualnosti (Barth, 2000). Pri pregledu literature je Scholl s soavtorji (Scholl et al., 2004) ugotovil, da imajo avtorji na temo definicije upravljanja znanja precej različna mnenja. Nekateri namreč menijo, da je poglavitni proces in osrednja tema upravljanja znanja proces izmenjave znanja, vendar uspešno upravljanje znanja zahteva upoštevanje celotnega cikla procesiranja znanja, na primer: kreiranje, shranjevanje, širjenje/izmenjavo in uporabo znanja. Razviti so bili tudi modeli, za katere se zdi, da je proces širjenja in uporabe znanja bolj pomemben od drugih procesov, vključenih v upravljanje znanja. Obstajajo tudi mnenja, da so inteligentne informacijske rešitve nujni pogoj za upravljanje znanja. Tehnologija nam je dala možnost upravljati znanje (Nathanson, 2002). Danes namreč obstajajo t. i. virtualne skupnosti (angl. communities of practice), v okviru katerih si udeleženci izmenjujejo znanje s pomočjo forumov, klepetalnic ipd. s podporo preprostejše tehnologije in ne nujno inteligentne informacijske rešitve. V tem primeru je način upravljanja znanja prepuščen odločitvi organizacije. Inteligentne rešitve IT za majhne in srednje velike organizacije v večini niso cenovno dosegljive. Ni pa ocen oz. poročil, da bi bile takšne rešitve boljše preprostih, cenovno dostopnih virtualnih skupnosti. Virtualne skupnosti dajejo namreč ljudem s podobnimi interesi možnost druženja, komuniciranja in medsebojne izmenjave idej in drugih informacij prek interneta. S pomočjo teh aktivnosti posamezniki vzpostavljajo medsebojne vezi z drugimi člani skupnosti in s skupnostjo kot celoto. Proces izmenjave znanja je na ta način zelo učinkovit. Avtorji, ki nasprotujejo mnenju, da je za učinkovito upravljanje znanja nujna informacijska tehnologija, to utemeljujejo s tem, da je človek tisti, ki posreduje in uporablja znanje in da je uspešnost upravljanja znanja na podlagi informacijske tehnologije kot osrednjega dejavnika že na samem začetku obsojena na neuspeh (Bernik et al., 2002). Spet drugi avtorji so mnenja, da se upravljanje znanja od organizacije do organizacije razlikuje glede na naravo samega znanja. V organizaciji, ki se ukvarja npr. z razvojem programske opreme, se pojavlja drugačno znanje kot npr. v organizaciji, ki nudi zdravstvene storitve. Definicija področja in namena uporabe znanja naj bi po nekaterih prepričanjih predstavljala podlago za uspešno upravljanje znanja. Poglejmo torej, kaj pomeni upravljanje znanja. 2.1 Kaj pomeni upravljanje znanja Za definicijo pojma upravljanja znanja potrebujemo najprej definiciji znanja in upravljanja, šele nato ju lahko integriramo v celoto pojma upravljanja znanja. Znanje je opredeljeno kot osebno prepričanje, ki povečuje posameznikovo sposobnost za izvajanje učinkovitih akcij (Alavi in Leidner, 1999). V tem kontekstu akcija od posameznika zahteva fizično sposobnost (kot npr. igranje tenisa) ali kognitivno/intelektualno aktivnost (npr. reševanje problemov) ali oboje (npr. operacija, ki hkrati vključuje tako ročne spretnosti kot kognitivne elemente - v tem primeru v obliki poznavanja anatomije človeka in medicine na splošno). Znanje lahko dalje opredelimo kot del hierarhije sestavljene iz podatkov, informacij, znanja in modrosti (Bock, 1998): . podatek je predstavitev dejstva, . informacija je dejstvo z vsebino in perspektivo (ovrednoteni podatki v specifični situaciji), . znanje je informacija s smernico za akcijo (z znanjem odgovarjamo na vprašanja kako), . modrost je razumevanje, katero znanje uporabiti za kakšen namen (navadno z modrostjo odgovarjamo na vprašanja zakaj in kdaj). Upravljanje (menedžement) je lahko tudi del neke hierarhije, ki vključuje nadzor, upravljanje in vodenje (povzeto po Bock, 1998): . Pri nadzoru se ukvarjamo s posameznimi opravili in ljudmi. Delujemo na operativnem nivoju organizacije ali oddelka. • Pri upravljanju se ukvarjamo s skupinami, pri čemer nam prioritete predstavljajo postopki za dosego določenega cilja. ■ Vodenje se ukvarja z namenom in spremembami na strateškem nivoju. Organizacijsko upravljanje znanja je način, kako organizacije ustvarjajo, zajemajo in ponovno uporabijo znanje za lažje doseganje zastavljenih ciljev. Lahko ga opišemo tudi kot proces štirih delov, povezanih v zanko: . Znanje je ustvarjeno: to se zgodi v glavah ljudi. . Znanje je zajeto: je zapisano na papir v poročilu, shranjeno na računalnik na kakršen koli način ali je preprosto zapomnjeno. ■ Znanje je klasificirano in modificirano: klasificiranje lahko pomeni le dodatek ključnih besed; lahko pomeni indeksiranje. Modifikacija lahko doda vsebino, ozadje ali znanja, ki pomagajo pri kasnejši ponovni uporabi informacij oz. znanj. Uspešnost tega koraka v organizaciji lahko testiramo s pomočjo zaposlenih tako, da opazujemo, kako bodo našli in uporabili znanje, kadar ga potrebujejo. . Znanje si delimo: ko se znanje deli in uporablja, je nehote tudi modificirano s strani tistih, ki ga uporabljajo. To nas popelje nazaj na začetek - ustvarjanje novega znanja. Upravljanje znanja je organiziran proces pridobivanja, organiziranja in posredovanja tako tihega kot eksplicitnega znanja zaposlenih, da bi ga lahko drugi zaposleni uporabljali za bolj učinkovito in produktivno delo (Alavi in Leidner, 1999). Sisteme za upravljanje znanja (angl. Knovvledge management systems) lahko opredelimo kot orodja za pomoč pri učinkovitem upravljanju znanja, ki poleg pomoči pri kreiranju, zbiranju, organiziranju in širitvi znanja (Alavi in Leidner, 1999), vključujejo med drugim tudi repozitorije dokumentov, podatkovne baze znanja, ponujajo možnost beleženja razprav zaposlenih in tehnologije filtriranja podatkov (Hahn in Sub-ramani, 2000). 2.2 Repozitorij znanja Pri upravljanju znanja se pogosto srečamo s pojmi, kot so skladiščenje podatkov ali izmenjava dobrih praks. Pri skladiščenju podatkov in drugih informacij moramo upoštevati: . kako bomo iskali podatke (mine your data) - za to ne potrebujemo nujno programske opreme za rudarjenje s podatki, marveč le različne sklope podatkov, enega poleg drugega, in tako lahko najdemo zanimive povezave. Sklope podatkov je treba prej definirati; e da so podatki in informacije lahko z različnih področij - organizacija lahko poskusi sortirati svoje izdelke ali storitve npr. po količini nakupa, donosnosti, datumu ali času. Predlagane so lahko zanimive ponudbe za stranke (npr. internetna knjigarna Amazon ponuja seznam izbranih knjig ali drugih izdelkov, ki so jih stranke največkrat kupile ob določeni knjigi); • inventuro intelektualnega kapitala - iščemo tisto, kar je z našega stališča vredno, ugotavljamo, kje bi lahko to še uporabili. Poznamo tri tipe repozitorijev znanja. To so strukturirani repozitoriji, nestrukturirani repozitoriji in ljudje. Skupaj tvorijo nepretrgano zvezo v smislu iskanja znanja: e strukturirani repozitoriji - podatkovne baze ali ekspertni sistemi. Karakterizirani so kot preprost način iskanja, ker vključujejo podporo iskanja, kot npr. indeksi, ključne besede, nadzorovano besedišče ipd.; . nestrukturirani repozitoriji vključujejo projektna poročila, zapisnike prodajnih telefonskih klicev in druge besedilne dokumente, pri katerih je treba iskati po prostem besedilu. Oba omenjena repozitorija sta namenjena eksplicitnemu znanju. To znanje je že določeno, znano. Znanje, ki je »nekje tam« zunaj (čaka, da ga najdemo, vidimo in uporabimo), pa je tiho znanje. Vključuje se v tretji tip repozitorijev: . ljudje kot repozitorij znanja - tiho znanje »prebiva« v glavah ljudi. Orodja za doseganje tega znanja so telefonski imeniki (s pomočjo katerih lahko poiščemo določeno osebo, za katero vemo, da poseduje specifično znanje), rumene strani organizacije in drugi imeniki, ki jih ljudje uporabljajo, da pridejo do želenih informacij in znanja. Proces upravljanja znanja torej zajema tako upravljanje z eksplicitnim kot tudi s tihim znanjem. Slednje je za organizacijo še toliko bolj pomembno, saj je teže dosegljivo. Sam proces upravljanja znanja pa naj bi med svoje aktivnosti vključeval tudi izobraževanje zaposlenih, in sicer o upravljanju znanja, medsebojnih odnosih, vodenju, upravljanju in procesu nadzora, o sistemu nagrajevanja, torej o vsem, kar predstavlja kulturo organizacije. Ta izobraževanja vodijo k spremembam v organizaciji, k izboljšanju poslovanja in zmanjševanju ovir pri vzpostavljanju omenjenega procesa. Največjo oviro upravljanja znanja v večini organizacij predstavlja ravno kultura organizacije, ki med drugim dosledno nagrajuje informacije in kopičenje znanja. Razlog za to v tem primeru ni obstoječa programska oprema, temveč vodenje, upravljanje in nadzor v organizaciji. Ker nimajo vse informacije že vnaprej določene vrednosti (Santosus, 2001), ima vsaka posamezna organizacija odgovornost, da določi, katere informacije se lahko shranijo v repozitorij in katere se lahko kvalificirajo kot intelektualne in pomembne za pridobivanje novega znanja. Vse s pomočjo organizacijske kulture. Vključevanje moderne organizacije v virtualno in distribuirano obliko delovanja povzroči, da postanejo odnosi med zaposlenimi, vodji, partnerji, strankami in izvajalci pogostejši in bolj neurejeni. Brez primernega vodenja ali upravljanja se lahko izgubi večina znanja, ki se ustvarja prav med temi odnosi. To tveganje obstaja tako pri tihem in/ali individualnem znanju, kot tudi pri eksplicitnem organizacijskem znanju. Učinkovito upravljanje znanja omogoča organizacijam, da se zaščitijo pred izgubo izkušenj, ko se posamezni zaposleni in partnerji odločijo prekiniti odnose z organizacijo. Omogoča in promovira tudi sodelovanje med različni projektnimi skupinami v organizaciji, med različnimi oddelki in hierarhičnimi nivoji (Resnick, 2004). Na sliki 1 je predstavljena razmejitev med tihim in eksplicitnim znanjem. 2.3 Prednosti upravljanja znanja Upravljanje znanja prinaša določene prednosti, saj so organizacije, ki ga uvajajo ali so ga že uvedle, nekaj korakov pred svojimi konkurenti. Zagovorniki uspešnosti upravljanja znanja pravijo, da se učinkovito upravljanje znanja v organizaciji opazi pri (Stuart, 1996): . zmanjšanem številu napak, . manjšem številu podvojevanj, » hitrejšem reševanju problemov in s tem boljšem odločanju, . hitrejšem usposabljanju novih zaposlenih (Bernik et al„ 2002), . hitrejšem odzivu strankam, povečanih in uspešnejših odnosih s strankami, • reduciranih raziskovalnih in razvojnih stroških, ■ izboljšanih izdelkih in storitvah, ■ povečani samostojnosti zaposlenih, ■ izboljšanju uporabe znanja zaposlenih z razumevanjem vrednosti znanja in nagrajevanju zaposlenih na podlagi prispevka znanja v delovne procese, izdelke in storitve (Bernik et al., 2002), ■ pogosti menjavi delovnih mest v organizaciji, . krčenju organizacije (dovvnsizing), ■ konstantnih spremembah, . globalizaciji, . prehodu z industrijske ekonomije na ekonomijo, temelječo na znanju, . spodbujanju inovacij s spodbujanjem svobodnega izražanja idej (Santosus, 2001). Da bi kar najbolje izkoristili intelektualne prednosti organizacije, je treba znanje medsebojno deliti in se zavedati, da je to temelj za dolgoročno uspešno sodelovanje znotraj in zunaj organizacije. Organizacije morajo ob tem izdelati in ohraniti t. i. »zemljevide znanja« (knowledge maps) ali navigacijska orodja (Stuart, 1996), ki zaposlenim pomagajo pri čim lažjem dostopu do lastnega in novega znanja (kje in kako poiskati znanje v organizaciji). 2.4 Neuspešni poskusi upravljanja znanja Poleg vključevanja najvišjega vodstva v proces upravljanja znanja, je treba za uspešno strategijo upravljanja znanja upoštevati tudi pričakovanja drugih zaposlenih, določiti glavne prioritetne aktivnosti, s pomočjo katerih bomo najlažje dosegli organizacijske cilje in se odločiti, ali bomo proces upravljanja znanja podprli z informacijsko tehnologijo. Ob vsem tem je treba upoštevati najobičajnejše razloge za neuspešno uvajanje upravljanja znanja v organizacijo (Stuart, 1996): . Površni poskusi upravljanja znanja lahko dosežejo prekomerno količino informacij. Organizacije, ki delajo samo zaloge podatkov z zelo malo organiza- Dokumentirane Vem-kako in znanje v informacije, ki lahko 4 ► glavah posameznikov v poenostavijo aktivnosti organizaciji j Izražanja 5 Knjiga Mentalni | Enačbe modeli, Vzorci Tekst v v Zaznavanja Razumevanja ( Izkušnje | Vem-kako - shranjeno, - enostavno zakodirano - komunikacijsko - prenosljivo - lahko izraženo v formalnem, izmenljivem Z znanjem izvajamo aktivnosti in odločitve ) Tiho znanje - osebno, - kontekstno odvisno - težko oblikovano - težko za komunikacijo - težko prenosljivo Slika 1: liho in eksplicitno znanje (Kidwell et al., 20001 cije in brez analize podatkov, imajo pogosto težave s skladiščenjem podatkov in z izgubo časa pri iskanju »založenega materiala«. Preveč informacij je lahko slabše kot biti brez njih. « Učinkovito upravljanje znanja potrebuje vzpostavitev podpore kulture sodelovanja in zmanjšanje tradicionalnega rivalstva med zaposlenimi. Če si nekdo pretvori načelo »znanje je moč« v »kar vem, moram skriti in obdržati zase«, to ni primeren in učinkovit način deljenja virov. • Uspešen trud ne dopušča prostora za neskladja, nedostopnost ali osamljene otoke izkušenj. To pomeni, da upravljanje znanja postane parodija ali konflikt, če vsi viri niso enako dosegljivi v vsej organizaciji, v vsakem oddelku in na vseh oddaljenih lokacijah 24 ur na dan. . Znanje ne živi samo s pomočjo informacijske tehnologije. Tudi uporabniško najprijaznejša orodja ne bodo pomagala pri upravljanju podatkov/informacij/znanja, če ne bodo tesno povezana z ljudmi in delovnimi procesi. Organizacije se takšnim nevšečnostim lahko izognejo s pomočjo (Alvi, 1999; Soliman, 2000; Bernik, 2002): . osredotočanja samo na tisto znanje, ki ga organizacija potrebuje za uspešno poslovanje, . postavitve pomembnega znanja na vidno mesto -jasno definirane poti do znanja in modrosti organizacije, . iskanja znanja tudi zunaj organizacije (pri strankah, dobaviteljih, konkurenci itd.). . jasne razlage zaposlenim, da ima izmenjava znanja poglavitno vrednost organizacije - postavitev kulture znanja, . meritev rezultatov uspešnosti uvedbe procesa upravljanja znanja, • nagrajevanja izmenjave znanja in izkušenj (vodstvo mora kar se da motivirati zaposlene, da bi delili tudi intuitivno znanje), . izbire in implementacije ustrezne strategije upravljanja znanja, . oblikovanja tima in določitev nosilcev upravljanja znanja, . integrirane uporabe ustreznih tehnologij (za podatkovne baze, komunikacijo, iskanje, upravljanje z dokumentacijo itd.). Pri uvajanju upravljanja znanja se pojavljajo tako procesne kot tudi kulturne omejitve (Gartner, Inc, 2002). Na sliki 2 je prikazano, kako se povečuje poslovna vrednost organizacije ob upoštevanju t. i. procesnih omejitev (dostop do informacij/znanja, organizacija znanja, zajem, uporaba in ponovno kreiranje znanja) in kulturnih omejitev, kot so izmenjava znanja, sodelovanje in inovativnost. Ko se proces ponovnega kreiranja znanja združi s kulturo inovativnosti, lahko organizacija uspešno in brez večjih omejitev konkurira na domačem ali tujem trgu. Kreiranje znanja Poslovne vrednosti Procesne omejitve Kreiranje Izmenjava znanja ^Apliciranje znanja Uporaba Apliciranje znanja Izmenjava znanja Izmenjava znanja Organizacija Dostop Izmenjava Sodelovanje Inovativnost Kulturne omejitve Slika 2: Kulturne in procesne omejitve upravljanja znanja (Gartner, Inc., 2002) 3 MODEL UPRAVLJANJA ZNANJA Model upravljanja znanja zajema pet faz upravljanja, ki ustrezajo zajemanju, shranjevanju, interpretaciji, širjenju in pregledovanju notranjega in zunanjega znanja za namene izboljšanja delovanja organizacije. Upravljanje znanja je metoda pretvorbe surovih podatkov v informacije in nato prenos teh informacij v uporabno znanje. Danes so sistemi upravljanja znanja lahko podprti z uporabo informacijskih tehnologij, ki podpirajo upravljanje znanja v organizaciji. Takšna informacijska tehnologija lahko podpre vse faze upravljanja znanja. Tehnologija je potrebna, vendar ne zadostna komponenta za doseganje zadanih ciljev. Nujna pogoja pri tem sta upravljanje delovnih procesov organizacije in seveda kultura organizacije. Na sliki 3 je prikazan model petih faz z dodatkom elementov, ki jih je treba upoštevati za učinkovito upravljanje znanja v organizaciji. Faze in elementi so podrobneje opisani v nadaljevanju (povzeto po Resnick, 2004). 3.1 Zajemanje znanja Zajemanje znanja od zaposlenih in partnerjev je kritično za razvoj baze znanja v organizaciji. Sistem pridobivanja znanja je lahko pasiven ali aktiven (ne nujno podprt z informacijsko tehnologijo). Pri pasivnem sistemu opazujemo komunikacijo med zaposlenimi, opazujemo končne izdelke, ki nastanejo pri delu, in sicer za identifikacijo in zajem informacij in znanja v Širjenje Interpretacija in transformacija Pregledovanje Shranjevanje > podatkovno rudarjenje > semantične mreže > podatkovni modeli ^ zaupanje v kodirane podatke ^ aktivno/pasivno širjenje znanja ^ zasebnost > dostop y upravljanje odnosov in sodelovanja > tehnologija > izbrana politika > aktivn^pasivni zajem > zasebnost Slika 3: Model upravljanja znanja z zahtevami upravljanja v vsaki fazi (Resnick, 2004) bazo znanja. Potencialni kanali za pasivno zajemanje znanja vključujejo priponke elektronske pošte, dnevne rede sestankov, zapisnike sestankov, razna poročila, predstavitve, bele knjige in druge delovne izdelke. Zbiranje in filtracija znanja sta lahko pri pasivnih sistemih problematični zaradi velike količine podatkov, s katerimi upravljajo zaposleni med svojimi vsakodnevnimi opravili. Baza podatkov mora omogočati shranjevanje tako ogromne količine začasnih podatkov med procesom filtriranja, kot tudi shranjevanje končne, prečiščene baze znanja. Najbolj občutljiv faktor pri zajemanju znanja se nanaša na zasebnost zaposlenih. Pazljivo je potrebno upoštevati stopnjo opazovanja dokumentov in komunikacije med zaposlenimi. Značilno je namreč, da povečanje zaščite zasebnosti zaposlenih vodi do pomanjkanja podatkov v bazi znanja. Naslednje vprašanje glede zasebnosti je, ali so rezultirajoče informacije v bazi znanja povezane do zaposlenega, ki jih je ustvaril, in koliko ta povezava vpliva na zasebnost. Anonimnost podatkov zmanjšuje tveganje vdorov v zasebnost, vendar ker je znanje vsebinsko odvisno, je lahko izgubljen pomen informacij, če ne poznamo identitete zaposlenega, ki je ustvaril informacijo. Aktivni sistemi upravljanja znanja zahtevajo, da zaposleni zagotovijo direktne informacije. To pomeni, da od zaposlenih zahtevamo vlaganje dodatnega časa in truda. Prav to lahko privede do zmanjšanja sodelovanja pri upravljanju znanja in je torej kritično vodenje udeležbe in sodelovanja pri aktivnih sistemih. Zaposleni morajo namreč videti »otipljive« prednosti sistema, šele nato si bodo vzeli čas in vnašali lastno znanje v bazo. Ko, ko zaposleni zagotovijo direktne informacije, jih lahko primerno »zakodirajo« in tako znatno zmanjšajo napake v fazi interpretacije. 3.2 Shranjevanje znanja V času, ko se zajemajo surovi podatki ali informacije, je pred organizacijo postavljen primarni izziv identifikacije podatkov/informacij, ki so zanjo relevantni in bi morali biti vključeni v sistem upravljanja znanja. Pri nekaterih sistemih upravljanja znanja je treba vsak vhod preprosto shraniti kot besedilni, avdio ali kateri koli drugi zapis, v katerem lahko uporabniki sistema najdejo ključne besede in kasneje dodano vrednost ali le novo znanje. Na ta način se količina podatkov hitro povečuje. V repozitoriju lahko nastane pravi kaos podatkov. Za večje organizacije je priporočljivo, da se temu čim bolj izogibajo oz. uporabljajo to metodo na zelo omejenih področjih dela. Organizacije večkrat zanemarijo možnost, da lahko s pomočjo informacijskih sistemov podatke »zakodirajo« in jih pretvorijo v uporabne informacije. Vendar so taki sistemi za majhne in srednje velike organizacije še vedno cenovno nedosegljivi. Tako tem ostane edina rešitev prvi način, tj. shranjevanje vsakega vhodnega podatka/ informacije. V pomoč so jim lahko natančno definirani filtri, ki so zelo pomembni za preprečevanje vnosa napačnih podatkov v sistem. Pasivni sistemi so še posebno občutljivi na netočnost, ker lahko napačno presodijo vsebino ali nepravilno kodirajo določene koncepte. Vendar so tudi aktivni sistemi lahko netočni in sicer zaradi napak zaposlenih ali nezdružljivosti med nameni zaposlenih in obliko podatkovnih modelov uporabljenih pri obliki vnosnega vmesnika. Tako je zelo pomembno, da organizacije natančno analizirajo obstoječe sisteme za shranjevanje podatkov oz. definirajo lastne, sebi najprimernejše. 3.3 Interpretacija in transformacija znanja Med zgodnjo fazo razvoja (polnitve), mora baza znanja črpati informacije iz različnih virov in jih smiselno združevati s pomočjo uporabnikov sistema. Bolj napredni informacijski sistemi naj bi bili zmožni pretvoriti različne skupine nepovezanih podatkov v semantično mrežo aplikativnega znanja. To je ključni korak pravega upravljanja znanja, vsebinsko odvisnega, vendar tudi takšen sistem za upravljanje znanja potrebuje precej vloženega truda v času razvoja. Trenutno so procesi transformacije mogoči le na omejenih področjih, kot je podpora strankam (Resnick, 2004, po Gianforte, 2001), ali za specifične tehnološke procese. Informacije iz različnih delov organizacije bi morale biti povezane v semantično mrežo z razumljivo vsebino in vsesplošnostjo. Medtem ko grupiranje informacij specifične domene pomaga pri zmanjševanju kompleksnosti in tudi uporabniku pri navigaciji, je končna moč upravljanja znanja predvsem iskanje medsebojnih povezav po semantični mreži in ustvarjanje novih odnosov, novih relacij. S pomočjo sistema je tako lahko ustvarjeno znanje, ki prej posamezniku ni bilo poznano. Se vedno pa tak proces zahteva aktivno udeležbo zaposlenih pri upravljanju znanja. 3.4 Širjenje znanja Sirjenje znanja s pomočjo sistema nujno potrebuje predhodno shranjevanje. Sirjenje tihega znanja je predvsem odvisno od kulture organizacije in s tem zaposlenih, če so le-ti pripravljeni deliti svoje znanje. Sirjenje organizacijskega znanja je tako omejeno z vidika varnosti in dojemanja koristnosti baze znanja. Nadzor varnosti lahko opravljamo s pomočjo politike odgovornosti in avtorizacijske tehnologije (tehnologije dokazovanja pristnosti). Za povečevanje koristnosti baze znanja v organizaciji je potrebno konstantno manevriranje s pravili avtorizacije. Situacija je kritična predvsem na začetku, ko je baza znanja v organizaciji še dokaj prazna in tako udeleženci igrajo precejšnjo vlogo. Potrebna je namreč določena kritična masa podatkov/informacij, ko zaposleni lahko začutijo in vidijo korist uporabe sistema. Zato je pomembno, da so zaposleni seznanjeni s to kritično maso podatkov/informacij in da spoznajo pomembnost sodelovanja in prispevanja informacij, ki bodo sčasoma ustvarjale neko vrednost. Tako kot pri fazi zajemanja so tudi v tej fazi, fazi širjenja ali razpršitve, vmesniki lahko aktivni ali pasivni. Aktivni sistem zahteva od zaposlenih povpraševanje po podatkih in zagotavlja parametre, ki opisujejo njihovo željo. Pri pasivnem sistemu pa gre za opazovanje aktivnosti zaposlenih in zagotavljanje predlogov oz. namigov tudi z direktnimi informacijami ali povezavami na shranjene dokumente (če je postavljena tudi informacijska podpora). Pasivni sistemi z veliko bazo znanja lahko povzročijo, da dobi uporabnik na stotine predlogov na dan, kar je lahko za uporabnika zelo moteče. Tak sistem bi moral omogočati možnost nastavitev prejemanja informacij in transformiranega novega znanja. 3.5 Presoja in pregled znanja Presoja znanja je faza, ki je v času implementacije sistema upravljanja znanja prevečkrat zanemarjena. Čez čas postane zastarela tudi informacija, ki je bila ob vnosu točna. Nivo zaupanja se spremeni skoraj takoj, ko je informacija vnesena v sistem, saj se tehnologija in trg zelo hitro spreminjata. Nekateri sistemi merijo uporabnost neke informacije glede na to, kako pogosto je uporabljena. Če neki podatek, informacija ali znanje ni bilo uporabljeno v določenem časovnem obdobju, se avtomatsko izbriše ali odstrani. Drugi način izboljševanja uporabnosti baze znanja, ki je lahko implementiran skozi proces presoje, je zaposlitev eksperta za vsebino, ki ročno ocenjuje informacije in povezave med njimi in tako izboljšuje semantično mrežo. Pri velikih bazah znanja je to lahko dolgotrajen proces, vendar lahko bistveno poveča veljavnost in zanesljivost sistema za upravljanje baze znanja in zadovoljstva zaposlenih pri širjenju in uporabi znanja. a SKLEP V uspešnih organizacijah vodje stremijo k izboljševanju učinkovitosti delovnih procesov, odnosov s strankami, uresničevanju njihovih želja in tudi želja zaposlenih. K vsem tem organizacijskim ali poslovnim procesom dodajmo še vse bolj pomemben proces upravljanja znanja. Prednosti tega procesa, kot so npr. hitrejše reševanje problemov, boljše odločanje, znižani razvojni stroški in vse večkrat omenjeno spodbujanje inovacij, so prednosti, ki jih lahko približamo večini drugih procesov v organizaciji in s tem omogočimo še lažji pristop k uvedbi novega procesa, procesa upravljanja znanja. Res je, da organizacije danes čutijo več pritiska kot kadar koli prej, saj trg zahteva vzdrževanje dobro informirane delovne sile, neprestano dvigovanje produktivnosti in pridobivanje konkurenčne prednosti. Upravljanje znanja lahko pripomore k doseganju ciljev ustvarjanja vsestranskega in obširnega ter lahko dostopnega organizacijskega spomina, zato velja, da prej kot začnemo z uvajanjem procesa upravljanja znanja, prej bo organizacija napredovala in bodo rezultati v tem kontekstu uspešnejši. Projekti upravljanja znanja so med seboj različni, tako kot so med seboj različne organizacije, ki jih vpeljujejo. Vendar imajo vse organizacije večinoma iste cilje, in sicer obdržati, analizirati in organizirati znanje, izkušnje in modrost zaposlenih ter zagotoviti čim lažji dostop do tega znanja. Vseeno je treba opozoriti na prekomerno količino informacij, ki lahko kaj kmalu povzroči kaos v bazi znanja. Z dobro definiranim procesom upravljanja znanja se lahko temu izognemo. Medtem ko je učinkovito upravljanje znanja lahko zelo drago, je lahko neučinkovito upravljanje znanja še dražje (Soliman, 2000). 5 LITERATURA Alavi, M., and Leidner, D. E. Knovvledge Management Systems: Issues, Challenges, and Benefits, Communications of the AIS (1:7), 1999. Barth, Steve: Defming Knovvledge Management, julij 2000, vir: http://www.destinationcrm.com/articles/ default.asp?ArticlelD=1400. (28. 6. 2005). Bernik, M., Florjančič J., Rajkovič V.: Upravljanje z znanjem in uporaba informacijskih tehnologij, Organizacija, letnik 55, št. 8, oktober 2002. Bock, Wally: Knowledge Management 101, 1998, vir: http:// www.knowledgepoint.com.au/starting_out/Articles/ so_wb001a.html. (3. 3. 2007). Gartner, Inc.: Knovvledge Management Project Framework, Vl_10, maj 2002. Kahn, J., Subramani, M. R.: A framevvork of knowledge management systems: issues and challenges for theory and practice, Proceedings of the twenty first international conference on Information systems, 2000, str. 302-312. Kidwell, J. J., M. Vander Linde, K.,L. Johnson, S.: Applying Corporate Knowledge Management Practices in Higher Education, Educause Quarterly, No. 4, 2000, vir: http:// www.educause.edu/ir/librarv/pdf/E0M0044.pdf , (28. 6. 2005). Nathanson A., Levi so n A.: Differentiate your firm with Knowledge Management, Legal IT, junij 2002, vir: http:// www.brco.com/downloads/articles/a_AN_AL_KM4.pdf (3. 3. 2007). Resnick, Marc: Knowledge Management in the Information Age, Journal of e-Business, vol. 2, No. 1, junij 2002. Santosus, M., Surmacz, J.: The ABCs of Knovvledge Management, Knovvledge Management Research Center, maj 2001, vir: http://www.cio.com/research/knowledge/edit/ kmabcs.html (28. 6. 2005). Scholl, W., Konig, C., Meyer, B., Heisig, R: The future of Knovvledge Management: an international delphi study, Journal of Knowledge Management, Vol. 8, No. 2, 2004. Soliman F., Spooner K.: Strategies for implementing knovvledge management: role of human resources management, Journal of Knowledge Management, Vol. 4, No. 4, 2000, pp. 337-345. Stuart, Anne: Uneasy pieces: Part 2 Knovvledge Management, junij 1996, vir: http://www.cio.com/archive/ 060196_uneasv_l.html (28. 6. 2005). Katja Harej je doktorska študentka in raziskovalka na področju vodenja projektov informacijskih sistemov na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Njena raziskovalno-razvojna dela zajemajo predvsem delovanje spletnih skupnosti, interakcijo med procesi dela in sistemi vodenja v organizaciji ter načrtovanje in razvoj informacijskih sistemov. Tatjana VVelzer Družovec je redna profesorica na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Pod njenim okriljem deluje laboratorij za podatkovne tehnologije. Njeno raziskovalno-razvojno področje pokriva predvsem konceptualno oblikovanje podatkovnih baz, kakovost podatkov in podatkovno modeliranje. Romana Vajde Horvat je docentka na Inštitutu za informatiko na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Deluje na raziskovalno-razvojnem področju, ki med drugim pokriva vodenje projektov razvoja informacijskih sistemov, standardizacijo, metode komuniciranja in izboljšanje procesa razvoja programske opreme. RAZPRAVE B Uporaba metrik pri identifikaciji smiselnih preoblikovanj programske kode Marko Tekavc, Marjan Maričko Univerza v Mariboru, Fakulteta za elektrotehniko računalništvo in informatiko, Inštitut za informatiko (marko.tekavc, marjan.hericko)@uni-mb.si Izvleček Preoblikovanje programske kode je proces spreminjanja programske kode na način, da se obnašanje sistema navzven ne spremeni, spremeni in izboljša pa se notranja struktura programskega sistema. Natančno definirani, preizkušeni in delno z orodji podprti pristopi k preoblikovanju se osredotočajo predvsem na odpravljanje slabo oblikovane kode, ne pa tudi na to, kako identificirati takšno kodo v sistemu. Korak identifikacije slabo oblikovane kode in izbire ustreznega preoblikovanja je tako v veliki meri odvisen od izkušenj razvijalca. V prispevku je predstavljen in ovrednoten na metrikah temelječ pristop k identifikaciji slabo oblikovane objektno-orientirane programske kode in smiselnih preoblikovanj. Abstract Metric-Based Softuvare Refactoring Refactoring is a process that changes softvvare code in order to improve its structure vvhile keeping its behavior unchanged. Current approaches and tools related to refactoring are mainly focused on the code-restructuring step. The process of code identification is rarely addressed; therefore practitioners have to rely on their personal experiences and professional judgment. In this paper the method of identifying bad code in object-oriented systems is presented and evaluated. The proposed method is based on selected OD metrics. The method assists in the identification of code parts that reguire refactoring. It also provides recommendations for adeguate change. 1 Uvod Programski sistemi se zaradi prilagajanja spreminjajočemu se okolju, odpravljanja napak ali kakšnega drugega razloga med razvojem pa tudi v času uporabe velikokrat spreminjajo. Vsakršno spreminjanje sistema zahteva dobro razumevanje strukture sistema, velikokrat pa povzroči tudi vnos novih, neželenih napak. Zato je skozi celoten cikel razvoja programske opreme treba namenjati ustrezno pozornost skrbi za dobro strukturo programske kode. Prav preoblikovanja lahko pomagajo na poti do izboljšanja strukture in razumljivosti programske kode. Fouvler v [1] natančno opisuje postopke in primere aplikacije preoblikovanj. Uporabnost in pridobitve procesa preoblikovanja programske kode v okoljih, ki uporabljajo ekstremno programiranje, pa predstavlja tudi [2]. Aplikacija preoblikovanj je dokaj enostavna, saj je treba v večini primerov le slediti natančno podanim postopkom. Nekatera preoblikovanja so definirana tako, da jih je bilo mogoče tudi avtomatizirati in so danes podprta v številnih orodjih. Se vedno pa obstaja težava, ki je še posebej izrazita pri velikih sistemih, in sicer kako poiskati odgovore na vprašanje, kdaj in kje je smiselno določena preoblikovanja aplicirati. Vpra- šanje je posebej zanimivo zaradi trditve, da nobena skupina metrik ne more nadomestiti človeške intuicije in subjektivnih zaznavanj pri ugotavljanju, katera preoblikovanja aplicirati in zakaj [1]. Skladno s tem se današnje raziskave na področju avtomatizacije preoblikovanj v glavnem ukvarjajo z apliciranjem preoblikovanj, ne pa s problemom, kako v kodi identificirati mesta, kjer bi uporabili preoblikovanja. Naloga, kako locirati dele kode, primerne za preoblikovanje, nikakor ni lahka, prav tako pa je zahtevna tudi naloga samodejne identifikacije preoblikovanja, s katerim bi tako identificirano kodo na najustreznejši način izboljšali. Prav to pa sta izziva, ki jih naslavljamo v pričujočem prispevku. Cilj raziskave je ugotoviti, v kolikšni meri si lahko pomagamo z metrikami kot orodjem za identifikacijo tako slabo oblikovane kode kot tudi preoblikovanj, ki bi odpravila takšno kodo. V raziskavi, ki smo jo opravili, smo poskusili zajeti kar se da širok nabor najbolj znanih in uporabljanih metrik za objektno-orientirane sisteme ter ugotoviti, katere izmed njih in na kakšen način so primerne za identifikacijo slabo oblikovane kode. V razdelku poglavju so na kratko povzete bistvene značilnosti procesa preoblikovanja objektno orientiranih programskih sistemov. Sledi pregled sorodnih raziskav, kjer podrobneje predstavimo dva pristopa k samodejni identifikaciji slabo strukturirane kode in smiselnih preoblikovanj. V četrtem razdelku najprej predstavljamo izhodišča predlaganega pristopa, ki temelji na metrikah, razvrščenih v tri skupine. Prva skupina je namenjena identifikaciji možnih izboljšav strukture sistema, druga identifikaciji in preoblikovanju razredov, tretja skupina metrik, ki smo jo oblikovali, pa se osredotoča na metode znotraj posameznih razredov. Četrti razdelek predstavi rezultate praktične uporabe in ovrednotenja predlaganega pristopa na konkretnem primeru. 2 Izboljšanje strukture programske kode s preoblikovanjem Po definiciji je preoblikovanje proces spreminjanja programske kode tako, da se obnašanje sistema navzven ne spremeni, spremeni in izboljša pa se notranja struktura sistema [1]. Preoblikovanje programske kode se je uveljavilo kot pomembna praksa pri razvoju programske opreme predvsem v povezavi z objektno orientiranimi sistemi in vpeljavo agilnih pristopov, saj brez njene uporabe razvijalci le s težavo udejanjajo temeljne vrednote in principe agilnosti, kot sta npr. odzivnost in preprostost. Načelo preprostosti namreč pomeni, da razvijemo minimalni sistem, ki še zadovoljuje zahteve uporabnikov. Če pred dodajanjem nove funkcionalnosti obstoječe kode ne bi izboljšali, torej preoblikovali in pripravili za dodajanje nove funkcionalnosti, bi sistem po nekaj iteracijah zaradi slabe strukturiranosti postal neobvladljiv in nezmožen nadaljnjega razvoja. Ko govorimo o preoblikovanju in o identifikaciji delov kode, kjer je treba aplicirati določeno preoblikovanje, ne moremo mimo pojma slabo oblikovane kode. Slabo oblikovana koda je definirana kot del kode, ki sicer služi svojemu namenu, torej izvršuje neko zaporedje ukazov, ki skupaj pravilno izvedejo neko funkcionalnost, vendar pa bi lahko bil ta del kode napisan bolje, razumljiveje, morda v drugem razredu, komponenti ali metodi. Tabela 1 povzema po [1] najpomembnejše tipe slabo oblikovane kode, kratek opis in vrste preoblikovanja, ki jih je smiselno uporabiti za odpravljanje tega tipa slabo oblikovane kode. Vsakega izmed identificiranih tipov slabo oblikovane kode lahko torej odpravimo z uporabo enega ali več različnih vrst preoblikovanja. Zaradi boljše razumljivosti so imena posameznih vrst preoblikovanj v tabeli pa tudi v nadaljnjem besedilu navedena z izvornim angleškim izrazom. Žal pa tudi podrobni seznam vseh identificiranih tipov slabo oblikovane kode ne more zagotoviti enoumnega kriterija, s pomočjo katerega bi ugotovili, kdaj je preoblikovanje nujno, temveč je treba primere slabo oblikovane kode vzeti kot smernice, kje in kako izboljšati kodo s pomočjo preoblikovanj. Seveda se odločitev glede tega, katero preoblikovanje uporabiti za odpravo določenega tipa slabo oblikovane kode, od primera do primera razlikuje. Včasih lahko slabo oblikovano kodo odpravimo že z enim samim preprostim preoblikovanjem, velikokrat pa je treba aplicirati več preoblikovanj zapored. 3 Sorodne raziskave Čeprav se lahko strinjamo s trditvijo, da pri identifikaciji slabo oblikovane kode ne moremo nadomestiti človeških izkušenj in intuicije, obstaja nekaj raziskav, ki dokazujejo, da lahko ustrezni pristopi in metode vsaj pomagajo pri zadani nalogi. Predstavili bomo rezultate dveh raziskav s tega področja, podrobnejši opis je na voljo v [3] in [5]. 3.1 Preoblikovanje na podlagi metrike razdalje Raziskava Metrics Based Refactoring [3] je pokazala, da lahko s pomočjo posebnih metrik podpremo subjektivne ocene o slabo oblikovani kodi in identificiramo, kje aplicirati katero preoblikovanje. Na podlagi metrik izdelamo vizualno sliko sistema, iz katere ugotovimo, kje so mesta v programu, ki bi jih bilo treba preoblikovati. Raziskava se omeji zgolj na štiri tipe preoblikovanja in sicer Move method, Move Field, Extract Class in In-line Class ter temelji na dejstvu, da je veliko preoblikovanj osnovanih na principu “Dajmo skupaj, kar sodi skupaj". Tako avtorji definirajo, da je podobnost med dvema elementoma v zvezi z zbirko njunih skupnih lastnosti. disttt(x,y) := l - pri čemer sta x in y opazovana elementa, p(x):= {lastnosti pi e B \ x ima v lasti pj Formula 1: Razdalja med opazovanima elementoma |p(-r)o/>(.y)| \p(x)D p(y)j Na podlagi formule 1 vpeljemo pojem razdalje oz. oddaljenosti, s katero opišemo mero vezljivosti. Velja, da je vezljivost delov z nizkimi razdaljami boljša kot vezljivost delov z velikimi razdaljami. Razdalje računamo za atribute in metode razreda, pri čemer izhajamo iz pred- postavke, da dva elementa sodita skupaj, če uporabljata drug drugega. Identifikacija možnega preoblikovanja je omejena na prej omenjena štiri preoblikovanja in poteka na osnovi identifikacije velikih razdalj med člani razreda ter majhnih razdalj do članov drugega razreda. Tabela 1: Tipi slabo oblikovane kode Slabo oblikovana koda Opis Smiselna preoblikovanja Komentarji Assertion V komentarjih opisujemo, kaj dela programska koda. Extract Method, Rename Method, Introduce Predolga metoda Metoda je tako obsežna, da težko ugotovimo, kakšna je njena funkcionalnost. Extract Method, Replace Temp with Query, Introduce Parameter Dbject, Preserve VVhole Dbject, Replace Method with Method Dbject Predolg nabor parametrov V metodo pošiljamo vse podatke prek parametrov, čeprav bi lahko metoda sama prišla do potrebnih podatkov. Replace Parameter with Method, Preserve VVhole Dbject, Replace Method with Method Dbject Podvojena koda Imamo enako kodo na več različnih mestih v sistemu, kar otežuje spreminjanje programa. Extract Method, Puli Up Field, Form Template Method, Substitute Algorithm Prevelik razred Razred, ki opravlja preveč funkcionalnosti. Extract Class, Extract Subdass Tip vgrajen v ime V imenih metod imamo podatke, ki so vidni že iz samega podpisa metode. Rename Method Nekonsistentna imena Za isti pojem uporabljamo različna imena. Rename Method Špekulativna splošnost Pretiravamo z generalizacijo kode, z namenom predvidevanja prihodnjih potreb. Collapse Hienarchy, Inline Class, Remove Parameter, Rename Method Obsedenost s primitivnimi tipi Za sestavljene podatke uporabljamo primitivne tipe, namesto da bi uporabili preproste objekte. Replace Data Value with Dbject, Replace Type Gode with Class/Subclass State/Strategy, Extract Class, Introduce Parameter Dbject, Replace Array VVith Dbject Podatkovni razred Razred je brez funkcionalnosti - sestavljen samo z atributi in metodami get in set. Move Method Skupine podatkov Skupine podatkov, ki jih vedno najdemo skupaj. Extract class, Introduce Parameter Dbject, Preserve VVhole Dbject Zavrnjena zapuščina Podrazredi ne potrebujejo vsega kar podedujejo. Replace Inheritance VVith Delegation. Neprimerna intimnost Dva razreda sta preveč prepletena. Change Bidirectional Association to Unidirectional, Extract Class, Flide Delegate Len razred Razred, ki ne opravlja dovolj funkcionalnosti. Collapse Hierarchy, Inline Class Zavidanje lastnosti Metodo bolj zanimajo lastnosti nekega drugega razreda kot tistega, v katerem se dejansko nahaja. Extract method, Move Method Verige sporočil Odjemalec mora uporabiti en razred, da pride do drugega in potem tega, da pride do tretjega itd. Flide Delegate Osrednja osebnost Razred večino stvari delegira k drugemu razredu. Inline Method, Replace Delegation VVith Inheritance Raznolike spremembe Razred se pogosto iz različnih razlogov spreminja na različne načine. Extract Class Poseg s šibrovko Nasprotno od raznolikih sprememb. Sprememba povzroči veliko majhnih sprememb v različnih razredih. Inline Class Vzporedne hierarhije dedovanj Posebna oblika posega s šibrovko. Vedno ko naredimo podrazred razreda, moramo narediti tudi podrazred nekega drugega razreda. Move Method, Move Field Po aplikaciji koncepta merjenja razdalje na osnovi vezljivosti in po izračunu vseh razdalj med metodami in atributi izdelamo metriko razdalj med opazovanimi elementi, s pomočjo katere izvedemo vizualizacijo. Vizualizacija je mogoča s pomočjo programa "3D-Spring Embedder"[4], s katerim izdelamo 3D modele v jeziku VRML. Ključnega pomena za orodje, ki omogoča vizualizacijo, je hitrost in povezanost z razvojnim okoljem. Za uporabo in izračun vrednosti metrike z razdaljami, ki je potrebna za vizualizacijo, je treba izdelati repozitorij relevantnih konceptov, kot so razredi, metode, povezave ipd. Nato izberemo konstrukte, ki jih bomo analizirali, in izračunamo razdalje. Na osnovi izračunanih pozicij in informacij iz repozitorija izdelamo model VRML. Ena izmed slabosti opisane rešitve podpornega orodja je prav trajanje izgradnje repozitorija uporabljenih konceptov iz projekta, ki se sicer izvaja samo enkrat, vendar pa se mora ob spremembah v programski kodi posodobiti. Dodatno težavo predstavlja interpretacija vizualizacije in razpoznavanje slabo oblikovane kode. S kompleksnostjo sistema namreč narašča tudi kompleksnost vizualizacije, kar otežuje identifikacijo delov s slabo oblikovano kodo. Poleg tega obstajata pri uporabi te metode za velike sisteme še dve težavi: . Veliko razredov ne moremo obravnavati ločeno, saj so vpeti v strukturo dedovanja. Če raziskujemo določen razred brez upoštevanja konteksta dedovanja, lahko pridemo do napačnih sklepov oziroma predlogov za preoblikovanje. ■ Ker lahko v velikem sistemu obstaja več tisoč razredov in je lahko podrobna analiza časovno zelo potratna, se pojavlja problem, kako v tako velikem sistemu v predstavljeni vizualizaciji opaziti tiste razrede, ki jih je treba preoblikovati. Čeprav so nekateri izmed omenjenih problemov delno rešeni, je metoda za velike sisteme le pogojno uporabna, poleg tega pa uporabljena metrika ni podprta v obstoječih razvojnih okoljih in orodjih. 3.2 Preoblikovanje na podlagi zgodovine sprememb V članku Improving Evolvabiliti/ through Refactoring [5] je opisana metoda, ki uporablja zgodovinske podatke, pridobljene iz repozitorijev, kot je CVS. Metoda se osredotoča na sklope sprememb - če se nekateri deli skozi več izdaj zelo pogosto spreminjajo, potem lahko takšni podatki služijo kot pokazatelji potencialnih mest za aplikacijo preoblikovanj. Poleg koncepta slabo oblikovane kode vpeljemo še koncept sumljivih sprememb. Takšne spremembe težko opazimo v kodi, lahko pa jih identificiramo na podlagi pregleda zgodovine sprememb. Pristop omogoča zaznavanje sumljivih sprememb in s tem spodbuja razvijalce k preoblikovanju takšnih delov izvorne kode. Definicija sklopljenosti sprememb pravi, da sta elementa logično sklopljena, če spremembe skozi dovolj veliko število izdaj vplivajo na oba elementa. Predstavljena sta dva tipa sumljivih sprememb: 2. Osrednja osebnost (»Man in the middle«) - osrednji razred se razvija skupaj s številnimi ostalimi razredi, ki so razpršeni po različnih modulih v sistemu. Takšen razred zavira razvoj samostojnih modulov zaradi močne povezanosti z drugimi deli sistema. 2. Vsebnik podatkov (»Data Container«) - obstajata dva razreda, kjer prvi vsebuje vse potrebne podatke, drugi pa sodeluje z ostalimi razredi in zagotavlja funkcionalnost, ki uporablja predvsem podatke prvega razreda. S tem krši princip ograjevanja podatkov in povezanih funkcionalnosti. Predlagana metoda je podprta tudi z orodjem, izdelanim v ta namen - EvoLens [6]. Orodje razčleni dnevniške datoteke iz repozitorija CVS in izračuna spremembo sklopljenosti med razredi. Sklopljenost se nato skupaj s strukturnimi informacijami vizualizira. Pristop je bil preizkušen na zgodovini sprememb velikega industrijskega projekta skozi obdobje petnajstih mesecev. V tem času so bila, s pomočjo analize zgodovinskih podatkov predlagana mesta za preoblikovanje. Po aplikaciji preoblikovanj in nadaljnjih petnajstih mesecih opazovanj so ocenili učinkovitost pristopa, ki je podprla hipotezo, da je kombinacija analize odvisnosti sprememb in preoblikovanja uporabna in učinkovita [5]. Zal je predstavljeni pristop uporaben zgolj v povezavi s spremljanjem in zbiranjem zgodovinskih podatkov, v praksi pa bi želeli programsko kodo izboljšati tudi v primeru, ko tovrstnih podatkov še ni, zato smo definirali pristop, ki temelji zgolj na aktualnem sistemu ter temelji na uveljavljenih metrikah objektno orientirane kode, hkrati pa lahko metrične vrednosti enostavno pridobimo in zberemo v času razvoja s pripomočki in metričnimi orodji, ki so po navadi že vključena v sodobna razvojna okolja. 4 Uporaba uveljavljenih objektno orientiranih metrik pri preoblikovanju Pristop, ki ga predlagamo, temelji na predpostavki, da bi bilo mogoče s pomočjo uveljavljenih objektno orientiranih metrik identificirati slabo oblikovane dele kode in predlagati preoblikovanja, s katerimi bi takšno kodo izboljšali. Na osnovi analize najbolj uveljavljenih in razširjenih metrik za objektne sisteme smo oblikovali nabor primernih metrik in jih razdelili v tri skupine glede na to, kakšen tip slabo oblikovane kode lahko z njimi identificiramo: 1. Slaba struktura - V to skupino smo uvrstili predvsem metrike MOOD, ki jih je predlagal Abreau [7, 8]. Z njimi lahko ugotovimo, ali program upošteva pravila in navodila dobrega objektnega načrtovanja ter implementacije. 2. Slabo oblikovani razredi - V to skupino smo uvrstili metrike, ki izpostavijo slabo oblikovane razrede. Tako identificiramo razrede, ki so pretesno povezani z drugimi razredi, razrede, ki imajo nizko vez-ljivost, in razrede, ki so preveliki ali imajo preveliko število operacij in atributov. 3. Prezapletene metode - V tretji skupini najdemo metrike, ki se ukvarjajo z metodami. Prezapletene metode lahko identificiramo po dolžini, preveliki ciklomatični kompleksnosti, prezapletenih vejit-vah ali prevelikem številu operacij, lokalnih spremenljivk ali parametrov. Tabela 2: Povezanost metrik, slabo oblikovane kode in preoblikovanj Metrika Slabost Možni tip slabo oblikovane kode Preoblikovanje Slaba struktura Faktor sklopljenosti (CF) Prevelika sklopljenost Neprimerna intimnost, Move Method, Move Field, Change Bidirectional osrednja osebnost, Association to Unidirectional, zavidanje lastnosti Replace Delegation With Inheritance Faktor polimorfičnosti IPF) Neuporaba Podvojena koda Replace Type Gode with Subclasses, polimorfizma Replace Type Gode vvith State/Strategy, Replace Conditional vvith Polymorphism Skrivanje metod/atributov (AHF/MHF) Kršitev ograjevanja Encapsulate Field, Self Encapsulate Field, Hide Method Dedovanje atributou/metod IAIF/MIF) Neuporaba dedovanja Podvojena koda, Replace Delegation With Inheritance, osrednja osebnost Extract Subclass, Replace Type Gode vvith Subclass/State/Strategy Slabo oblikovani razredi Sklopljenost med objekti ICBO) Prevelika sklopljenost Neprimerna intimnost, Change Bidirectional Association to Unidirectional, verige sporočil Extract Class, Flide Delegate Sklopljenost klicev metod (MICI Prevelika sklopljenost Neprimerna intimnost, Extract Class, Hide Delegate, Move Method verige sporočil Pomanjkanja vezljivosti Pomanjkanje vezljivosti Replace inheritance vvith delegation, med metodami (LCDM1 Move Field, Move Method Število atributov/operacij/članov Prevelik razred Prevelik razred Extract Class, Extract Subclass razreda (N0A/N00/N0M) Število dodanih metod (NOAM) Neustrezna uporaba Extract subclass, Replace inheritance vvith delegation dedovanja Utežene metode razreda (IIVMPC) Prekompleksen razred Prevelik razred, Extract Class, Extract Subclass, Podvojena koda Replace Type Gode vvith State/Strategy, Replace Conditional vvith Polymorphism Prezapletene metode Ciklomatična kompleksnost (CC) Prekompleksna metoda Predolga metoda, Extract method, Replace Type code vvith Podvojena koda Class/Subclasses/State/Strategy Število vrstic kode (L0C1 Predolga metoda Predolga metoda Extract Method Maksimalno število vejitev Prekompleksna metoda Extract method, Replace Type code v metodi (MN0B1 vvith Class/Subclasses/State/Strategy Število parametrov (NDP) Predolg nabor Predolg nabor Replace Parameter vvith Method, parametrov parametrov Preserve VVhole Object, Introduce Parameter Dbject Število lokalnih spremenljivk (IMDLUI Lokalne spremenljivke Replace Temp vvith Query, Inline Temp Tabela 2 za vsako izmed izbranih metrik prikazuje, katero slabost in tip slabo oblikovane kode lahko odkrijemo z njo ter katera so iz tega izhajajoča najpogosteje uporabljana preoblikovanja za izboljšanje takšne kode. Dejansko lahko z nekaterimi metrikami identificiramo nasprotne tipe slabo oblikovane kode ali pa metrika identificira tudi kakšen drugi tip slabo oblikovane kode, ki v tabeli ni naveden. Tudi zato tabela ne nudi popolnega pregleda, temveč le podaja najpogostejše povezave med metrikami, slabo oblikovano kodo in preoblikovanji. 4.1 Slaba struktura Metrike iz te skupine povedo, kako dobro je sistem strukturiran in kako so uporabljeni principi objektnega razvoja (dedovanje, ograjevanje, polimorfizem). Večina teh metrik vrne vrednost za celoten sistem in zato niso primerne za lociranje mest s slabo oblikovano kodo, pač pa kažejo, v kateri smeri bodo potekala preoblikovanja. Metrika faktor sklopljenosti (Coupling Factor - CF) prikaže odstotek sklopljenosti med razredi v sistemu. Cim večja je ta vrednost, tem bolj sklopljeni so razredi in je sistem težji za vzdrževanje. Visoka vrednost je pogosto znak za smiselnost premestitve metod in atributov (Move Method, Move Field) v ustreznejše razrede ali spremembo dvosmerne povezave v enosmerno (Change Bidirectional Association to Unidirectional). Seveda sta ti dve preoblikovanji zgolj najočitnejši možnosti, sklopljenost lahko namreč zmanjšamo tudi z drugimi preoblikovanji. Metrika faktor polimorfičnosti (Polymorphism Factor -PF) vrne stopnjo polimorfizma v opazovanem sistemu. Nizka vrednost praviloma pomeni, da je v sistemu premalo uporabljen eden izmed osnovnih principov objektnega razvoja - polimorfizem. Običajno v sistemu namesto polimorfizma nastopajo stavki svvitch/case, ki jih preoblikujemo s preoblikovanji Replace Type Code zvith Subclasses, Replace Type Code zvith State/Strategy in Replace Conditional zvith Polymorphism. Metriki skrivanje metod oziroma atributov (Attribute Fliding Factor - AFIF / Method Fliding Factor - MFIF) izpostavita kršitve ograjevanja. Problem razrešimo s spreminjanjem vidnosti in ograjevanjem atributov/ metod, za kar lahko uporabimo preoblikovanja Encap-sulate Field, Self Encapsulate Field in Hide Method. Metriki dedovanje atributov oziroma metod (Attribute Inheritance Factor - AIF / Method Inheritance Factor - MIF) vrneta delež vseh podedovanih atributov/metod v sistemu. Če je vrednost nizka, to navadno pomeni, da v sistemu ni vzpostavljena ustrezna hierarhija razredov, saj je premalo uporabljan eden temeljnih principov objektnega razvoja - dedovanje. 4.2 Slabo oblikouani razredi V tej skupini so metrike, s pomočjo katerih lahko ugotovimo, ali imamo v našem sistemu ustrezne razrede in povezave med njimi. Z metrikami iz te skupine praviloma identificiramo točno določen razred ali razrede, ki jih je treba preoblikovati, hkrati pa ugotovimo, za kakšen tip slabo oblikovane kode gre in s pomočjo katerih preoblikovanj lahko odpravimo takšno kodo. Metrika sklopljenost med objekti (Coupling Betzveen Objects - CBO) vrne število razredov, s katerimi je povezan opazovan razred. Prevelika sklopljenost med razredi je značilna za modularno strukturo in preprečuje ponovno uporabo ter otežuje vzdrževanje sistema. Večja sklopljenost zahteva tudi rigoroznejše testiranje. Metrika nakazuje neprimerno intimnost (Inap-propriate Intimacy) med razredi. Sklopljenost med razredi lahko zmanjšamo s preoblikovanji Change Bidirectional Association to Unidirectional, Extract Class in Ftide Delegate. Metrika sklopljenost klicev metod (Method Invocation Coupling - MIC) vrne relativno število razredov, h katerim opazovani razred pošilja sporočila: MICnom = nMIC/(N-l) pri čemer je nMIC število razredov, h katerim se pošiljajo sporočila, in N število vseh razredov v sistemu. Prevelika sklopljenost med razredi ima vpliv na: 1. vzdrževanje - vzdrževanje močno sklopljenih razredov je težavnejše zaradi odvisnosti od povezanih razredov; 2. razumljivost - težja razumljivost razreda, saj je za razumevanje po navadi treba razumeti tudi povezane razrede ali njihove dele; 3. nagnjenost k napakam, težavno testiranje - napake v razredu so premo sorazmerne s številom povezav na druge razrede in posledično ima to negativen vpliv na testiranje. Visoka vrednost te metrike torej pomeni močno povezan razred in nakazuje neprimerno intimnost (Inappropriate 1ntimacy) med razredi. Spet si lahko pomagamo s preoblikovanji, kot so Extract Class, Hide Delegate in Move Method. Metrika pomanjkanje vezljivosti med metodami (Lack of Cohesion OfMethods - LCOM) vrne odstotek metod, ki ne dostopajo do določenega atributa, glede na vse atribute v razredu. Visoka vrednost te metrike nakazuje pomanjkanje vezljivosti in pomeni, da je razred slabo zasnovan. Pomanjkanje vezljivosti povečuje kompleksnost. Pri identifikaciji slabo oblikovanih razredov si lahko pomagamo tudi s tremi sorodnimi metrikami, ki preštejejo atribute, metode oziroma člane razreda. Na podlagi metrik števila atributov, operacij oziroma članov razreda (Number of Attributes - NOA, Number of Opera-tions - NOO, Number of Members - NOM) lahko identificiramo (pre)kompleksen, prevelik razred, ki je eden najpogostejših tipov slabo oblikovane kode [11. Rešitev je v razdelitvi razreda na ustreznejše razrede/ podrazrede s preoblikovanjem Extract Class/Extract Subclass. Metrika število dodanih metod (Number ofAdded Methods - NOAM) prešteje število (dodatnih) operacij (pod)-razreda; podedovane in predefinirane (overidden) metode ne upošteva. Metrika ne zadeva razredov brez staršev. Prevelika vrednost te metrike pomeni, da se funkcionalnost izbranega podrazreda preveč razlikuje od starša. S pomočjo preoblikovanja Extrad subclass lahko ustvarimo dodatni podrazred ali hierarhijo nadomestimo z delegiranjem (Replace inheritance ivith delegation). Metrika utežene metode razreda (VVeighted Methods Per Class - WMPC) je zadnja metrika, ki smo jo uvrstili v skupino metrik, primernih za identifikacijo slabo oblikovanih razredov. Prva oblika te metrike meri kompleksnost razreda na podlagi ciklomatične kompleksnosti metod v razredu, druga pa temelji na predpostavki, da več metod in večje število parametrov metod navadno pomeni tudi večjo kompleksnost. 4.3 Prezapletene metode Uporaba metrik iz te skupine izpostavi slabo oblikovane metode. Praviloma lahko s pomočjo teh metrik identificiramo tudi tip slabo oblikovane kode v metodi in s tem preoblikovanja, ki odpravijo takšno kodo. Metrika ciklomatične kompleksnosti (Cyclomatic Cont-plexity - CC) pomaga pri identifikaciji kompleksnih metod, saj predstavi število ciklov v merjeni metodi. Dejansko prešteje število možnih poti skozi algoritem s pomočjo štetja stavkov if, for in ivhile. Po definiciji dobimo vrednost metrike z enačbo: CC = L - N +2P pri čemer je L število povezav v grafu kontrolnega toka, N je število vozlišč in P število nepovezanih delov. Cim višja je izmerjena vrednost metrike, tem kompleksnejša je merjena metoda. Metrika števila vrstic kode (Lines ofCode - LOC) šteje vrstice v metodi/razredu/paketu/aplikaciji, vključno s komentarji in praznimi vrsticami. Preveliko število vrstic kode običajno pomeni (pre)kompleksno, predolgo metodo. Tip slabo oblikovane kode, ki ga identificiramo, je torej predolga metoda, odpravimo pa ga s preoblikovanjem Extract Method. Metrika maksimalno število vejitev v metodi (Maximum Number of Branches - MNOB) je definirana kot maksimalno možno število if-else in/ali čase vejitev v metodi. Visoka vrednost praviloma pomeni kompleksno metodo. Preoblikovanja, s katerimi lahko odpravimo kompleksne pogojne strukture, so Extract method, Replace Type code ivith Class/Subclasses/State/Strategy. Metrika število parametrov (Number of Parameters -NOP) vrne število parametrov v opazovani metodi. Preveliko število parametrov je dobro poznana slabo oblikovana koda, imenovana predolg nabor parametrov (Long Parameter List), ki jo lahko odpravimo z enim preoblikovanjem ali kombinacijo preoblikovanj: Replace Parameter ivith Method, Preservc Whole Object in Introduce Parameter Object. Metrika število lokalnih spremenljivk (Number of Local Variables - NOLV) je pomembna zato, ker lokalne spremenljivke otežujejo ali onemogočajo določena preoblikovanja metod. Preoblikovanji, ki ju lahko uporabimo za odpravo lokalnih spremenljivk, sta Replace Temp ivith Query in Inline Temp. 5 Ovrednotenje pristopa na primeru Vrednotenje ustreznosti predstavljenih skupin metrik, ki lahko služijo kot smernice pri izvajanju preoblikovanj, smo izvedli na enostavnem sistemu za vodenje izposoje gradiva v knjižnici. Programska koda je napisana praktično brez upoštevanja konceptov objektne orientacije, z eno relativno dolgo in kompleksno metodo, in je kot takšna zelo primerena za preoblikovanje. Originalna programska koda je na voljo na naslovu http://cot.uni-mb.si/Refactoring/koda.zip. Slika 1 prikazuje razredni diagram tega programa. Analiza programske kode je bila izvedena z orodjem, ki nudi podporo izvajanju metrik na programski kodi in avtomatizacijo nekaterih enostavnejših pre- oblikovanj. Tabela 3 prikazuje najzanimivejše rezultate metrik, s pomočjo katerih lahko ocenimo strukturo našega programa. Faktorja dedovanja metod (MIF) in polimorfizma (PF) sta enaka 0, kar pomeni, da ta dva koncepta v našem primeru nista navzoča. Prav tako je slab tudi faktor sklopljenosti (CF), saj nakazuje precej veliko sklopljenost med našimi razredi. Sprejemljiva pa je stopnja prikritosti atributov (AHF), to pomeni, da je večinoma upoštevan koncept ograjevanja. Qc lzposoja(gradivo: Gradivo, dnilzposoje: int) a dnilzposoje: int £ Clan(naziv: String) • novalzposoja(izposoja: Izposoja) O ustvariPorocilo(): String o naziv String n izposoje: Vector V KNJIGA: int V ZBORNIK: int V REVIJA: int d naslov: String £ Oradivo() £ Gradivo(naslov: String, tipGradiva: int) O getNaslovGradiva(): String O setTipGradiva(tipGradiva. int) O getTipGradiva(): int Slika 1: Razredni diagram kode (pred preoblikovanjem) Tabela 3: Rezultati metrik strukture kode pred preoblikovanjem ka VVMPC1, ki v primerjavi z drugimi razredi kaže na Struktura veliko cikiomaticno kompleksnost metod razreda Član. Z analizo metrični rezultatov tega sklopa metrik lahko ugotovimo, da bo treba pri preoblikovanju največ pozornosti posvetiti razredu Član. Izvesti želimo takšna preoblikovanja, da zmanjšamo močno povezanost razreda z drugimi razredi ter poenostavimo kompleksne metode v razredu. Tabela 5: Rezultati metrik nad metodami pred preoblikovanjem Metode AHF CF MIF PF Knjižnica 67 67 0 0 Z analizo tega sklopa metrik smo postavili tezo, da je programska koda precej slabo strukturirana in skorajda ne upošteva dobrih praks uporabe konceptov objektne orientacije. Predvideli smo, da lahko z uporabo ustreznih preoblikovanj strukturo našega programa izboljšamo. Pri analizi rezultatov metrik nad razredi lahko vi- cc L0C MNDB N0LV N0P dimo (tabela 4), da dobimo najslabše rezultate v razredu Član. Velika sklopljenost razreda Član (metrika CBO) nakazuje modularno strukturo razreda. Visoke vrednosti metrik za pomanjkanje vezljivosti (LCOM2 in LCOM3) kažeta na slabo zasnovo prav vseh razredov. V razredu Član pa izstopata še rezultata metrike MIC, ki kaže, da razred Član relativno pogosto pošilja sporočila drugim razredom, in metri- Knjižnica 2 [9] 44 [66] Knjižnica.Član 3 86 Knjižnica.Član.Član 1 1 0 0 1 Knjižnica. Član. getNaziv 1 1 0 0 0 Knjižnica. Član. novalzposoja 1 1 0 0 1 Knjižnica. Član. ustvariPorocilo 9 66 13 7 0 Knjižnica.Gradivo 1 26 Knjižnica. Gradivo. Gradivo 1 0 0 0 0 Knjižnica. Gradivo. Gradivo 1 2 0 0 2 Tabela 4: Metrične vrednosti za razrede pred preoblikovanjem Knjižnica.Gradivo.getNaslovGradiva 1 1 0 0 0 Razredi Knjižnica. Gradivo. getTipGradiva 1 1 0 0 0 CBO ICDM2 IC0M3 MIC NBA NOM NOB VUMPC1 IA/MPC2 Knjižnica. Gradivo. setTipGradiva 1 1 0 D 1 Knjižnica 1 56 83 33 2 5 3 7 3 Knjižnica.Izposoja 1 19 Knjižnica. Član 3 50 75 100 2 5 3 12 4 Knjižnica. Izposoja. Izposoja 1 2 0 0 2 Knjižnica.Gradivo 0 84 75 02535 4 Knjižnica. Izposoja. getDnilzposoje 1 1 0 0 0 Knjižnica.Izposoja 1 33 100 0 2 4 2 3 2 Knjižnica. Izposoja. getGradivo 1 1 0 D 0 Tabela 5 prikazuje rezultate metrik nad metodami. V oglatem oklepaju so pri metrikah CC in LOC navedene tudi maksimalne izmerjene vrednosti. Že na prvi pogled je jasno, da je metoda ustvariPorocilo tista, ki je "krivec" za kompleksnost tega razreda. Predvsem izstopa ciklomatična kompleksnost metode in maksimalno možno število vejitev. 66 vrstic kode samo po sebi sicer ni veliko, vendar gre za zelo enostaven primer in vidimo lahko, da je to polovica kode našega primera. S pomočjo analize vrednosti metrik tega sklopa metrik lahko identificiramo metodo, pri kateri se lotimo preoblikovanja. Rezultati kažejo, da je treba zmanjšati kompleksnost in dolžino identificirane metode, zato jo z ustreznimi preoblikovanji razbijemo na manjše dele, pri čemer bomo skušali odpraviti tudi lokalne spremenljivke. Glede na vrednosti metrik, ki nakazujejo preveliko sklopljenost razreda, nato tako razbito metodo skušamo premakniti na ustreznejša mesta oz. drug razred in s tem zmanjšati sklopljenost in povečati ve-zljivost. Z nizom različnih preoblikovanj, ki izhajajo oz analize rezultatov metrične analize in predlaganih preoblikovanj, pridemo do strukture razredov, ki jo prikazuje slika 5. Programska koda je na voljo na: http://cot.uni-mb.si/Refactoring/PKoda.zip. Po končanem preoblikovanju programsko kodo ponovno ovrednotimo s pomočjo istih metrik. Metrične vrednosti prvega sklopa metrik, s katerim ocenjujemo strukturo programske kode, prikazuje tabela 6. Tabela 6: Rezultati metrik strukture kode po preoblikovanju Struktura AHF CF MIF PF Knjižnica 63 23 45 39 Iz rezultatov je razvidno, da smo s pomočjo preoblikovanj zmanjšali odstotek sklopljenosti med razredi v sistemu. Prav tako pa vrednosti metrik MIF in PF kažeta na uporabo dedovanja in polimorfizma. Tabela 7 kaže na izboljšanje vrednosti metrik v razredu Član. Vidimo lahko, da smo oblikovali tri dodatne razrede glede na strukturo, ki smo jo imeli pred pričetkom preoblikovanj. Ker smo funkcionalnost večinoma prenesli v razred Gradivo in njegove po-drazrede, so pričakovano rezultati metrik za ta razred slabši kot pred preoblikovanjem, vendar pa lahko -gledano rezultate metrik v celoti - ugotovimo, da smo izboljšali naše razrede. S preoblikovanji smo izboljšali prej zelo kompleksno metodo ustvariPorocilo, saj smo funkcionalnosti iz te metode prenesli v druge metode in v ustreznejše razrede. Izboljšali smo tudi povprečno število vrstic metod v projektu. V celoti rezultate metrik nad metodami po preoblikovanju prikazuje tabela 8. Qc Zbormk(naslov String) O getTipGradr/a() O vrn»Cenolzposoje(steviloDntlzposoje mt) 0 Zbornik Revija( naslov Strmg) O getTipGrad«va() ♦ vrmCenolzposoje(steviloDnrfzposoje int) G Revija «F Knjiga(naslov String) • getTipGradivaO O vrrwCenolzposoie(steviloDnilzposo)e int) ® vrniBonusTocke(steviloDnilzposote mt) £ lzposoia(gradivo: Gradivo, dnilzposoje: int) O izracunajZnesek() O vrniBonusTocke() a dnilzposoje: mt 0 Izposoja £ Clan(naziv: String) O novalzposoiafizposoja Izposoja) • ustvanPorocioO ■ vrniSkupnoStevioBonusTockO e vrniSkupenZnesekO a naziv: Strmg a izposoje Vector 0 Član novoGradivo(naslov String, tipGradiva: mt) O getNastovGradiva() C' getTipGradivaO V vrniCenolzposoje(steviloDnilzposoje mt) ♦ vrrnBonusTocke(steviloDnilzposo)e mt) V KNJIGA int I/ ZBORNIK mt REVUA mt o naslov String Slika 5 Razredni diagram aplikacije po preoblikovanju Tabela 7: Rezultati metrik razredov po preoblikovanju Razredi CBO ICDIUI2 IC0M3 MIC N DA NOM N00 WMPC1 WMPC2 Knjižnica 1 56 72 23 1 5 4 6 5 Knjižnica. Član 3 50 62 40 2 7 5 9 6 Knjižnica.Gradim 3 79 87 60 1 7 6 8 11 Knjižnica.Izposoja 1 40 66 20 2 6 4 5 4 Knjižnica.Knjiga D 20 0 3 3 6 5 Knjižnica.Revija 0 0 0 2 2 5 3 Knjižnica.Zbornik 0 0 0 2 2 4 3 6 Sklep V članku smo naslovili področje preoblikovanja objektne programske kode s poudarkom na raziskavi uporabnosti uveljavljenih OO metrik pri identifikaciji slabo oblikovane kode. Ugotovili smo, da obstaja le malo raziskav na temo uporabe metrik za identifikacijo slabo oblikovane kode. Povzeli smo značilnosti dveh pristopov, ki se tej tematiki najbolj približata, ju na kratko opisali ter predstavili njune cilje, prednosti in slabosti. Predstavili in ovrednotili smo tudi pristop, ki temelji na uporabi treh kategorij metrik glede na to, kakšen tip slabo oblikovane kode lahko identificiramo z njimi. V kategorijo metrik, ki pomagajo pri identifikaciji slabe strukture programske kode, smo uvrstili izbrane metrike iz skupine metrik MOOD, v drugo kategorijo metrike, s katerimi identificiramo slabo oblikovane razrede, v tretjo pa tiste, ki izpostavijo slabo oblikovane metode. Za predstavljene metrike smo podali, kakšno vrsto slabo oblikovane kode lahko odkrijemo z njimi, in kadar je bilo mogoče, predlagali preoblikovanja, s katerimi bi takšno kodo izboljšali. Predlagani pristop smo ovrednotili na primeru in tako spoznali prednosti ter slabosti. Metrike so se izkazale kot uporaben pripomoček pri preoblikovanju. Pokazali smo, da lahko z njimi ovrednotimo strukturo programa in lociramo nekatere slabo oblikovane dele kode. Nobenega dvoma ni, da že uporaba preprostih metrik daje koristne smernice za izboljšanje oz. preoblikovanje strukture programske kode. Zal pa se je izkazalo, da je potrebno nekaj izkušenj, da se odločimo, kako preoblikovati in izbrati najprimernejša preoblikovanja. V nadaljnjih raziskavah bi se bilo treba osredotočiti predvsem na možnost uporabe kombi- Tabela 8: Rezultati metrik nad metodami po preoblikovanju Metode cc toc IVI NOB MOLU NDP Knjižnica 2 [2] 34 [27] Knjiznica.Clan 2 66 Knjižnica.Član.Član 1 1 0 0 1 Knjižnica.Član.getNaziv 1 1 0 0 0 Knjižnica.Član.novalzposoja 1 1 0 0 1 Knjižnica. Član. ustvariPorocilo 2 27 0 5 0 Knjižnica.Član.vrniSkupenZnesek 2 6 0 3 0 Knjiznica.Clan.vmiSkupnoSteviloBonusTock 2 6 0 3 0 Knjižnica.Gradivo 1 40 Knjižnica.Gradivo.getNaslovGradiva 1 1 0 0 0 Knjižnica. Gradivo. getTipGradiva 1 0 0 0 0 Knjižnica.Gradivo.novoGradivo 1 6 4 0 2 Knjižnica.Gradivo.setNaslov 1 1 0 0 1 Knjižnica.Gradivo.vrniBonusTocke 3 8 3 1 1 Knjižnica.Gradivo.vrniCenoIzposoje 1 0 0 0 1 Knjiznica.lzposoja 1 27 Knjižnica.Izposoja.Izposoja 1 2 0 0 2 Knjižnica. Izposoja. getDnilzposoje 1 1 0 0 0 Knjižnica. Izposoja.getGradivo 1 1 0 0 0 Knjižnica.Izposoja.izracunajZnesek 1 1 0 0 0 Knjižnica. Izposoja.vrniBonusTocke 1 1 0 0 0 Knjižnica.Knjiga 2 29 Knjižnica.Knjiga.Knjiga 1 1 0 0 1 Knjižnica.Knjiga.getTipGradiva 1 1 0 0 0 Knjižnica.Knjiga.vrniBonusTocke 2 8 2 1 1 Knjižnica. Knjiga. vrniCenoIzposoje 2 6 1 1 1 Knjiznica.Revija 2 21 Knjižnica.Revija.Revija 1 1 0 0 1 Knjižnica.Revija.getTipGradiva 1 1 0 0 0 Knjižnica.Revija.vrniCenoIzposoje 3 9 3 1 1 Knjiznica.Zbornik 1 18 Knjižnica,Zbornik.Zbornik 1 1 0 0 1 Knjižnica.Zbornik.getTipGradiva 1 1 0 0 0 Knjižnica.Zbornik.vrniCenoIzposoje 2 6 1 1 1 nacij metrik, določiti mejne ter signalne vrednosti posameznih metrik, upoštevati tudi značilnosti projek- 7 Literatura [1] Fovvler, M. (1999). Refactoring: improving the design of code, Addison-Wesley, 1999. [2] Grajfoner, U., Repinc, R Refactoring - Preoblikovanje programske kode, Uporabna informatika, letnik Vlil, štev. 4, 2000, str. 231-236. [3] Simon, F., Steinbruckner, F., Levverentz, C. Metrics Based Refactoring, European Conf. Softvvare Maintenance and Reengineering, IEEE Computer Society Press, 2001, str. 30-38. [4] Simon, F., Steinbruckner, F., Levverentz, C. 3D-Spring Embedder for Complete Graphs, Technical Report 11/00, Computer Science Reports, Technical University Cottbus, 2000. ta, v sklopu katerega apliciramo predlagani pristop, ter preizkusiti uporabnost pristopa na večjem projektu. [5] Ratzinger, J., Fischer, M., Gali, H. Improving Evolvability througb Refactoring, Vienna University of Technology, 2004. [6] Ratzinger, J., Fischer, M., Gali, H. Evo/en s: Lens-view visualizations of evolution data, Technical Report, Vienna University of Technology, December 2004. [7] Abreu, F. B., Carapuga, R., Object-Oriented Softvvare Engineering: Measuring and Controlling the Development Process, Proceedings of the 4th International Conference on Softvvare Quality, ASQC, McLean, VA, USA, Oktober 1994. [8] Abreu, F. B., Goulao, M., Esteves, R. Tovvard the design quality evaluation of object-oriented softvvare systems, Proceedings of the 5th International Conference on Softvvare Quality, Austin, Texas, USA Oktober 1995, str. 44-57. Marko Tekavc je podiplomski študent na Inštitutu za informatiko Fakultete za elektrotehniko, računalništvo in informatiko Univerze v Mariboru, kjer je tudi zaposlen kot asistent za področje informatike. Sodeluje na različnih projektih, tako aplikativnih kot tudi znanstveno-raziskovalnih. Raziskovalna področja, s katerimi se ukvarja, pokrivajo objektno orientirane tehnologije, preoblikovanje programske kode, storitvene arhitekture (SOA), spletne storitve in kompozicije poslovnih procesov (BPEU. Marjan Heričko je izredni profesor na Inštitutu za informatiko na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Je vodja laboratorija za informacijske sisteme in strokovni koordinator slovenske tehnološke platforme za programsko opremo in storitve. Njegovo raziskovalno-razvojno delo obsega vse vidike razvoja sodobnih informacijskih rešitev s poudarkom na metodologijah razvoja, metrikah in razvojnih okoljih. Svoje izkušnje je predstavil v številnih prispevkih na domačih in tujih konferencah ter revijah. Je tehnični koordinator aktivnosti centra COT ter predsednik konferenc DTS in CIS. Diplomiral, magistriral in doktoriral je na Fakulteti za elektrotehniko, računalništvo in informatiko v Mariboru. RAZPRAVE B Upravljanje neprekinjenega poslovanja v slovenskih organizacijah Borut Žnidar1, Aleš Groznik2 1 Avtenta.si, sistemska integracija in poslovne rešitve, d. o. o., Ljubljana; bomt.znidar@avtenta.si 2 Univerza v Ljubljani, Univerza v Ljubljani, Ekonomska fakulteta v Ljubljani, ales.groznik@ef.uni-lj.si Povzetek Prispevek obravnava upravljanje neprekinjenega poslovanja v slovenskih organizacijah. Neprekinjeno poslovanje je v sodobnem času izziv, s katerim se soočajo organizacije. Vsaka organizacija se mora zavedati posledic nepričakovanih prekinitev poslovanja, z njimi povezanih tveganj in stroškov. Potreba po hitrem okrevanju in vzpostavitvi poslovanja v prvotno stanje zahteva vnaprejšnje planiranje in pripravo. Pri tem potrebujemo izdelan načrt neprekinjenega poslovanja. S pomočjo načrta neprekinjenega poslovanja organizacija ostaja pripravljena na nepričakovane dogodke in njihove negativne posledice. S stanjem uvajanja neprekinjenega poslovanja v Sloveniji ne moremo biti zadovoljni. Rezultati ankete kažejo, da neprekinjeno poslovanje upravljajo v finančni dejavnosti, medtem ko je stanje neprekinjenega poslovanja v javni upravi in zdravstvu slabo. Abstract Business Continuity Management in Slovene Organisations The paper introduces the status of business continuity management in Slovene organisations. In today's volatile business environment one of the key guestions is how to maintain business continuity. Organisations have to be aware of sudden business interruptions accompanied with business risks and costs. The need for fast recovery calls for business planning in terms of business continuity management. Business continuity management with business recovery plan ensures organisation readiness in terms negative im-pacts of business interruptions. The study shovvs that business continuity management in Slovene organisations has been introduced in financial sector vvhereas puhlic sector, especially health institutions, experiences a severe lack of business continuity management. 1 Uvod Neprekinjeno poslovanje (NP) predstavljajo vse aktivnosti, ki omogočajo neprekinjeno poslovanje organizacije v primeru kriznih situacij. Obsega proaktivne in reaktivne načrte za izogibanje kriznim situacij in katastrofam ter omogoča hitro obnovo poslovanja, če pride do njih. Ekonomist Peter F. Drucker (Drucker, 1972), je kot glavno nalogo organizacije postavil preživetje in kot vodilni princip poslovne ekonomije izogibanje izgubi in ne povečevanje dobička. Pri uresničevanju naloge preživetja vidimo izogibanje izgubi na dveh področjih: v okviru običajnega poslovanja kot menedžment kontrole izgube in v primeru katastrofe kot krizni menedžment. Članek obravnava upravljanje neprekinjenega poslovanja kot mehanizem poslovanja v primeru katastrofe, incidenta, izpada dela poslovanja. Razlogov za izpad poslovanja je veliko in so lahko posledica naravnih sil, človeške napake, sabotaže ali tehnične napake. Marsikateri od njih lahko povzroči katastrofalne posledice za poslovanje organizacije. Rezultat so lahko poškodovano premoženje, prekinjen poslovni proces, izguba prihodka, ogrožen konku- renčni položaj. Vse te posledice neposredno ali posredno vplivajo na poslovanje organizacije. VVallace (VVallace, 2004) meni, da lahko katastrofa pomeni vse od izpada ključnega strežnika do naravne nesreče, ki uniči celotno poslovno enoto. Vse kar lahko povzroči prekinitev normalnega poslovanja lahko postane tudi katastrofa, zato večina organizacij brez skrbnega načrtovanja neprekinjenega poslovanja ne more preživeti večje prekinitve poslovanja. Zato je pomembno, da je organizacija sposobna tudi v primeru hudih prekinitev poslovanja čim prej vzpostaviti nadzor nad dogajanjem in pričeti z obnovo poslovanja ter vzpostavitvijo delovanja kritičnih funkcij v najkrajšem času. V času izpada je čas največji sovražnik, saj lahko izgubljeni čas prevedemo v nezadovoljne stranke, izgubljen prihodek, kazni itn. Tradicionalno so se organizacije pri pripravi obnove poslovanja v primeru katastrofe osredotočale na informacijsko infrastrukturo. Kritične funkcije organizacije so navadno zelo povezane z delovanjem informacijske tehnologije in je zato njeno hitro okrevanje zelo pomembno, vseeno pa imajo lahko malo vrednosti, če ne poskrbimo za širše okrevanje ključnih poslovnih procesov. Fulmer (Fulmer, 2005) priporoča, naj priprava načrta neprekinjenega poslovanja vsebuje naslednje ključne korake: ■ določitev vseh računalniških sistemov, aplikacij, ljudi, opreme in zalog, potrebnih za okrevanje; ■ priprava rezervnega postopka za kritične datoteke in sisteme ter varen podatkovni podsistem na oddaljeni lokaciji; • določitev ene ali več rezervnih lokacij, kjer se lahko izvajajo obdelava podatkov in poslovne operacije; e priprava učinkovite kontrole nad izvajanjem obnove; . določitev zunanjih sredstev in partnerjev, ki lahko pomagajo v procesu okrevanja; . testiranje načrta, ki pokaže zmožnost zagotovitve zahtevanega nivoja storitve za ključne poslovne procese in obnovo poslovanja; e vzdrževanje načrta upravljanja neprekinjenega poslovanja. Glede na prepletenost poslovanja in informacijske tehnologije v organizacijah se večina postopkov neprekinjenega poslovanja začne v oddelku informatike, ki zagotavlja obnovo informacijskega sistema v primeru izpada. V nadaljevanju se aktivnosti prenesejo na poslovne procese in zagotavljanje njihovega neprekinjenega poslovanja. Vpeljava neprekinjenega poslovanja se po navadi začne kot projekt vpeljave, ki nato preide v program upravljanja neprekinjenega poslovanja. Glede na obseg (informatika ali poslovni procesi), vključenost poslovnega dela organizacije ipd. je mogoče opredeliti, kje so posamezne organizacije na poti uvajanja neprekinjenega poslovanja. Namen tega članka je prikaz stanja upravljanja neprekinjenega poslovanja v slovenskih organizacijah. 2 Anketa o stanju neprekinjenega poslovanja v Sloveniji Čeprav je neprekinjeno poslovanje izrednega pomena za poslovanje organizacij, je stanje v Sloveniji slabo raziskano. Osnovni namen članka je podati izsledke raziskave neprekinjenega poslovanja v slovenskih organizacijah. V ta namen smo po vzoru tujih raziskav (Verton, 2000; Smith, 2002; Svvanskon in VVohl, 2002) oblikovali vprašalnik, ki so ga najprej testirali in verificirali neodvisni strokovnjaki s področja neprekinjenega poslovanja. Cilj ankete je bil ugotaviti stanje vpeljevanja neprekinjenega poslovanja, vpeljanih elementih neprekinjenega poslovanja ter posredno odvisnost med stopnjo vpeljave ter panogo, zahtevami regulative ipd.. Anketa je imela 13 vprašanj in je bila razdeljena na tri področja: profil organizacije in udeleženca, načrt neprekinjenega poslovanja organizacije in zaznane motnje poslovanja. Anketiranje je bilo izvedeno naključno, v sklopu dveh konferenc, ki sta aprila 2006 potekali v Sloveniji. Prvi dogodek je bil forum IBM, na katerem je sodelovalo več kot 600 udeležencev, drugi dogodek pa je bila konferenca o neprekinjenem poslovanju s 64 udeleženci, ki jo je organiziral in vodil Inštitut Iziv. Na obeh srečanjih smo med udeleženci izvedli anonimno anketo o upravljanju neprekinjenega poslovanja v slovenskih organizacijah. Vrnjenih in veljavnih je bilo 80 vprašalnikov; opravljena statistična analiza je potrdila, da je vzorec reprezentativen. 2.1 Udeleženci raziskave Udeleženci obeh konferenc in še posebej udeleženci v tej anketi sodijo med bolj zainteresirane ne tem področju, saj so v večini organizacij že vpeljali ali pa vpeljujejo program neprekinjenega poslovanja. Zato se zdi smiselna domneva, da udeleženci predstavljajo segment slovenskih organizacij, ki jim je blizu pojem neprekinjenega poslovanja. V anketi prevladujejo štiri dejavnosti (slika 1): finančna dejavnost, informacijsko tehnološke storitve, javna uprava in gospodarska dejavnost. Te štiri dejavnosti, predvsem 6,0 % 19,0% 14,0% 33,0 % I I management [33 ostalo I I vodstvo IT [31 svetovanje I I osebje IT U notranja revizija Slika 1: Panoge podjetij udeležencev prva, so tudi najdejavnejše na področju izvajanja neprekinjenega poslovanja v Sloveniji. 5,0 % 14,0 % I I finančna institucija I I gospodarska dejavnost storitve I I javna uprava [S trgovina I I zdravstvo ostalo Slika 2: Struktura položaja udeležencev Večino odgovorov na vprašalnik (70 %) smo dobili iz srednjih in velikih podjetij z več kot 100 zaposlenimi, skoraj polovica jih prihaja iz srednje velikih podjetij s 100 do 500 zaposlenimi. Rezultati ankete kažejo zanimivo strukturo položaja udeležencev (slika 2), saj kažejo ustrezno razporeditev ključnih udeležencev obravnavane teme, in sicer jih je po ena petina iz menedžmenta, četrtina iz vodstva informacijske tehnologije in tretjina izmed drugega osebja informacijske tehnologije. Taka struktura udeležencev obljublja relevantne rezultate ankete, saj ni manjkal noben ključni udeleženec upravljanja neprekinjenega poslovanja. 2.2 Stopnja vpeljave neprekinjenega poslovanja V večini primerov (skoraj 2/3) načrt neprekinjenega poslovanja še ni pripravljen oz. se pripravlja. Pri ostalih prevladujejo organizacije, ki so načrt pripravile, vendar ga še niso preizkusile. Le v 10 % primerov organizacije načrt redno preizkušajo in v prav toliko odstotkih načrt tudi redno obnavljajo. Če pogledamo, katere organizacije in do kakšne mere imajo vpeljan načrt neprekinjenega poslovanja se po pričakovanjih izkaže (slika 3), da so to večja podjetja. V skoraj 50 % podjetjih z več kot 500 zaposlenimi je načrt neprekinjenega poslovanja že vpeljan, medtem ko je v najmanjših podjetjih z do 20 zaposlenimi le 15 % takih podjetij. % 100 -i nad 500 100-500 do 20 20-100 št. zaposlenih v podjetju I I se redno obnavlja I I se redno preizkuša I I je narejen I I se pripravlja I I ni narejen Slika 3: Stopnja vpeljanosti neprekinjenega poslovanja glede na velikost podjetja Pri polovici vprašanih je glavni razlog za uvedbo načrta neprekinjenega poslovanja zahteva regulative. V dobri četrtini primerov je vzrok zahteva menedžmenta in le v dobrih desetih odstotkih izkušnja zaradi izpada poslovanja ali zahteva poslovnega partnerja. Precej slabo je stanje pri testiranju in rednem pregledu načrta neprekinjenega poslovanja. V obeh primerih ena tretjina sploh še ni izvedla testiranja oz. pregledala načrta, tretjina to opravlja le občasno. Preostale organizacije testiranje in pregled načrta izvajajo vsaj enkrat letno. Zanimiva je tudi primerjava vloge posameznih ključnih udeležencev (slika 4). Vidimo, da je vloga notranje revizije ob vpeljavi načrta neprekinjenega poslovanja pomembna, nato pa se njena vloga po mnenju udeležencev ankete manjša. Na drugi strani vidimo pomembno vlogo oddelka informacijske tehnologije, ki se ji pri vpeljanih načrtih neprekinjenega poslovanja približa vloga menedžmenta. Žal je v praksi uveljavljen pristop k uvajanju neprekinjenega poslovanja, ki ga avtorji v strokovni literaturi izrecno odsvetujejo, ko gre za težave pri vpeljevanju in upravljanju načrta neprekinjenega poslovanja, če vloga menedžmenta ni ključna v fazah vpeljave in upravljanja neprekinjenega poslovanja. I I vloga interne revizije | | vloga mgmt-a I I vloga IT Slika 4 Vloga ključnih udeležencev pri uvajanju neprekinjenega poslovanja % 30 25 20 -j'6 C01-" ^ <#N <(N- ^ 9v ^ I I 1 ostalo I I 2 zdravstvo I I 3 trgovina I I 4 javna uprava F~1 s gospodarska dejavnost I I 6 storitve | 7 finagnčna industrija 3 Rezultati ankete 3.1 Vpeljani elementi neprekinjenega poslovanja Pogled na vpeljane elemente neprekinjenega poslovanja (slika 5) glede na panogo kaže veliko izstopanje finančnih institucij, v katerih so vsi elementi precej enakomerno zastopani. Solidno je tudi stanje v storitveni dejavnosti, v kateri pa že vidimo slabšo zastopanost kompleksnejših elementov (analiza vpliva kriznega dogodka - BIA, krizni menedžment). Slabše stanje je v drugih obravnavanih panogah (gospodarstvo, javna uprava in trgovina), v katerih je do neke mere prisotna le vpeljava varnostnih politik. Izrazito slabo je stanje v zdravstvu, v katerem tako rekoč ni vpeljanih elementov neprekinjenega poslovanja. Kritični poslovni procesi zdravstva imajo tudi na ravni vse družbe posebno vlogo (npr. reševanje življenj), zato bi pričakoval podobno vlogo neprekinjenega poslovanja kot npr. v finančnih institucijah. Razlogov za tako stanje je več: morda informatika v zdravstvu ne igra zadosti pomembne vloge v ključnih procesih, morda so ključni procesi dovolj dobro pokriti z ročnimi/alternativnimi postopki, morda pa zakonodajalec ni opravil svoje vloge z uvedbo ustrezne re-gulative. Slika 5: Vpeljani elementi neprekinjenega poslovanja po panogah V ZDA npr. za zdravstvene organizacije, zaposlene v zdravstvu in zdravstvene zavarovalnice velja zakon HIPAA. Sestavljen je iz dveh delov in v drugem delu je pet pravil, ki preprečujejo prevaro in zlorabo v zdravstvu. Neprekinjeno poslovanje ureja varnostno pravilo, ki zahteva vzpostavitev načrta aktivnosti za nepredvidene situacije in obsega tudi pripravo varnostnih kopij podatkov in izdelavo procedur za obnovo v primeru katastrofe, kar vodi k uvajanju neprekinjenega poslovanja v zdravstvu. V panogah, kjer do uvajanja neprekinjenega poslovanja pride predvsem zaradi zahteve menedžmenta, vidimo večjo naklonjenost rešitvam visoke razpoložljivosti (nasproti rezervni lokaciji), kar je verjetno povezano z nižjimi stroški take rešitve in manjšim pritiskom regulative in zakonodaje. 3.2 Zunanji faktorji vpeljave Če pogledamo odvisnost vpeljave posameznih elementov neprekinjenega poslovanja glede na razlog vpeljave, vidimo (slika 6), da je zahteva regulative ali zakonodaje najmočnejši faktor za vpeljavo načrta neprekinjenega poslovanja. Najmočnejši trije elemen- I 1 zahteva poslovnega partnerja I I izkušnja zaradi izpada poslovanja I I zahteva poslovodstva I I zahteva regulative Slika 6 Vpliv spodbujevalcev na vpeljavo elementov neprekinjenega poslovanja ti so varnostne politike, rezervna lokacija in obvladovanje tveganja, kar je verjetno posledica močne zastopanosti finančne industrije v tej skupini in vpliv dogovora Basel II. Basel II predstavlja priporočila bančnih nadzornikov in centralnih bank iz 13 držav, ki sestavljajo baselski odbor za nadzor bančništva. Njihov cilj je poenotenje upravljanja s tveganji v bankah in poenotenju pristopa med državami. V okviru upravljanja operativnega tveganja morajo finančne institucije zagotavljati tudi neprekinjenega poslovanja in s tem implementacijo elementov neprekinjenega poslovanja. Naslednja pomembna ugotovitev je povezana z nizko oceno menedžmenta, kot spodbujevalca vpeljave neprekinjenega poslovanja. Če se spomnimo citata ekonomista Petra F. Druckerja iz uvoda, je glavna naloga organizacije postavil preživetje in vodilni princip poslovne ekonomije izogibanje izgubi. Način zagotavljanja preživetja je preprečevanje izpada poslovanja, kar se v organizacijah izvaja v okviru procesa upravljanja neprekinjenega poslovanja. Iz tega bi pričakovali bistveno večjo podporo, sodelovanje in zahtevo menedžmenta po vpeljavi neprekinjenega poslovanja v organizacijo. Žal pa je v Sloveniji povsem drugače. Sprašujemo se, ali se menedžment sploh zaveda posledic, ki jih lahko povzroči neaktivnost na področju neprekinjenega poslovanja? Ali se menedžment zaveda tveganj, ki jim je izpostavljena njihova organizacija? 3.3 Odvisnost elementov neprekinjenega poslovanja od stopnje vpeljave neprekinjenega poslovanja Tretji vpogled v rezultate ankete kaže na odvisnost med stopnjo vpeljave neprekinjenega poslovanja v organizacijo in vpeljanimi elementi neprekinjenega poslovanja. Številčno večji rezultat pomeni večjo odvisnost med stopnjo vpeljave in elementom neprekinjenega poslovanja; negativen rezultat. Negativni rezultat pomeni obratno odvisnost. Opazimo (slika 7), da organizacije vpeljujejo neprekinjeno poslovanje predvsem zaradi varnostne politike. Pri organizacijah, ki tudi preizkušajo in/ali obnavljajo načrt neprekinjenega poslovanja, sta dodatno večkrat vpeljana še rezervna lokacija in obvladovanje tveganja. Organizacije, ki se pripravljajo na vpeljavo neprekinjenega poslovanja, imajo negativno odvisnost za vse elemente, iz česar lahko sklepamo da po navadi nimajo vpeljanega še nobenega elementa neprekinjenega poslovanja. Morda je treba oznako »se pripravlja« razumeti bolj v smislu želje oz. nekakšnega srednjeročnega cilja, kot pa da se že izvaja projekt vpeljave neprekinjenega poslovanja. % -0,1 - -0,2 - -0,3 - obvl. BIA plan visoka rez. vam. upr. krizni tveganja obnove razpol. lokacija politike varnosti mgmt. I I se pripravlja [3] se redno preizkuša I I je narejen H se redno obnavlja Slika 7 Odvisnost med stopnjo vpeljave in vpeljanimi elementi neprekinjenega poslovanja 4 Sklep 5 stanjem uvajanja neprekinjenega poslovanja v Sloveniji ne moremo biti zadovoljni. Na eni strani sicer obstajajo organizacije, v katerih so že vpeljali (po navadi zaradi regulative) neprekinjeno poslovanje in se sedaj program upravlja, na drugi strani pa imamo precej podjetij, v katerih je poznavanje vsebine in problematike precej šibko tako pri informatikih kot pri menedžmentu. Rezultati ankete kažejo slabo stanje uvajanja neprekinjenega poslovanja v javni upravi in na katastrofalno stanje v zdravstvu. V večini primerov je prišlo do implementacija elementov neprekinjenega poslovanja zaradi zunanjih zahtev, ki ne izvirajo iz potreb organizacij samih, marveč so posledica regulative, zunanjih pregledov ter zahtev poslovnih partnerjev. Poznavanje te tematike znotraj Slovenije je slabo, tako znotraj menedžmenta in informatikov v organizacijah, kot pri lastnikih in zakonodajalcu. Rešitev tega stanja vidimo v izobraževanju in prenašanju znanja ter izkušenj na menedžment, informatike in stroko. Glede na njihovo pomembno vlogo v tem procesu je treba informatike izobraziti in usposobiti, da bodo prepoznali vlogo in pomen neprekinjenega poslovanja in da bodo sposobni sodelovati v celotnem procesu vpeljave in nadzorovanja neprekinjenega poslovanja. 5 Literatura [1] Drucker, Peter F.: Technology, Management, and Society. New York: Harper and Row Publishers, 1972. [2] Fulmer Kenneth, L.: Business Continuity Planning: A Step-by-Step Guide with Planning Forms, Third Edition. Rothstein Associates, 2005. 190 str. [3] Smith, D. J.: Business Continuity Management: Good practise Guidlines. VVorchester, The Business Continuity Institute, 2002, 287 str. [4] Svvanskon, Marianne, Wohl, Amy: Contingency Planning Guide tor Information Technology systems, VVashingtom: National Institue of Standard and Technlology (NISI), 2002, 92 str. [5] Toigo, Jon VVilliam: Disaster Recovery planning: strategies for protecting critical information, Upper Saddle River: Prentice Hall, 2000, 432 str. [6] Verton, Dan: Disaster Recovery Planning Stili Lags. Computervvorld, Framingham, 36(2002), 14, str. 8. [7] VVallace, Michael, VVebber, Lawrence: The Disaster Recovery Handbook - A Step-by-Step Plan to Ensure Business Continuity and Protect Vital Operations, Facilities, and Assets. Amacom, 2004. 416 str. 5.1 Viri [1] Health Insurance Portability and Accountability Act (HIPAA). [URL: htto://en.wikiDedia.org/wiki/HIPAAl. [2] Basel II. [URL:http://en.wikipedia.org/wiki/Basel_lll. Borut Žnidar je kot svetovalec za področje informacijsko-komunikacijske tehnologije zaposlen v podjetju Avtenta.si v Ljubljani. Njegovo delo obsega svetovanje in načrtovanje informacijskih rešitev na področju infrastrukture, varnosti in neprekinjenega poslovanja. Aleš Groznik je docent s področja poslovne informatike, zaposlen na Ekonomski fakulteti Univerze v Ljubljani. Področje njegovega strokovnega in raziskovalnega dela je vloga sodobnega informacijskega sistema v poslovnem okolju. Ukvarja se s področji prenove poslovanja, elektronskega poslovanja, strateškim načrtovanjem informacijskih sistemov ter revizijo informacijskih sistemov. Raziskuje možnosti in vlogo informacijskih sistemov z vidika zagotavljanja poslovnih informacij za uspešno vodenje organizacij in je revizor informacijskih sistemov (CISA). POROČILA B Uvedba podatkovnega skladišča v Banki Slovenije Luka Babnik, Banka Slovenije Luka.Babnik@bsi.si Izvleček V vse hitreje razvijajočem se svetu hitro narašča obseg poslovnih podatkov, ki imajo vedno večji pomen za delovanje organizacije. Poročanje, analize, obdelava in posredovanje poslovnih podatkov postajajo vse bolj pomembni dejavniki za vsako podjetje, saj lahko pripomorejo k zagotavljanju konkurenčnosti podjetja, optimizaciji poslovnih procesov, hitrem odzivanju podjetja na spremembe v poslovnem svetu. Namen članka je predstavitev problematike in poslovne rešitve SAP BW, ki bi bila lahko podlaga za vzpostavitev podatkovnega skladišča v Banki Slovenije. Članek obravnava tudi posamezna področja, na katerih bi predstavljena rešitev prinesla izboljšave, in namenja pozornost poslovni inteligenci. Ključne besede: poslovni proces, informacijska tehnologija, celovite programske rešitve, SAP, podatkovno skladišče, Banka Slovenije, poslovna inteligenca, podatki, poslovna rešitev SAP BW, OLAP, podatkovno modeliranje, podatkovni objekti, transakcijski podatki Abstract Data VVarehouse implementation in Bank of Slovenia In the fast developing business vvorld a number of business data is grovving rapidly. Today business data have significant impact on organizational operations. Reporting, analysis, and interpretation of business data presents one of the key fields for company in guaranteeing its competitive edge, optimizing processes and enabling it to react quickly and in line with the market. The purpose of the article is to present current problems in Bank of Slovenia and business solution SAP BW vvhich could represent a good base for data vvarehouse establishment. The article also covers other business fields vvhere proposed solution could lead to an improvement. Some attention in the article is assigned to business intelligence vvhich development in the last fevv years is very rapid. Key vvords: business process, information technology, enterprise resource systems, SAP, data vvarehouse, Bank of Slovenia, business intelligence, data, SAP BW, Online Analytical Processing (OLAP), data modeling, business info objects, transaction data 1 Uvod Vse več poslovnih procesov je podprtih z informacijsko tehnologijo, informacijski sistemi imajo vse večji pomen pri shranjevanju, obdelavi in posredovanju podatkov. Kljub temu se lahko zgodi, da nam informacija, ki jo potrebujemo, ni na voljo v danem trenutku. Podjetja se zaradi učinkovitejšega upravljanja s podatki in informacijami v vse večji meri usmerjajo k uporabi podatkovnih skladišč [angl. Data VVarehouse). Uspešno upravljanje z informacijami postaja v vsaki organizaciji vse bolj pomemben dejavnik. Podatke in informacije za vsakdanjo uporabo je treba imeti ustrezno urejene in shranjene, saj le taki omogočajo hitro in učinkovito upravljanje z njimi. Izraz podatkovno skladišče lahko opredelimo kot obsežno zbirko podatkov, ki v povezavi z orodji za obdelavo in analizo podpira procese odločanja in sprejemanja odločitev v posameznem podjetju (Egger, 2004: 13-28). Podatkovno skladišče ni odlagališče nepotrebnih podatkov, marveč predstavlja poslovno rešitev, ki v podjetju rešuje problem količine in obdelave podatkov, s katerim se ukvarja vedno več podjetij (Jaklič, 2002:18). Podatkovno skladišče predstavlja enoten vir informacij in podatkov ter tako omogoča, da vse podatke in informacije najdemo na enem mestu. Taki podatki omogočajo učinkovito izvajanje poizvedovanja, poročanja, vizualizacije podatkov, kot tudi izvajanje sprotnih analitičnih obdelav (angl. Online An-alytical Processing - OLAP). Pravočasni in točni podatki omogočajo učinkovit nadzor nad poslovanjem podjetja, kot tudi učinkovitejše poslovanje samega podjetja (Marolt, Šmid, 2005: 15). V Banki Slovenije je SAP ena izmed poslovnih rešitev, ki podpira izvajanje poslovnih procesov. Podatke, shranjene v poslovni rešitvi SAP v oddelku bančnih operacij, uporabljajo za izdelavo dnevnih in mesečnih poročil. Mesečno poročilo pripravljajo enkrat mesečno, v začetku meseca za pretekli mesec. Parametre za mesečno poročilo uporabniki lahko dobivajo s pomočjo rešitve SAP, kjer so tudi shranjeni. Končno poročilo pa je kljub temu pripravljeno v excelu, v katerega uvozijo s pomočjo rešitve SAP pri- dobljene podatke na ravni posameznih instrumentov (vrednostni papirji, depoziti, poslovni partnerji itd.). V excelu nato naredijo obdelavo in izračun pridobljenih podatkov za potrebe mesečnega poročila (kreditna izpostavljenost do posameznih izdajateljev, strukture portfelja, donosnosti itd.). Ta proces je zelo zamuden, saj enemu zaposlenemu lahko vzame tudi več kot 10 delovnih dni, poleg tega pa je pri tem velika možnost napak. Dnevno poročilo pripravljajo enkrat dnevno po koncu delovnega dne. Ob začetku naslednjega delovnega dne poročilo posredujejo v pregled in potrditev vodstvu oddelka. V tem poročilu prikažejo, do kolikšne mere so porabljeni limiti, ki so dodeljeni posameznemu krovnemu izdajatelju, in tudi morebitne kršitve kriterijev (vsota naložb pri določenem krovnem izdajatelju in njemu podrejenih izdajateljih ne sme presegati vrednosti limita). Podatke za to poročilo pridobijo s pomočjo izvajanja poslov v ozadju (angl. background job) v SAP-u, ki se nato prenesejo v excel. Vse obdelave podatkov se trenutno izvajajo prek produkcijskega strežnika, ker ni vzpostavljenega samostojnega podatkovnega skladišča, v katerem bi se shranjevali podatki, potrebni za izvajanje analiz. Osnovni namen produkcijskega strežnika je podpora izvajanju vsakodnevnih poslovnih procesov. Ker so analize in najrazličnejše obdelave ogromnih količin podatkov tako časovno, kot tudi performanč-no zelo obsežne, se izvajajo prek poslov v ozadju zunaj rednega poslovanja. Podatki so analitikom tako na voljo naslednji delovni dan. Problem, ki se tudi pojavlja pri trenutnem poslovanju, je, da analitiki ne morejo izvajati sprotnih analiz in obdelav podatkov, ker bi te preveč obremenjevale produkcijski strežnik in s tem ovirale izvajanje drugih poslovnih procesov. Vpeljava podatkovnega skladišča bi v veliki meri pripomogla k odpravi tega problema oziroma bi prinesla občutno izboljšavo poteka trenutnega poslovanja. 2 Podatkovno skladišče in poslovna inteligenca Vsako podjetje se mora vprašati, koliko časa porabi za pripravo podatkov, za izdelavo analiz in za prenos pomembnih informacij znotraj podjetja, na podlagi katerih lahko pridejo do odgovorov, rezultatov oziroma sprejetih odločitev. Časovne zamude pri pripravljanju in prilagajanju potrebnih informacij za sprejemanje odločitev so lahko za organizacije tvegane, saj se dandanes poslovne odločitve ne sprejemajo več na kvartalnih, mesečnih nivojih, ampak je potreba po analizi prišla na dnevni, ponekod celo na urni nivo (McKnight, 2006). V takem poslovnem okolju je čas vse pomembnejši. Sprejemanje poslovnih odločitev zahteva visoko kakovostne, jasno opredeljene informacije, ki jih morajo imeti uporabniki na voljo v času, ko sprejemajo odločitev. Take informacije pomagajo reševati probleme, na drugi strani pa prinašajo prednosti in nove priložnosti. V zadnjem času je v razvitem poslovnem svetu v vzponu uporaba poslovne inteligence (angl. Business Intelligence). Poslovno inteligenco lahko opredelimo kot sistem, ki omogoča analizo podatkov o poslovanju organizacije in posledic sprejetih odločitev. Poslovna inteligenca je večdimenzionalni koncept, katerega osnovne značilnosti in prednosti so hitrejše sprejemanje boljših odločitev, spreminjanje podatkov v informacije, podpora racionalnim odločitvam menedžmenta (Vitt, Luckevich, Misner, 2002). Razvoj sistemov poslovnega obveščanja je tesno povezan z razvojem informacijske tehnologije in predvsem z njeno demokratizacijo. Sodobna informacijska tehnologija uporabnikom ponuja vse več različnih sistemov za urejanje in analizo podatkov. Sprejemanje pomembnih poslovnih odločitev ni več mogoče le na podlagi dolgoletnih izkušenj, temveč je za konkurenčne odločitve nujno potrebna tudi temeljita analiza velike količine podatkov (Jaklič, 2003). Poslovno obveščanje omogoča organizacijam preprost in hiter vpogled, prikaz in iskanje podatkov, ki jih potrebujejo. Da bi iz razpoložljivih podatkov dobili čim več koristnih informacij, morajo biti podatki primerno urejeni in shranjeni. Urejene in ustrezno shranjene podatke pa zagotavljajo podatkovna skladišča. Podatkovna skladišča združujejo podatke, pridobljene iz različnih informacijskih virov, in so najprimernejša podlaga za učinkovito poslovno obveščanje. Orodja poslovnega obveščanja zagotavljajo večdimenzionalno analiziranje, poizvedovanje in poročanje podatkov, ki so shranjeni v podatkovnem skladišču. Orodja omogočajo izmenjavo informacij tudi prek intraneta in interneta. Najpogostejša orodja za poslovno obveščanje so t. i. orodja OLAP, ki omogočajo sprotno obdelavo podatkov. Glavni namen poslovnega obveščanja lahko opredelimo kot preoblikovanje podatkov v informacije in naprej v znanje ter nato v poslovno korist (dobiček, konkurenčno prednost) organizacije (Loving, 2003: 1-2). V začetku je bil temeljni cilj poslovnega obveščanja zagotovitev informacij za sprejemanje odločitev na najvišji ravni menedžmenta. V nadaljevanju so se hitro pojavile potrebe po poslovnem obveščanju na nižjih ravneh. V hitro spreminjajočih se konkurenčnih razmerah morajo biti ključne informacije na razpolago v kratkem času. Vse te zahteve pa so pripeljale do sprememb tudi v načinu komuniciranja znotraj organizacij. Tok informacij se je spremenil v tok znanja, kar pomeni, da so učinkovite informacije dostopne tam, kjer jih v določenem trenutku potrebujejo (Kovačič, Bosilj - Vukšič, 2005: 93-95). Eden izmed glavnih ciljev poslovne inteligence je omogočanje poslovnih odločitev, ki podjetju zagotavljajo nemoteno in učinkovito delovanje, hkrati pa mu prinašajo tudi konkurenčno prednost. 2.1 Predstavitev poslovne rešitve SAP BUV Podjetje SAP je svojo prvo rešitev za podatkovno skladiščenje predstavilo leta 1997. Takratna rešitev je zajemala predvsem orodja, ki so podjetju omogočala učinkovitejše upravljanje s podatki. Kasnejši razvoj je zajemal vse širši pogled poslovanja in je tako vključeval tudi vse širši zajem posameznih poslovnih komponent in aplikacij, ki so združevale poslovno rešitev. Poslovna rešitev SAP BW (angl. SAP Business Information VVarehouse - SAP BW) zajema obširno zbirko orodij, ki omogočajo zajem, transformacijo in polnjenje podatkov (ETE proces), orodja za podatkovno modeliranje, orodja, namenjena analizam in poročanju, ter orodja poslovne inteligence. Poleg tega zajema tudi številne analitične aplikacije, ki so uporabnikom v pomoč pri obdelovanju, analiziranju podatkov in omogočajo izvajanje sprotnih analitičnih obdelav podatkov (tehnologija OLAP), izvajanje večdimenzionalnih analiz z različnih poslovnih vidikov ter najrazličnejših analiz podatkov, ki so pridobljeni iz transakcijskih poslovnih sistemov oziroma drugih podatkovnih virov (Egger, 2004: 41). Poslovna rešitev SAP BW zajema številne poslovne komponente in orodja za upravljanje podatkov, podatkovno modeliranje, analitična orodja, orodja za zajem, prenos in polnjenje transakcijskih podatkov v podatkovno skladišče. Opredelimo jo lahko s tremi nivoji: . prvi nivo, ki je zadolžen za zajem, prenos in polnjenje transakcijskih podatkov (proces ETE) iz različnih podatkovnih virov v podatkovno skladišče SAP; . drugi nivo predstavlja področje podatkovnega skladišča, ki je namenjeno shranjevanju prenesenih podatkov v različnih strukturah, oblikah, vključujoč tudi multidimenzionalne strukture, imenovane podatkovne kocke (angl. InfoCube); . tretji nivo predstavljajo orodja za izvajanje analiz, poročil, katerih namen so uporabniku prijazne predstavitve z analizami pridobljenih rezultatov. SAP poslovni portal «® 9® Slika 1 Komponente SAP BUU poslovne rešitve (SAP Help, 200B) Poslovna rešitev SAP BW vsebuje orodja, ki omogočajo prilagodljivo izvajanje analiz, poročil ter predstavitev podatkov uporabnikom na prijazen in razumljiv način, kar pripomore h kakovostnejšemu izvajanju poslovnih procesov in sprejemanju poslovnih odločitev. SAP BW združuje več poslovnih komponent/rešitev in orodij. Od leta 2004 je podatkovno skladišče SAP BW ena izmed temeljnih komponent poslovne platforme, imenovane SAP NetVVeaver, ki združuje skupino poslovnih rešitev, ki pripomorejo k optimizaciji poslovnih procesov, boljšemu skladiščenju podatkov, učinkovitejšemu poslovnemu obveščanju, izvajanju analiz in obdelav ter s tem tudi k uspešnejšemu in učinkovitejšemu poslovanju celotnega podjetja (SAP Help portal, 2006). Poslovna rešitev SAP BVV je zasnovana tako, da zajema vse ključne koncepte podatkovnega skladišča. To pomeni, da zajema vse komponente, ki so potrebne za izvajanje procesov, ki so povezani s podatkovnimi skladišči in sicer: . funkcije za izvajanje ETL procesa (zajem podatkov iz podatkovnih virov, transformacija ustreznih podatkov in polnjenje podatkovnega skladišča), . komponente za shranjevanje podatkov, . orodja za obdelavo, analizo podatkov in izvajanje poročil, ■ predstavitvene komponente, ki omogočajo predstavitev pridobljenih podatkov na različne načine. Dodatna orodja/komponente poslovne rešitve omogočajo izvajanje specifičnih nastavitev in optimizacijo izvajanja, omogočajo različne možnosti prikaza podatkov itd. Arhitektura podatkovnega skladišča se deli na tri nivoje in sicer (Fu, 2002; DiMare, VVinter, 2003:1-16): ■ zgornji nivo (angl. top layer) je namenjen poročanju. To je lahko poslovni raziskovalec SAP BVV (angl. BVV Business Explorer - BEx) ali pa kako drugo orodje za poročanje (angl. third party tool). Poslovni raziskovalec SAP BVV sestavljata dve komponenti, in sicer orodje za analize (angl. BEx Analyzer) in orodje za iskanje (angl. BEx Brovvser). Orodje za analize je namenjeno izvajanju različnih analiz in obdelav, orodje za iskanje pa deluje kot informacijski center, ki uporabnikom omogoča iskanje, pregledovanje urejanje vseh vrst informacij znotraj podatkovnega skladišča. Najvišji nivo lahko predstavlja tudi poslovni portal SAP (angl. SAP Enterprise portal); • srednji nivo (angl. middle layer) predstavlja strežnik SAP BVV (angl. SAP BVV server), ki je zadolžen za naloge, kot so administracija podatkovnega skladišča in sistema, shranjevanje podatkov, pridobivanje ustreznih podatkov, ki jih potrebujejo uporabniki; . spodnji nivo (angl. bottom layer) predstavljajo izvorni podatkovni sistemi, ki vsebujejo transakcijske podatke. Izvorni sistemi so lahko poslovna rešitev SAP, podatkovne datoteke, drugi sistemi. SAP BVV omogoča povezavo s poslovno rešitvijo SAP in podatkovnimi datotekami s pomočjo tehnologije ALE (angl. Application Link Enabling), za vse druge sisteme pa prek tehnologije BAPI (angl. Bussines Application Programming Interface). Poslovna rešitev SAP BVV je zasnovana tako, da omogoča učinkovito izvajanje operacij na ravni uporabnikov in na ravni sistema. Uporabnikom omogoča uporabo številnih orodij in funkcij, s katerimi lahko obdelujejo podatke, arhitektura sistema pa omogoča nemoteno delovanje produkcijskega strežnika in s tem izvajanje rednih poslovnih procesov. 3 Analiza predstavljene rešitve in opredelitev drugih možnostih Vsaka poslovna rešitev prinaša organizaciji določene prednosti oziroma možnosti za izboljšanje poslovanja. Poslovna vrednost informatike se kaže predvsem v informatizaciji poslovnih procesov ter tako omogoča boljše in kakovostnejše izvajanje poslovnih procesov. Glavne značilnosti poslovne rešitve SAP BVV lahko opredelimo kot (Schmitt, Root, 2003:1-2; Kessler, 2003): . uporaba poslovne rešitve ni pogojena z uporabo celovite programske rešitve SAP, ■ omogoča povezavo s standardnimi poslovnimi rešitvami SAP, kot tudi z drugimi poslovnimi rešitvami, ki predstavljajo izvor transakcijskih podatkov ter s tem zagotavlja transparentnost, povezljivost rešitve, ■ vključuje orodja, ki omogočajo sprotne analitične obdelave podatkov (tehnologija OLAP), izvajanje historičnih, statističnih, distribucijskih in drugih analiz, • vsebuje orodja za preverjanje, čiščenje, preračunavanje vhodnih podatkov in orodja za razvoj podatkovnih modelov ter upravljanje podatkov, ■ zagotavlja celovitost shranjenih podatkov, ki omogočajo učinkovito izvajanje analiz in poizvedb, . poslovna rešitev je zasnovana tako, da omogoča učinkovito izvajanje analiz in obdelavo velike količine podatkov, . rešitev že vsebuje preddefinirane podatkovne modele, elemente, poročila, podatkovne kocke in druge atribute, ki pripomorejo k lažji uporabi, lahko pa pozitivno vplivajo tudi na uvajanje poslovne rešitve in so primerni za vsakdanjo uporabo oziroma so prilagodljivi spefičnim potrebam podjetja, . združuje poslovne komponente in orodja, ki omogočajo učinkovito izvajanje poslovnega obveščanja (angl. Business Intelligence), . rešitev predstavlja smiselno celoto, ki vključuje vse potrebne komponente, povezane s podatkovnim skladiščem, ki lahko pripomorejo k izboljšanju poslovnih procesov in večji učinkovitosti pri sprejemanju poslovnih odločitev. Ob uvajanju novih poslovnih rešitev se je treba zavedati, da se povsod pojavljajo tudi slabosti oziroma nevarnosti, na katere mora biti vsaka organizacija pozorna. Pri uvedbi podatkovnega skladišča bi bilo treba posebno pozornost nameniti predvsem dejavnikom, ki lahko negativno vplivajo na vzpostavitev podatkovnega skladišča, in sicer: . neustrezna izgradnja podatkovnega skladišča ne prinaša pričakovanih prednosti; . slaba kakovost vhodnih podatkov lahko vpliva na kakovost analiz in obdelav; ■ ob vzpostavitvi podatkovnega skladišča se na začetku pojavijo problemi, ki se navezujejo predvsem na časovno omejenost podatkov. Potrebna je opredelitev, kolikšna zgodovina podatkov se prenese v podatkovno skladišče; . slaba dokumentiranost obstoječih poslovnih procesov. Ob uvajanju predlagane poslovne rešitve bi bilo treba ustrezno opredeliti poslovne procese; . neizkoriščenost obstoječe informacijske tehnologije. Obstaja nevarnost, da tudi nova poslovna rešitev ne bi bila izkoriščena optimalno; . neustrezna opredelitev poslovnih potreb in ciljev lahko bistveno podaljša proces implementacije oz. pripelje do neuspešne izgradnje podatkovnega skladišča in zviša predvidene stroške; . potrebe po novem usposabljanju kadrov, pridobivanju novega znanja za vzdrževanje in uporabo implementirane poslovne rešitve ter dodatna obremenitev ključnih uporabnikov ob uvajanju poslovne rešitve; . obstajajo določena poslovna tveganja, ki vplivajo na izvajanje poslovanja in tveganja, povezana z informacijsko tehnologijo. Predpostavljata se tudi dve drugi možnosti - lastni razvoj podatkovnega skladišča ali nakup poslovne rešitve drugega proizvajalca. Lastni razvoj ne bi bil racionalen glede na to, da na trgu že obstajajo uveljavljene poslovne rešitve, ki zagotavljajo rešitev opredeljene problematike. Za lastni razvoj bi bila potrebna angažiranost velikega števila ljudi, hkrati pa gre pri projektu implementacije podatkovnega skladišča za dolgotrajen projekt, ki je tudi finančno zahteven. Lastni razvoj bi bil smotrn, če bi bile poslovne potrebe skromne in ozko usmerjene, če bi bilo za razvoj neomejeno časovno obdobje in bi imeli na razpolago skupino projektantov/programerjev, ki bi se ukvarjala izključno s to nalogo. Z implementacijo ustrezne poslovne rešitve, ki je že povezljiva s poslovno rešitvijo SAP, se izognemo tudi dodatnemu delu ob novih verzijah rešitve SAP. Globalno zasnovane poslovne potrebe in cilji pomenijo, da lastni razvoj ni primeren, zato se predlaga nakup oziroma implementacija nove programske oziroma poslovne rešitve, ki bi pokrivala opredeljene zahteve. Na trgu obstajajo številna uveljavljena podjetja, ki ponujajo poslovne rešitve za vzpostavitev podatkovnih skladišč. Ob vzpostavitvi poslovne rešitve drugega proizvajalca se je treba zavedati, da bo potreben obsežen lasten razvoj za povezavo drugih sistemov in aplikacij, med drugim tudi rešitve SAP s podatkovnim skladiščem, ki bi bilo razvito in kamor se bodo prenašali vsi ustrezni transakcijski podatki. Tak način uvedbe podatkovnega skladišča bi nedvomno zahteval tudi obširnejše spoznavanje tehnologije in funkcionalnosti poslovne rešitve drugega proizvajalca. Trenutno je poznavanje poslovne rešitve SAP tako na strani informatikov kot tudi ključnih poslovnih uporabnikov na visokem nivoju. Ob uvedbi poslovne rešitve drugega proizvajalca bi bila potrebna obsežnejša izobraževanja in svetovanja, kot v primeru uvajanja poslovne rešitve SAP BW, saj imajo tako informatiki kot tudi uporabniki že določeno znanje s področja rešitve SAP. Glede na obstoječe stanje uvedba podatkovnega skladišča na podlagi poslovne rešitve drugega proizvajalca ne bi bila optimalna, saj predstavljena poslovna rešitev SAP BW pokriva večino opredeljenih poslovnih zahtev in ciljev. Glede na izvedeno stroškovno analizo je vzpostavitev predstavljene rešitve v primerjavi z lastnim razvojem oziroma vpeljavo rešitve drugega proizvajalca najbolj primerna. Eden od razlogov za uvedbo poslovne rešitve SAP BW je tudi, da je trenutno poslovanje v oddelku bančnih operacij podprto tudi z rešitvijo SAP, zato bi bila implementacija rešitve SAP BW laže izvedljiva, obenem pa bi z omenjeno poslovno rešitvijo lahko zadovoljili opredeljene zahteve. 4 Vpliv uvedbe podatkovnega skladišča na poslovanje Merjenje učinkovitosti informacijskih rešitev je težko, s tem pa je težko opredeliti tudi finančne učinke. Lahko pa koristi/učinke nove poslovne rešitve opredelimo kot (Groznik, 2006: 57-58): nižje stroške poslovanja, večji prihodek, krajši čas izvajanja poslovnih procesov oziroma aktivnosti, boljše in hitrejše odločanje, boljšo informiranost zaposlenih, prilagodljivo, fleksibilno poslovanje, boljšo organiziranost. Uvedba podatkovnega skladišča bi omogočila priložnosti za izvajanje izboljšav na številnih področjih. Spremembe, ki bi se ob uvedbi podatkovnega skladišča pojavile, lahko predstavljajo izhodišča za nadaljnji razvoj. Glavne spremembe oziroma prednosti uvedbe podatkovnega skladišča: • Prenova obstoječih poslovnih procesov. Uvedba podatkovnega skladišča bi sprva mogoče imela manjši vpliv na potek posameznih poslovnih procesov. Sčasoma, ko bi rešitev v celoti zaživela, bi se pokazale prave vrednosti in prednosti, ki jih lahko pridobimo z uvedbo podatkovnega skladišča. Za uporabnike bi eno izmed bistvenih prednosti predstavljala izboljšava na področju priprave poročil, ki jih trenutno, zaradi razpršenosti podatkov in posameznih aplikacij, ki pripravljajo podatke, izdelujejo tudi več dni. Podatkovno skladišče bi analitikom omogočalo celoten nabor najrazličnejših orodij, s pomočjo katerih bi izvajali kakovostne analize in bi tako imeli dober pregled nad poslovanjem in investicijami, ki se izvajajo v oddelku bančnih operacij. Celovitost poslovne rešitve SAP BW bi omogočala opustitev številnih samostojnih aplikacij/ programov, ki so v tem trenutku potrebni zaradi pridobivanja najrazličnejših podatkov, s pomočjo katerih uporabniki sestavljajo poročila. Integracija podatkovnega skladišča z rešitvijo SAP BW bi omogočala hitrejše, kakovostnejše izvajanje procesov. Le-to bi omogočala urejenost, celovitost in integriranost podatkov v podatkovnem skladišču ter tako pozitivno vplivala na hitrost iskanja, pridobivanja podatkov, potrebnih za analize in obdelave. Uporabniki bi imeli na voljo ustrezno ure- jene, celovite, integrirane, kakovostne podatke, ki bi jih lahko sproti analizirali, številna orodja pa bi jim omogočala izvajanje najrazličnejših analiz, obdelav in kreiranje potrebnih poročil. Poslovna rešitev bi omogočala, da uporabniki ne bi bili omejeni na preddefinirana poročila, marveč bi imeli možnost izdelave svojih poročil, poizvedb in analiz brez sodelovanja informatikov, kar bi v primerjavi s sedanjim načinom dela močno pospešilo celoten poslovni proces. Izvajanje poslovnih procesov bi z uvedbo podatkovnega skladišča in integracijo rešitve SAP postalo kakovostnejše, uporabniki pa bi s tem prihranili predvsem čas, na voljo pa bi imeli kakovostne, ažurne in natančne podatke. Poslovna rešitev bi vplivala tudi na izboljšanje upravljanja podatkov in izvajanja poslovnih analiz. Rezultati in pridobljeni podatki bi pozitivno vplivali na izboljšanje sprejemanja poslovnih odločitev, nadzora poslovanja, upravljanja z denarnimi sredstvi ter izboljšanje nadzora in varnosti investicijske strategije. Omenjene prednosti na področjih upravljanja z denarnimi sredstvi in izboljšanja učinkovitosti lahko pripomorejo k povečanju prihodkov za 1 bazično točko (0,01 %) na letni ravni. Pri prenovi poslovnih procesov se je treba zavedati, da samo z nakupom nove informacijske rešitve oziroma tehnologije ne bomo uspešni pri prenovi poslovnih procesov, s tem pa tudi ne pri doseganju poslovnih ciljev. Prenova in informatizacija poslovnih procesov omogočata, da so poslovni procesi učinkoviti in uspešni. Omogočata njihovo fleksibilnost in predstavljata podlago za uspešen menedžment poslovnih procesov. Spremembe zajemajo celotni življenjski cikel poslovnega procesa. Zajema, vključuje in povezuje obstoječe ter nove metode in orodja na tem področju (Kovačič, Bosilj - Vukšič, 2005). Menedžment poslovnih procesov z usklajenimi ukrepi na področju organiziranosti, obvladovanja procesov in njihove informatizacije odpravlja nepovezanost med strateškim in operativnim menedžmentom, ki povzroča težave v mnogih organizacijah, ter zagotavlja ustrezno podlago za spremljanje poslovanja in ukrepanje. - Izboljšanje kakovosti podatkov. Podatkovno skladišče bi predstavljajo enoten vir integriranih podatkov namenjenih izvajanju analiz in poročil ter s tem pripomoglo k večji kakovosti podatkov in izvajanju hitrih, učinkovitih analiz. Uvedba poslovne rešitve bi izboljšala kvaliteto transakcijskih podatkov, saj bi bili podatki ob prenosu v podatkovno skladišče ustrezno prečiščeni, preverjeni in urejeni. Posebno pozornost bi bilo treba nameniti programom za zajem transakcijskih podatkov, da ne bi prihajalo do napak v posameznih izračunih oziroma do pomanjkljivih podatkov. Morebitne napake v transakcijskih podatkih bi lahko odpravili neposredno v transakcijskem sistemu. Ustrezno opredeljeni in definirani podatkovni modeli bi omogočali lažjo nadgradnjo oziroma dodajanje novih atributov oziroma virov. Z ustrezno definiranimi pravili osveževanja bi se podatki lahko dnevno osveževali, kar bi pripomoglo k izvajanju analiz na podlagi najnovejših podatkov. • Informacijska tehnologija. Trenutno je del poslovanja v Banki Slovenije že podprt s poslovno rešitvijo SAP, ki bi ob implementaciji podatkovnega skladišča predstavljala glavni izvorni vir transakcijskih podatkov. Prenos transakcijskih podatkov iz SAP v podatkovno skladišče bi bil zato laže izvedljiv. Podatke, ki jih pripravljajo zunanji sistemi in aplikacije bi ob pomoči vmesnikov prenašali v podatkovno skladišče. Ker je poslovna rešitev neodvisna komponenta, njeno delovanje ne bi vplivalo na produkcijski strežnik. Trenutno se obsežne obdelave in analize ne morejo izvajati sproti »on-line«, ampak le v ozadju. Ena izmed večjih prednosti integracije poslovne rešitve SAP in podatkovnega skladišča bi bila nadomestitev določenih obstoječih aplikacij/programov, ki so trenutno namenjeni za izdelavo posameznih poročil. S tem bi rešili problem razpršenosti posameznih aplikacij/programov, ki se je pojavljal v preteklosti, poslovni proces pa bi izvajali v celoti s pomočjo enotne, integrirane poslovne rešitve. Informacijska tehnologija ponuja veliko možnosti vpliva na poslovanje. Vpeljava informacijske tehnologije zaradi nje same ni pravilna rešitev. Informacijska tehnologija je sredstvo za uresničevanje poslovnih izzivov. Pokrivati mora ključne poslovne procese podjetja in se usmeriti v povezave s poslovnimi partnerji. Glede na Gartnerjeve raziskave med direktorji informatike (Blosch, McDonald, 2005) bosta glavni prioriteti v naslednjih letih izboljševanje, integriranje in prenavljanje poslovnih procesov ter strateška uporaba informacijske tehnologije, zlasti poslovne inteligence. Za uspešno uvedbo podatkovnega skladišča oziroma uspešno izvedbo samega projekta so pomembni tudi drugi dejavniki, t. i. dejavniki uspeha, ki bi morali biti zagotovljeni ob vpeljevanju podatkovnega skladišča. ■ Pripravljenost zaposlenih na spremembe. Nova poslovna rešitev bi tako kot vsaka sprememba prinesla določene novosti, ki bi jih bilo treba usvojiti. Novosti bi se navezovale tako na področje informatike kot tudi na poslovno področje. V primeru uvajanja podatkovnega skladišča bi šlo za projekt velike razsežnosti, ki bi se izvajal ob pomoči zunanjih svetovalcev z izkušnjami na tem področju. Sodelovanje zunanjih svetovalcev omogoča usvojitev določenih znanj že ob samem uvajanju poslovne rešitve. Ker bi šlo za uvajanje nove tehnologije, ki je v banki še ne uporabljamo, bi imelo sodelovanje z zunanjimi sodelavci velik pomen pri pridobivanju novega znanja tako za informatike kot tudi za poslovne uporabnike. Z novo tehnologijo bi se spremenil način dela uporabnikov. Prednost je, da so ključni uporabniki rešitve SAP že izkušeni, zato uvedba podatkovnega skladišča ne bi smela predstavljati velikih težav pri prilagajanju na novi način dela. Z udeležbo na seminarjih, delavnicah in svetovanjih bi si zaposleni lahko pridobili nova znanja od strokovnjakov s tega področja. . Organizacijska kultura. V sodobno razvitem poslovnem svetu se menedžment vedno bolj zaveda pomembnosti podatkov, analiz in obdelav, ki lahko pripomorejo k boljšemu sprejemanju poslovnih odločitev. Informatika kot ena izmed gonilnih sil zagotavljanja konkurenčne prednosti podjetja, potrebuje tudi ustrezen položaj v podjetju. Vodja informatike mora biti v tesni povezavi z vodstvom podjetja, saj lahko le na ta način izpolni svojo vlogo, ki je vodenje (povezava med poslovanjem in tehnologijo), spremljanje okolja (zaznavanje ključnih trendov), pripravljanje strategije (spremljanje povpraševanja in usklajevanje), organiziranje (organiziranje informatike), dostavljanje (zagotavljanje stroškovno in časovno ugodne storitve), merjenje (merjenje, kje se nahaja informatika/podjetje, in vedeti, zakaj se nahaja tam) (Kitzis, 2003). Tudi v našem primeru bi projekt implementacije podatkovnega skladišča moral biti strateškega pomena in imeti podporo najvišjega menedžmenta. Projektna skupina za izvajanje implementacije bi morala biti ustrezno sestavljena in vodena, nadzorovana s strani člana, ki predstavlja vrhnji menedžment. Podpora najvišjega vodstva bi pripomogla k uspešnemu izvajanju projekta, sama poslovna rešitev pa bi tako laže zaživela v uporabi. 5 Sklep Predlogi za nadaljnji razvoj so tesno povezani s področji, kjer bi se pojavile spremembe zaradi uvajanja predlagane poslovne rešitve. Predlagane izboljšave, ki bi jih prineslo podatkovno skladišče, lahko predstavljajo izhodišča za nadaljnji razvoj, ki bo potreben za uspešno izvajanje poslovanja v bližnji prihodnosti. V sodobnem poslovnem svetu imajo podatki in informacije vse večji pomen, zato večina podjetij že uporablja sodobno razvita podatkovna skladišča in druga orodja, ki omogočajo izboljšanje podatkovnih analiz in tako v veliki meri lahko pripomorejo k izboljšanju poslovnih odločitev. V zadnjem času se v sodobnem poslovnem svetu odvija skokovit razvoj tehnologije poslovne inteligence. V Sloveniji tega razvoja po zadnjih raziskavah še ni videti, a bo slej kot prej zajel tudi slovenska podjetja. Po rezultatih raziskave za leto 2005/ 2006, ki jo je izvedel inštitut za poslovno informatiko na ekonomski fakulteti, je delež podjetij, kjer menijo, da orodij poslovne inteligence ne potrebujejo, med 10 in 12 odstotki, v več kot 20 odstotkih podjetij pa je poslovanje s to tehnologijo zelo slabo pokrito. Rezultati kažejo zaostajanje slovenskih podjetij za tujino pri uvajanju nove informacijske tehnologije (Inštitut za poslovno informatiko, 2006). Na področju podatkovnih skladišč in orodij za podporo odločanju je stanje malo boljše, a še vedno je viden zaostanek za tujino. Po rezultatih raziskave v okrog 48 odstotkih podjetij že uporabljajo podatkovna skladišča, okrog 24 odstotkov podjetij pa načrtuje razvoj in uporabo podatkovnih skladišč v bližnji prihodnosti. V zadnjih petih letih se je delež podjetij, ki uporabljajo podatkovna skladišča, povečal le za dobrih 16 odstotkov, kar dokazuje, da razvoj na tem področju ni tako hiter kot v tujini. Ključne ugotovitve raziskave so pokazale, da so podatkovna skladišča dokaj dobro zastopana v slovenskih podjetjih, vendar bi podjetja morala večjo pozornost posvečati kakovosti podatkov, shranjenih v podatkovnih skladiščih. Raziskava je pokazala, da v veliki večini uvedba podatkovnega skladišča privede do izboljšanja transakcijskih poslovnih procesov, saj so identifikacije posameznih problemov lažje in s tem tudi možnost odprave in optimizacije procesov (Groznik et al., 2006: 1-41). Ugotovitve raziskave kažejo, da se tudi v Sloveniji vse večji pomen daje podatkovnim skladiščem in počasi tudi drugim tehnologijam, ki so v sodobnem svetu že dobro razvite. Tudi v Banki Slovenije bi uvedba podatkovnega skladišča zagotovo prinesla pozitivne učinke na poslovanje. Poslovna rešitev SAP BW je toliko bolj zanimiva, saj gre za celovito poslovno rešitev, v kateri je zajeta sodobna tehnologija, ki omogoča poleg podatkovnega skladišča tudi uporabo tehnologije poslovne inteligence in vrsto drugih orodij, ki lahko pripomorejo k izboljšanju trenutnega poslovanja. 6. Literatura in viri 1. Blosch, M., McDonald, M. (2005): Delivering IT's Contribution: The 2005 CIO Agenda, Gartner. 2. DiMare, David J., Winter, Richard: SAP Business Information VVarehouse; Multi Terabyte Evaluation and Feasibility test. VValtham: VVinter Corporation, 2003. 16 str. 3. Egger, Norbert: SAP BW Proffesional; Tips and tricks for dealing with SAP Business Information VVarehouse. SAP PRESS, Bonn, 2004. 418 str. 4. Fu, Henry: Data VVarehousing and SAP BW. Addison Wesley Professional, 2002. [URL:http://www.awprofessional.com/articles/ printerfriendly.asp?p=28666&rl=l] 5. Groznik Aleš: Strateško načrtovanje informatike. Univerza v Ljubljani, Ekonomska fakulteta, 2006. 66 str. 6. Groznik, Aleš et al.: Stanje poslovne informatike v Sloveniji. Univerza v Ljubljani, Ekonomska fakulteta, Inštitut za poslovno informatiko, 2006. 41 str. 7. Jaklič, Jurij: Upravljanje in uporaba podatkov. Ljubljana: Ekonomska fakulteta, 2002. 213 str. 8. Jaklič, Jurij: Baze podatkov in njihova uporaba. Ljubljana: Ekonomska fakulteta, 2003. 186 str. 9. Kessler, Udo: More Time for Analysis and Enterprise Control, SAP info, Oktober 2003. [ U R L: h ttp ://www. sa p. i nfo/ index.php4?ACTION=noframe&url=http://www.sap.info/ public/l NT/int/index/Category-28803c61b2496f2c9-inV-l/ articleContainer-78143f854306a3eb6] 10. Kitzis, E.: CIO Agenda 2003-2004: Drive Enterprise Effectiveness, Gartner Symposium ITXP0, Lake Buena Vista, Florida 20-24 okt., 2003. 11. Kovačič, Andrej, Bosilj - Vukšič, Vesna: Management poslovnih procesov. Ljubljana: GV Založba, 2005. 487 str. 12. Loving, Tim: Use business intelligence to make better decisions. Gale Group, 2003. 2 str. [URL: http://vwvw.findarticles.eom/p/ articles/mi_mOFNP/is_l_42/ai_ 96378489] 13. Marolt Šmid, Jasna: »Kako učinkovito je vaše poslovanje?«. Revija Infosrc.si, Ljubljana, 2005/št. 43. 33 str. 14. McKnight, VVilliam: Building Business Intelligence; get to the point. DM Revievv, 2006. 2 str. [URL: http://www.dmreview.com/portals/ portalarticle.cfm?articleld= 1057931 &topicld=230064]. 15. SAP Help portal: SAP Business Information VVarehouse. [URL: http://help.sap.com/saphelp_nw04/helpdata/en/e3/ e60138fede083del0000009b38f8cf/frameset.htm], 11. 8. 2006. 16. Schmitt, Erič, Root, L. Nate: Scorecard Summary; SAP Business Information VVarehouse. Forrester Research, Inc., 2003. 2 str. [URL:http://www.forrester.com/ Research/PDF/ 0,5110,16399,OO.pdf]. 17. Vitt, Elizabeth, Luckevich, Michael, Misner, Stacia: Business Intelligence. Microsoft Press, 2002. 224 str. Luka Babnik je končal univerzitetni študij leta 2004 na Fakulteti za organizacijske vede Univerze v Mariboru. Leta 2005 se je vpisal na podiplomski študij na Ekonomski fakulteti Univerze v Ljubljani, smer poslovna informatika, in leta 2006 zagovarjal magistrsko delo. Od leta 2004 je zaposlen kot projektant v oddelku informacijska tehnologija v Banki Slovenije, kjer dela na področju informacijskega sistema SAP. KOLEDAR PRIREDITEV DSI 2007 - Dnevi slovenske informatike 2007 Z informatiko do novih poslovnih priložnosti 11.-13. apr. 2007 Portorož, Slovenija http://www.dsi2007.si ISPASS 2007 - International Symposium on Performance Analysis of Systems and Software 25.-27. apr. 2007 San Jose, Kalifornija, ZDA http://www.ispass.org ACM 2007 - International Conference on Computing Frontiers 7.-9. maj 2007 Ischia, Italija http://www.computingfrontiers.org ASGI '07 - Workshop on Architectural Support for Gigascale Integration 10. jun. 2007 San Diego, Kalifornija, ZDA http://www.ece.cmu.edu OTS 2007 - 12. konferenca Sodobne tehnologije in storitve 13.-14. jun. 2007 Maribor, Slovenija http://www.cot.si/ots2007 OSPERT 2007 - VVorkshop on Operating Systems Platforms for Embedded Real-Time applications 3.-6. jul. 2007 Piša, Italija http://www.cs.ucsc.edu RTCSA 2007 -13th IEEE Conference on Embedded and Real-Time Computing Systems and Applications 21.-24. avg. 2007 Daegu, Južna Koreja http://www.rtcsa.org Hoti 2007 - Hot Interconntents 15 - IEEE Symposium on High-Performance Interconntents 22.-24. avg. 2007 Palo Alto, Kalifornija, ZDA EGOV 2007 - Sixth International EGOV Conference 3.-7. sep. 2007 Regensburg, Nemčija http://www.dexa.org PACT 2007 - 16th International Conference on Parallel Architectures and Compilation Technigues 15.-19. sep. 2007 Brasov, Romunija http://pactconf.org e-Smart '07 - The leading smart card industry conference 19.-21. sep. 2007 Sophia Antipolis, Francija www.strategiesm.com/conferences/ esmart/07/calls.htm#research MeTTeG '07 - lst International Conference on Methodologies, Technologies and Tools enabling e-Govemment 27.-28. sep. 2007 Camerino, Italija http://conferences.cs.unicam.it/metteg07 ICL 2007 - ePortfolios & School and IT 27.-28. sep. 2007 Beljak, Avstrija www.icl-conference.org EMBEDDED SVSTEMS WEEK 2007 - CODES + ISSS 2007 - Fifth International Conference on Hardware/Software Codesign and System Synthesis 30. sep.-5. okt. 2007 Salzburg, Avstrija www.esweek.org ; www.codes-isss.org EMBEDDED SVSTEMS WEEK 2007 - Seventh International Conference on Embedded Softvvare www.esweek.org; www.emsoft.org EMBEDDED SVSTEMS WEEK 2007 - International Conference on Compilers, Architecture and Synthesis for Embedded Systems www.casesconference.org www.esweek.org; eGovINTEROP '07 - eGovernment lnteroperability Campus 2007 9.-12. okt. 2007 Pariz, Francija www.egovinterop.net VVMUNEP '07 - Third ACM International VVorkshop on VVireless Multimedia Networking and Performance Modeling 22.-26. okt. 2007 Chania, Kreta, Grčija http://wmunep2007.cti.gr/ SC '07 - 20th International Conference for Hight -Performance Computing, Networking, Storage and Analysis 10.-16. nov. 2007 Reno, Nevada, ZDA http://sc07.supercomputing.org HICSS41 41st Hawaii International Conference on System Sciences 6.-10. jan. 2008 ??? http://www.hicss.hawaii.edu HiPEAC 2008 - International Conference on Hight Performance Embedded Architectures & Compilers 27.-29. jan. 2008 Goteborg, Švedska http://www.hipeac.net/conference Včlanite se v Slovensko društvo INFORMATIKA Pristopna izjava Želim postati član Slovenskega društva INFORMATIKA Prosim, da mi pošljete položnico za plačilo članarine 33,55 € [8.040 SIT] (kot študentu 14,52 € (3.480 SIT)) in me sproti obveščate o aktivnostih v društvu. V članarini je upoštevan DDV v višini 20 %. (ime in priimek, s tiskanimi črkami) (poklic) (domači naslov in telefon) (službeni naslov in telefon) (elektronska pošta) Datum: Podpis: Članarina vključuje naročnino na revijo Uporabna informatika. Študenti imajo posebno ugodnost: plačujejo članarino 14,52 6 (3.480 SIT) in prejemajo tudi revijo. Naročilnica na revijo UPORABNA INFORMATIKA Revijo naročamto) EU s plačilom letne naročnine 33,81 € (8.000 SIT) I I izvodov po pogojih za podjetja 83,46 € (20.000 SIT) za enoletno naročnino in 58,48 € (14.000 SIT) za vsako nadaljnjo naročnino EU po pogojih za študente letno 14,61 € (3.500 SIT) V cenah je upoštevan DDV v višini 8,5 %. (ime in priimek, s tiskanimi črkami) (podjetje) (davčna številka) (ulica, hišna številka) (pošta) Datum Podpis: Naročnino bomo poravnali najkasneje v roku 8 dni po prejemu računa. Izpolnjeno naročilnico ali pristopno izjavo pošljite na naslov: Slovensko društvo INFORMATIKA, Vožarski pot 12,1000 Ljubljana Lahko pa izpolnite obrazec na domači strani društva: http://www.drustvo-informatika.si Vse bralce revije obveščamo, da lahko najdete domačo stran društva na naslovu http://www.drustvo-informatika.si Obiščite tudi spletne strani mednarodnih organizacij, v katere je včlanjeno naše društvo: IFIP www.ifip.or.at ECDL www.ecdl.com CEPIŠ: www.cepis.com NARODNA in univerzitetna knjižnica II 433 7482007 920072359,1 I Razprave Matjaž B. Jurič, Marjan Maričko, Ivan Rozman Raziskava o uporabi storitvenih arhitektur v Sloveniji Jurij Jaklič, Tatjana Huber, Marko Svetina, Mojca Indihar štemberger Menedžment poslovnih procesov v oskrbovalni verigi - Primer Merkur Katja Han^Tatjana VVeizer Družovec Upravljanje znanja - informacijska podpora ali sistem za ohranjanje Marko Tekavc, Marjan Maričko Uporaba metrik pri identifikaciji smiselnih preoblikovanj programske kode Borut Žnidar, Aleš Groznik Upravljanje neprekinjenega poslovanja v slovenskih organizacijah ■ LuRa Babnik Uvedba podatkovnega skladišča v Banki Slovenije 1 : : I .; ISSN 1316-1882 (‘V«*!-'-’* • a 771318 188001