37 4 UDK: 659.23:004.4/.6 Uvedba celovitih informacijskih rešitev (rešitev ERP) je zaradi svoje kompleksnosti zapletena, zato se je morajo organizacije lotiti premišljeno in pri tem upoštevati metodo uvajanja, ki jo priporoča ponudnik rešitve ERP. Obenem morajo zagotoviti pogoje uvajanja, ki bodo omogočili uspešno in učinkovito uvedbo rešitve ERP. Zaradi velikega števila neuspešno uvedenih rešitev ERP na pomenu pridobiva proučevanje dejavnikov KDU, ki vplivajo na uspeh uvedbe rešitve ERP. Raziskava v slovenskih podjetjih je pokazala, da metoda uvedbe ne vpliva na pomembnost KDU, da v okviru posamezne metode ponudnika obstajajo povezave med KDU in da obstajajo razlike v pomembnosti KDU pri uvajanju rešitev glede na metodologijo ponudnika. Ključne besede: celovite informacijske (ERP) rešitve, uvajanje celovitih (ERP) rešitev, SAP, Navision, GEAC I z v l e č e k JEL: L86 Mag. Simona Sternad, viš. pred. Zdenko Deželak, asist. Heri Špička, pred. Univerza v Mariboru Ekonomsko-poslovna fakulteta Uroš Zabukovšek, prof. rač. z mat. Univerza v Mariboru Pedagoška fakulteta Model of Critical Success Factors of Implementation SAP and Navision Solutions MODEL KRITIČNIH DEJAVNIKOV USPEHA UVAJANJA REŠITEV SAP IN NAVISION STERNAD IDR.: MODEL KRITIČNIH DEJAVNIKOV USPEHA UVAJANJA REŠITEV SAP IN NAVISION UDC: 659.23:004.4/.6 Implementation of enterprise resource planning solutions (ERP solutions) is a complicated task because of its complexity. Organizations must start implementation deliberately and have to take into consideration the implementation methodology of an ERP vendor. The study of factors (CSF) which influence the success of the implementation of ERP solutions is important because of several unsuccessful implementation attempts. Research conducted in Slovenian organizations has shown that implementation method did not have any influence on the importance of CSF, that there is a connection between CSFs within each vendor implementation method, and that there are differences in importance of CSFs within each vendor methodology. Key words: enterprise resource planning solutions, ERP solutions, implementation of ERP solutions, SAP, Navision, GEAC A b s t r a c t 1 Uvod Zaradi vse bolj dinamičnega poslovnega okolja in vse večje konkurence na trgu, potrebujejo organizacije informacijske sisteme, ki bodo celovito podpirali njihovo poslovanje, hkrati pa bodo omogočali uresničevanje razvojnih ciljev. Vse pogosteje organizacije preprosto nimajo časa, denarja ali drugih virov, da bi razvile takšne celovite informacijske sisteme (v nadaljevanju IS). Zato se organizacije ponavadi raje odločijo za uvedbo celovite informacijske rešitve (v nadaljevanju rešitve ERP) kot pa lastne rešitve. Rešitve ERP v celoti podpirajo poslovanje (vse poslovne funkcije) in so sestavljene iz več modulov, kot so npr. proizvodnja, finance, logistika, človeški viri in drugi. Pojavile so se šele v devetdesetih letih, ko so se pojavile nslednje tehnološke izboljšave: grafični uporabniški vmesniki oziroma s kratico vmesniki GUI (angl. Graphical User Interface), relacijske podatkovne baze, 4. generacija programskih jezikov, orodja CASE (angl. Computer Added Software Engineering) in arhitekture odjemalec/strežnik. Tako lahko rešitve ERP prepoznamo po naslednjih značilnostih (O’Leary 2000): so gotove programske rešitve, izdelane za arhitekturo odjemalec/strežnik, ne glede na to, ali uporabljajo običajne ali spletne odjemalce, v njih je združena večina poslovnih procesov, obdelajo večino transakcij v podjetju, uporabljajo podatkovno bazo na ravni organizacije, v kateri je vsak podatek zapisan samo enkrat, omogočajo dostop do podatkov v realnem času itd. Poleg tega se od njih pričakuje, da podpirajo več valut in jezikov, imajo podporo za podjetja v različnih panogah ter možnost prilagoditve rešitev brez programiranja (t.i. prilagajanje). Ker pa poslovno okolje sili organizacije, da se povezujejo, so organizacije začele pritiskati na ponudnike rešitev ERP, da naj pripravijo module, s pomočjo katerih bi si izmenjevale podatke. Tako so ponudniki rešitev ERP dodali module, med katere uvrščamo e-poslovanje (angl. e-business), modul oskrbovalne verige (angl. Supply Change Management) in modul odnosov s kupci (angl. Customer Relation Management). Uvedba rešitev ERP je zaradi njihove kompleksnosti zapletena, zato se je morajo organizacije lotiti premišljeno in pri tem upoštevati metodo uvajanja, ki jo priporoča ponudnik rešitve ERP, hkrati pa morajo zagotoviti pogoje uvajanja, ki bodo omogočili uspešno in učinkovito uvedbo rešitve ERP. Uvedba rešitve ERP je zato strateški projekt organizacije. Zaradi velikega števila neuspešno uvedenih rešitev ERP pridobiva na pomenu proučevanje dejavnikov, ki vplivajo na uspeh uvedbe rešitve ERP. Objave v svetu izvedenih raziskav, ki so dosegljive v tiskanih in elektronskih virih, navajajo mnogo kritičnih dejavnikov uvajanja (v nadaljevanju KDU) rešitev ERP. Ne raziščejo pa pomena KDU v povezavi z uporabljeno metodo uvajanja rešitve ERP. Ker se za uvajanje rešitev ERP najpogosteje uporabljajo metode ponudnikov rešitev ERP, podjetja rešitev SAP uvajajo po metodi ASAP, za uvajanje rešitve Navision pa se uporablja metoda On Target. Zaradi tega bomo v nadaljevanju najprej na kratko opisali uvedbo rešitve ERP in metodi dveh ponudnikov rešitev ERP. Sledijo na kratko povzeta spoznanja iz raziskav, ki so bile izvedene v svetu, nato pa bo predstavljena raziskava, izvedena v slovenskih podjetjih, ki so v bližnji preteklosti uvajala rešitev ERP. V raziskavi bomo preverili, ali obstaja razlika 38 NG, ŠT. 1–2/2007 IZVIRNI ZNANSTVENI ČLANKI/ORIGINAL SCIENTIFIC PAPERS med pomembnostjo KDU pri uvajanju rešitev ERP v Sloveniji in KDU pri uvajanju rešitev v tujini. Nato bomo preverili, ali metoda uvedbe vpliva na pomembnost KDU pri uvajanju rešitve ERP. Prav tako bomo preverili, ali obstajajo povezave med posameznimi KDU, uvedenimi po metodi ponudnika, in ali obstajajo razlike v rangiranju KDU pri uvajanju rešitev po metodologiji On Target in metodologiji ASAP. 2 Uvajanje celovitih informacijskih rešitev Raziskave kažejo, da velik odstotek projektov uvajanja IS ni izveden v predvidenem času, s predvidenimi stroški ali v predvidenem obsegu. Organizacija Standish Group International je v raziskavi prišla do zaključka, da je bilo 28 odstotkov vseh informacijskih projektov opuščenih pred zaključkom, 46 odstotkov pa jih ni bilo zaključenih v predvidenem času, s predvidenimi stroški ali v predvidenem obsegu (Laudon idr. 2000). Podobno kažejo tudi raziskave uvajanj rešitev ERP. Tudi pri uvedbi rešitev ERP se pojavlja velik odstotek opustitve uvajanj rešitev ERP (35 %) ali pa projekt uvedbe rešitve ERP ni bil zaključen v predvidenem roku, predvidenih stroških ali predvidenem času (55 %). Samo 10 odstotkov projektov uvedb rešitev ERP je bilo uspešno uvedenih (Bajwa 2004). Ker dolgotrajno uvajanje povečuje tveganja projektov uvedbe rešitve ERP, stroške projekta uvedbe rešitve ERP in zmanjšuje zavzetost in zaupanje projektnega tima v uspeh projekta uvedbe rešitve ERP, so ponudniki rešitev ERP pripravili svoje metodologije uvajanja rešitev ERP, ki temeljijo na hitri strategiji (angl. Breakneck strategy) in jo poimenovali hitra vpeljava (angl. rapid implementation). Ideja hitre strategije je, da organizacija najde in uvede rešitev ERP kolikor hitro je mogoče in z minimalnimi stroški. Hitra vpeljava rešitve vsebuje majhno število faz, ki jih ponavadi uvedemo po pristopu velikega poka (angl. Big Bang approach), faznem pristopu (angl. Phased approach) ali kombinaciji teh dveh. Metodologija uvajanja rešitev ERP ponudnikov rešitev ERP vključuje vsa potrebna orodja za uvajanje rešitve ERP, predloge za modeliranje in vmesnike. Vsem metodologijam je skupna osnovna razdelitev na več faz, ki se odvijajo pred in med uvedbo in po uvedbi rešitve ERP, opis opravil in primeri delovanja. Metodologija pa mora opredeljevati tudi glavne mejnike v uvedbi rešitve ERP in njihove rezultate ter potrjevanje rezultatov projekta v projektu. Poleg tega so metodologije računalniško podprte, kar omogoča lažje delo projektni skupini. V nadaljevanju poglavja bomo opisali metodologijo ASAP, s pomočjo katere podjetje SAP uvaja rešitev mySAP ERP in metodologijo On Target, s pomočjo katere Microsoftovi partnerji uvajajo rešitev Microsoft Navision. 2.1 Metodologija ASAP Leta 1996 so v podjetju SAP razvili metodologijo, ki so jo poimenovali pospešeni SAP (v nadaljevanju metodologija ASAP – Accelerated SAP). Cilj metodologije ASAP je učinkovita izraba časa, povečanje kakovosti in učinkovita izraba virov (Larocca 2002). Kot navaja Khan (2002), so glavne značilnosti metodologije ASAP naslednje: optimiranje časa, kakovosti in virov, zagotavljanje najboljše poslovne prakse, zagotavljanje procesno usmerjenega projektnega zemljevida (ASAP-zemljevid), določanje stroškov uvajanja in načrt dela. Metodologija vsebuje poslovne procese, orodja, izobraževanje in podporo, zagotavlja pomoč med fazami uvedbe, vsebuje odgovore na vprašanja o stroških in času uvajanja ter kako zagotoviti kakovost, orodja in vire, vsebuje kontrolne sezname, vprašalnike in tehnične vodnike, podpira nadaljnje izboljšave. Uvedba rešitve mySAP ERP s pomočjo metodologije ASAP poteka v petih fazah in vključuje:  predprojektne aktivnosti (faza Priprava projekta),  projektne aktivnosti (faze: Poslovni načrt, Realizacija in Končne priprave)  ter aktivnosti po zaključku projekta (faza Zagon v živo in podpora). Vsaka faza je sestavljena iz skupine delovnih paketov, vsak delovni paket je sestavljen iz skupine opravil, vsako opravilo, definicija, procedura, rezultati in vloge so določene v dokumentaciji ASAP-zemljevida (Estaves idr. 2002). Faza Priprava projekta (angl. Project Preparation) se začne, ko se organizacija odloči, da bo uvedla rešitev mySAP ERP. Prva naloga organizacije je, da izbere projektno organizacijo za uvedbo izbrane rešitve. V fazi priprave projekta mora projektna organizacija določiti zelo jasne projektne cilje, podroben projektni načrt in pripraviti vodilna načela, ki ji bodo pomagala pri lažjih odločitvah v času samega uvajanja. Ker pa projektna organizacija na začetku ne pozna zmogljivosti rešitve mySAP ERP, sodeluje pri uvajanju tim Sapovih svetovalcev ali pooblaščeno svetovalno podjetje, ki ovrednoti potrebe in zahteve na osnovi vnaprej pripravljenih vprašalnikov s pomočjo orodja ASAP Project Estimator. Ko imamo določen obseg projekta, potrebne vire in izbran projektni tim, lahko začnemo projektne aktivnosti. Najprej izvedemo začetno izobraževanje za člane projektnega tima, da spoznajo arhitekturo, glavne mejnike uvajanja in terminologijo rešitve mySAP ERP. S pomočjo pridobljenega znanja projektni tim pripravi podroben načrt dela, ki obsega poslovne procesne diagrame, scenarije in modele poslovnih opravil. V fazi Poslovni načrt (angl. Business Blueprint) projektni tim na osnovi analiziranja poslovanja, intervjujev in principov najboljše prakse določi točne cilje in obseg dela ter do konca te faze pripravi dokument, ki je podroben načrt z vizualno predstavitvijo modela organizacije in vsebuje: obstoječo in bodočo funkcionalnost poslovnih procesov, obseg uvedbe, organizacijsko strukturo, odloženo funkcionalnost, praznine in morebitno tveganje, vrsto pristopa uvedbe ter drugo. V drugi fazi gredo člani projektnega tima in ključni uporabniki na drugo raven izobraževanja, da spoznajo poslovne procese in module rešitve mySAP ERP, ki bodo uvedena v organizaciji. V času, ko so projektni tim in ključni uporabniki na izobraževanju, tim Sapovih strokovnjakov prilagodi standardno rešitev mySAP ERP do 80 odstotkov predvidene funkcionalnosti. Po zaključku izobraževanja projektni tim prilagodi še preostanek funkcionalnosti rešitve mySAP ERP in opredeli podatkovne in sistemske vmesnike, določi programsko in strojno opremo ter namesti razvojno instanco rešitve mySAP ERP. 39 STERNAD IDR.: MODEL KRITIČNIH DEJAVNIKOV USPEHA UVAJANJA REŠITEV SAP IN NAVISION Faza Izvedba (angl. Realization) vključuje konfiguriranje, testiranje in analiziranje sistema mySAP ERP. Ti trije koraki se v testni instanci ponovijo tolikokrat, kolikokrat je potrebno. Najprej Sapovi svetovalci prilagodijo osnovni poslovni model, ki se zaključi s prvim integracijskim testom. Nato je treba dokončati prilagajanje celotnega poslovnega modela, kar ponavadi poteka v več zaporednih ciklih. Najprej prilagodimo izjeme in nepokrite zahteve, jih testiramo in nato analiziramo, če ustrezajo našim zahtevam. Če tem ne ustrezajo, postopek ponovimo. Nato sledi testiranje enot in celote. Pripraviti in testirati moramo tudi vmesnike, programe za pretvorbo in poročila. V tej fazi je treba tudi pretvoriti statične podatke (kot npr. podatki o kupcih, dobaviteljih) iz obstoječega sistema v skupno podatkovno bazo novega sistema ter izvesti tretjo raven izobraževanja, ki obsega zahtevnejše šolanje projektnega tima oziroma posameznikov (kot npr. administrator podatkovne baze nove rešitve). Faza Končne priprave (angl. Final Preparation) vključuje vse naloge, ki jih je treba opraviti, da bo prehod na rešitev mySAP ERP na dan zagona v živo čim lažji. Tako je treba nadaljevati s testiranjem enot, katerih funkcionalnost smo spremenili ali dodali. Poleg tega moramo pripraviti načrt za zagon v živo, ki vsebuje glavne aktivnosti in opravila, mejnike, zaporedje nalaganja podatkov, zadolžitve posameznih oseb ter relacije med podatki. Poleg tega je treba pred zagonom v živo izvesti izobraževanje končnih uporabnikov. Podjetje SAP priporoča metodo izobraževanja, pri kateri so izobraževanja najprej deležni ključni uporabniki v organizaciji, ki v fazi končnih priprav naučijo uporabljati rešitev mySAP ERP še druge uporabnike rešitve. V končni pripravi mora organizacija izvesti tudi stresni in integracijski test ter na osnovi tega dokončno nastaviti rešitev mySAP ERP oziroma izdelati načrt prilagoditev z vmesniki ter selitev preostalih podatkov. Ko projektni tim pripravi strategijo za zagon v živo, mora pred dnem zagona dobiti potrditev vodstvenega tima projekta ali uprave. V fazi Zagon v živo (angl. Go-live and Support) je treba preveriti zadolžitve: ali so vsi procesi podprti, je prenos podatkov končan, so vsi vmesniki narejeni, so preneseni podatki ovrednoteni, je bil celoten (integracijski) test uspešno izveden, so kritična poslovna poročila in obrazci pripravljeni itd. Poleg tega je treba zagotoviti operativno pomoč in podporo uporabnikom, ki mora biti na dan zagona v živo dobro organizirana. V primeru, da je potrebno kakršno koli naknadno prilagajanje poslovnih procesov, se to ureja s kontrolo sprememb, ki omogoča, da je mogoče vsak problem hitro izslediti in popraviti. Poleg tega je potrebo pripraviti avtorizacijske profile, kar pomeni, da je treba pripraviti uporabniška imena z določenimi pravicami za dostop, ki omogočajo in dovoljujejo uporabniku, da ima dostop samo do tistih akcij (ukazov), za katere je pooblaščen. Ko v peti fazi opravimo zadnji pregled in dobimo dokončno potrditev zaključka projekta, ga lahko poženemo v živo. Po zagonu v živo je treba načrtovati izboljšave rešitve, ki zajemajo prilagoditve in popravke rešitve mySAP ERP. 2.2 Metodologija On Target Rešitev ERP Microsoft Navision podjetja Microsoft uvajajo Microsoftovi partnerji po metodologiji, ki se imenuje metodologija uvedbe MBS (angl. Microsoft Business Solutions Implementation Methodology). Pogovorno se metodologija MBS uvedbe imenuje metodologija On Target, zato bomo v nadaljevanju prispevka uporabljali izraz metodologija On Target. Metodologijo On Target sestavlja naslednjih pet faz, ki zajemajo:  predprojektne aktivnosti (faza Analiza),  projektne aktivnosti (faze Oblikovanje, Razvoj in testiranje ter Namestitev)  in aktivnosti po končanem projektu (faza Aktivnosti po zagonu). V fazi Analiza (angl. Analysis) mora Microsoftov partner narediti podrobnejšo analizo procesov in na osnovi tega predlagati izboljšanje poslovnih procesov v organizaciji ali vpeljavo novih poslovnih procesov ter tako narediti poslovanje učinkovitejše, rentabilnejše in za končne uporabnike prijaznejše. Poleg tega mora Microsoftov partner dopolniti že narejeno analizo praznin/prileganja in določiti stopnjo potrebnega prilagajanja rešitve Microsoft Navision, tako da bo zadoščeno viziji organizacije in obsegu projekta uvajanja rešitve Microsoft Navision. Ta faza se zaključi z dokumentom funkcijskih zahtev, ki vsebuje: opis organizacijske strukture, obstoječo tehnološko arhitekturo, cilje projekta, vizijo, obseg uvajanja, opis trenutnih poslovnih procesov, opis bodočih poslovnih procesov, opisi vseh potrebnih prilagoditev in poročil. V fazi Oblikovanje (angl. Design) Microsoftov partner skupaj s projektnim timom določi, kako bo delovalo posamezno poročilo, obrazec, polje in funkcija. Aktivnosti v tej fazi vodijo v točnejšo oceno stroškov prilagoditev in tudi drugih elementov projekta. Rezultat teh aktivnosti je podroben opis delovanja posameznih funkcij, poročil in procesov. Tako se v fazi Oblikovanje izdela: podroben opis sistemskih prilagoditev, ki so opredeljene v dokumentu funkcijskih zahtev, podroben opis bodočih poslovnih procesov, ki so opisani v dokumentu praznin/prileganja, podroben opis vmesnikov, ki bodo povezovali obstoječe IS in rešitev ter podroben opis podatkov, ki jih je treba prenesti v rešitev. Rezultat te faze je odgovor na vprašanje, »kako« bo rešitev zagotavljala zahtevano funkcionalnost, in je zapisan v dveh dokumentih: v organizacijskem oblikovnem dokumentu (namenjenem končnim uporabnikom) in v programskem oblikovnem dokumentu (namenjenem razvojnemu timu). Oba dokumenta sta vodilo za pripravo izobraževalnega gradiva, pomoč, tehnično dokumentacijo, uporabniške priročnike itd. V fazi Razvoj in testiranje (angl. Development and Testing) morajo razvijalci (programerji) prilagoditi rešitev Microsoft Navision in po potrebi doprogramirati manjkajočo funkcionalnost rešitve. V tej fazi je treba tudi pripraviti testno in produkcijsko okolje ter zbrati podatke. Pri prilagajanju modulov metodologija On Target določa štiri vrste testov, in sicer teste posameznih enot, razvojni test, sistemski test 40 in končni test, ki se izvede v fazi Namestitev. Pri testiranju si pomagamo z dvema dokumentoma: s sistemskim testnim načrtom in testnimi primeri. Poleg tega je treba pripraviti tudi razvojni načrt, ki vsebuje strukturo izvedbe prilagoditev z mejniki in vsebuje: (1) strategijo s projektnim načrtom, začetnim sestankom, nastavitvami uporabniškega okolja, izobraževanjem ključnih uporabnikov in razvijalcev, (2) načrt, ki vsebuje: podatkovno strukturo, glavno funkcionalnost, potrebne vmesnike, opis drugih procesov ter razna poročila/dokumente ter (3) razvoj testne strategije. V fazi Namestitev (angl. Deployment) se s pomočjo kontrolnega seznama izvede končni test, s katerim se preverijo in potrdijo spremembe prvotne funkcionalnosti rešitve Microsoft Navision in vmesniki, ki jih potrebujemo za prenos podatkov iz drugih IS. Poleg tega je treba pripraviti varnostne kopije obstoječega sistema, zaključiti računovodsko obdobje, prenesti produkcijske podatke v rešitev, preveriti stanje odprtih transakcij in namestiti v prejšnjih fazah sprejeto podatkovno strukturo. Namestitev produkcijskega sistem zahteva namestitev produkcijskih podatkov, preverjanje končnega in začetnega stanja in pripravo na odobritev zagona v živo. V tej fazi je treba tudi izvesti izobraževanje končnih uporabnikov, odpraviti morebitne težave s strani varnosti sistema in zaključiti celotno dokumentacijo. Ob koncu te faze pripravi Microsoftov partner sestanek za upravo organizacije, na kateri se izvede končni test in preveri, ali so vsi cilji projekta uvedbe rešitve uresničeni. Če je uprava zadovoljna z rezultati, potem potrdi projekt in rešitev MS Navision je pripravljena na zagon. Faza Aktivnosti po zagonu (angl. On-going Operations) vsebuje aktivnosti, ki se nanašajo na vzdrževanje in podporo rešitve ter nadziranju bodočih potreb v organizaciji ob rasti in razvoju poslovanja. Tako mora Microsoftov partner ponuditi pomoč in dodatno izobraževanje uporabnikom, rešiti zahteve po spremembah in priskočiti na pomoč v primeru nesreč, nadzirati zmogljivosti sistema, vrednotiti uporabo sistema, vrednotiti uporabniško zadovoljstvo, vrednotiti poslovne rezultate s predvidenimi cilji itd. Po nekajmesečni uporabi rešitve MS Navision, Microsoftov partner pripravi sestanek z organizacijo, na katerem preverijo delovanje rešitve ter se začnejo pogovarjati o morebitnem začetku novega projekta. 3 Kritični dejavniki uvajanja celovitih informacijskih rešitev Uvedba kompleksnih rešitve ERP je zapletena naloga, ki se je morajo podjetja lotiti premišljeno in pri tem upoštevati metodo uvajanja, ki jo priporoča ponudnik rešitve ERP, hkrati pa morajo zagotoviti pogoje uvajanja, ki bodo omogočili uspešno in učinkovito uvedbo rešitve ERP. Zato tudi ne preseneča navedba, da je samo med 10 do 30 odstotkov rešitev ERP (Gartner Group; povzeto po Kosi 2004) uvedenih v predvidenem času, s predvidenimi stroški in v predvidenem obsegu. Zaradi velikega števila neuspešno uvedenih rešitev ERP so mnogi proučevali dejavnike, ki vplivajo na uspeh uvedbe rešitve ERP. KDU pri uvajanju rešitev ERP so torej dejavniki, ki usodno vplivajo na uspešnost in učinkovitost projektov uvedbe rešitve ERP. Objave v svetu izvedenih raziskav, ki so dosegljive v tiskanih in elektronskih virih, navajajo mnogo kritičnih dejavnikov uvajanja rešitev ERP. V predhodni raziskavi (Sternad in Bobek 2004) smo proučili devetnajst v svetu izvedenih raziskav o vlogi in pomenu KDU. V tabeli 1 je prikazanih štirinajst KDU, ki so bili v teh raziskavah omenjeni več kot petkrat, zaradi česar sklepamo, da sodijo med pomembnejše. Števila v oklepajih predstavljajo število avtorjev, ki so navedli KDU v svoji raziskavi. Med najpomembnejše dejavnike smo tako uvrstili (1 – najpomembnejši, 15 – najmanj pomemben): 1. KDU: vključitev in podpora uprave (16), 2. KDU: jasni cilji, strategija in obseg uvajanja rešitve (14), 3. KDU: organizacija projektnega tima in njegove kompetence (13), 4. KDU: izobraževanje uporabnikov rešitve ERP (13), 5. KDU: prenova poslovnih procesov (11), 6. KDU: menedžment sprememb (10), 7. KDU: komunikacija znotraj projektnega tima in med projektnim timom ter preostalimi v organizaciji (9), 8. KDU: vključitev in sodelovanje uporabnikov pri uvedbi ERP (9), 9. KDU: prenos podatkov iz starih rešitev ERP (9), 10. KDU: vključevanje zunanjih svetovalcev (8), 11. KDU: uporaba principov projektnega menedžmenta (8), 12. KDU: aktivna vloga sponzorja projekta (7), 13. KDU: izbira tehnološke arhitekture (7) in 14. KDU: minimalno prilagajanje rešitve ERP posebnostim organizacije (7). V tabeli navedene KDU smo podrobneje opisali drugje (Sternad in Bobek 2005). Poleg zgoraj omenjenih KDU, smo v literaturi zasledili tudi naslednje dejavnike: zastarelost obstoječih IS, metodologija uvajanja, učinkovita kontrola, sodelovanje med oddelki v organizaciji, urejanje izjem in merjenje zmogljivosti rešitve ERP, zagotovitev potrebnih virov itd. 4 Uvajanje celovitih informacijskih rešitev v Sloveniji V raziskavo o uvajanju rešitev ERP v Sloveniji smo zajeli 206 slovenskih organizacij, ki so v bližnji preteklosti uvedle rešitev SAP R/3 oziroma mySAP ERP, Microsoft Navision ali GEAC System 21. Podatke smo dobili od ponudnikov rešitev ERP oziroma z uradnih spletnih strani partnerjev ponudnikov rešitev ERP, ki le-te rešitve uvajajo. Pripravili smo spletni vprašalnik, ki smo ga preko elektronske pošte poslali vodjem IT, in sicer:  54 organizacijam, ki imajo uvedeno rešitev SAP R/3 oziroma mySAP ERP (26 %),  147 organizacijam, ki imajo uvedeno rešitev Microsoft Navision (72 %) in  5 organizacijam, ki imajo uvedeno rešitev GEAC System 21 (2 %). NG, ŠT. 1–2/2007 IZVIRNI ZNANSTVENI ČLANKI/ORIGINAL SCIENTIFIC PAPERS 41 Na vprašalnik je odgovorilo 48 vprašanih, kar je 23 odstotkov. Podrobnejšo razvrstitev rešitev ERP glede na velikost organizacij vidimo na sliki 1. Večina organizacij, ki so odgovorile na vprašalnik, spada po standardni klasifikaciji dejavnosti Republike Slovenije v dejavnost proizvodnje (52,1 odstotka, dejavnost D), sledijo organizacije, ki so razvrščene v dejavnost trgovina, popravila motornih vozil in izdelkov široke porabe (14,6 odstotka organizacij; dejavnost G) in dejavnost poslovanje z nepremičninami, najem in poslovne storitve (14,6 odstotka organizacij; dejavnost K) ter 18,7 odstotka organizacij, ki so se razvrstile v druge dejavnosti. Podrobnejša delitev rešitev ERP glede na dejavnost je predstavljena v tabeli 2. S slike 1 in iz tabele 2 lahko razberemo, da je bila večina rešitev SAP R/3 in mySAP ERP uvedena v velika podjetja proizvodne dejavnosti. Rešitev SAP R/3 in mySAP ERP je v večji meri uvedena v velike organizacije tudi v svetovnem merilu. Prav tako pa ne preseneča rezultat, da je pogosteje prisotna v proizvodnji dejavnosti, saj podjetje SAP ponuja vnaprej pripravljene industrijske rešitve (module). Ti moduli so narejeni po principu »najboljše prakse« in predstavljajo standard za posamezno industrijsko panogo, kot npr. industrijska rešitev za farmacijo. Rešitev Microsoft Navision je v svetu uvedena predvsem v srednje velika in majhna podjetja. Podobne rezultate lahko razberemo tudi s slike 1 in iz tabele 2 za slovenska podjetja. Večina organizacij, ki imajo uvedeno rešitev Microsoft Navision, se je uvrstila med manjše ali srednje velike organizacije trgovinske ali storitvene dejavnosti. Tabela 1: V zadnjih petih letih objavljeni članki na temo KDU pri uvajanju rešitev ERP [1] Aduri idr. (2002) [2] Akkermans in Helden (2002) [3] Al-Mashari idr. (2003) [4] Al-Sehali (2000) [5] Bancroft idr. (2001) [6] Bradford in Florin (2003) [7] Estaves idr. (2002) [8] Gattiker in CFPIM (2002) [9] Holland in Light (1999) [10] Jarrar idr. (2000) [11] Khan (2002) [12] Mabert idr. (2003) [13] Parr in Shanks (2000) [14] Reif (2001) [15] Skok in Legge (2002) [16] Somers in Nelson (2004) [17] Umble idr. (2002) [18] Welti (1999) [19] Zhang idr. (2000) Slika 1: Razvrstitev rešitev ERP glede na velikost podjetij Tabela 2: Prikaz rešitev ERP po dejavnostih STERNAD IDR.: MODEL KRITIČNIH DEJAVNIKOV USPEHA UVAJANJA REŠITEV SAP IN NAVISION 42 Nadalje nas je v vprašalniku zanimalo, po kateri metodi so organizacije uvedle rešitev ERP. Na voljo so bili trije odgovori, in sicer: metoda ponudnika rešitve ERP, lastna metoda ali drugo. Na vprašanje je odgovorilo 45 vprašanih, in sicer: po metodi ponudnika rešitve ERP je uvedlo rešitev 34 anketirancev (70,8 %), po lastni metodi je uvedlo rešitev ERP 8 anketirancev (16,7 %), preostali anketiranci pa so odgovorili z drugo (3 odgovori ali 6,3 %). Če nadalje razdelimo odgovore glede metode uvedbe na posamezne proučevane rešitve ERP, vidimo v tabeli 3, da je bilo po metodi ponudnika uvedenih 34 rešitev, in sicer: 2 po metodi ponudnika GEAC, 17 po metodi On Target in 15 po metodi ASAP. 3. KDU: organizacija projektnega tima in njegove kompetence (Mx = 5,81), 4. KDU: vključitev in sodelovanje uporabnikov (Mx = 6,42), 5. KDU: komunikacija med projektnim timom in preostalimi v organizaciji (Mx = 7,28), 6. KDU: komunikacija znotraj projektnega tima (Mx = 7,58), 7. KDU: izobraževanje končnih uporabnikov (Mx = 7,71), 8. KDU: prenova poslovnih procesov (Mx = 7,74), 9. KDU: vključevanje zunanjih svetovalcev (Mx = 8,47), 10. KDU: aktivna vloga sponzorja projekta (Mx = 8,84), 11. KDU: prenos podatkov iz starih rešitev v rešitev ERP (Mx = 9,13), 12. KDU: čim manj prilagajanja rešitve ERP posebnostim organizacije (Mx = 9,19), 13. KDU: uporaba principov projektnega menedžmenta (Mx = 9,87), 14. KDU: menedžment sprememb (Mx = 10,74), 15. KDU: izbira tehnološke arhitekture rešitve ERP (Mx = 11,63). V vprašalniku so anketirani lahko opredelili tudi druge za njih pomembne KDU. Med navedenimi so bili: razpoložljivost članov projektnega tima podjetja (delo poleg rednih obveznosti), integracija z drugimi rešitvami, zrelost podjetja kot celote, znanje svetovalcev, velika skrb in gospodarnost pri upravljanju s potrebnimi viri, usposobljenost in struktura kadrov, strošek uvedbe, možnost prilagajanja proizvodnih postopkov rešitvi ERP in obratno ter hitrost uvedbe. Rangiranje KDU po pomembnosti iz raziskave smo primerjali s pomembnostjo posameznih KDU iz raziskav v svetu (gl. tabela 1). Med obema rangiranjema KDU obstaja visoka statistično značilna povezanost (r = 0,745, P = 0,001), iz česar lahko potrdimo hipotezo, da ne obstajajo razlike med pomembnostjo KDU pri uvajanju rešitev ERP v Sloveniji in KDU pri uvajanju rešitev v tujini. Nadalje smo želeli preveriti hipotezo, da metoda uvedbe ne vpliva na pomembnost KDU pri uvajanju rešitve ERP. KDU smo z vidika metode uvajanja dobili tako, da smo pri obdelavi KDU upoštevali samo odgovor »Po metodi ponudnika« (tabela 3), kar je izbralo 34 oziroma 70,8 odstotka vprašanih. Najprej smo preverili, ali metoda uvedbe vpliva na pomembnost KDU. Od 34 odgovorov je range ocenilo 23 vprašanih, kjer smo s pomočjo aritmetične sredine izračunali, kateri KDU je za vprašane najpomembnejši. Rezultat obdelave je naslednji: 1. jasni cilji, strategija in obseg uvajanja rešitve (MX = 2,96), 2. vključitev in podpora uprave (MX = 5), 3. organizacija projektnega tima in njegove kompetence (MX = 5,39), 4. vključitev in sodelovanje uporabnikov (MX = 6,77), 5. komunikacija znotraj projektnega tima (MX = 7,64), 6. izobraževanje končnih uporabnikov (MX = 7,82), 7. komunikacija med projektnim timom in preostalimi v organizaciji (MX = 7,83), 8. prenova poslovnih procesov (MX = 8,27), 9. vključevanje zunanjih svetovalcev (MX = 8,67), 10. aktivna vloga sponzorja projekta (MX = 8,86), Tabela 3: Prikaz rešitev glede na metodo uvedbe Z raziskavo smo preverjali več hipotez, ki so bile postavljene na osnovi predhodnih raziskav (Sternad in Bobek 2006). V nadaljevanju se bomo omejili na štiri hipoteze in predstavili spoznanja v zvezi z njimi:  H1: Ne obstaja razlika med pomembnostjo KDU pri uvajanju rešitev ERP v Sloveniji in KDU pri uvajanju rešitev v tujini.  H2: Metoda uvedbe ne vpliva na pomembnost KDU pri uvajanju rešitve ERP.  H3: Obstajajo povezave med posameznimi KDU, ki so bili uvedeni po metodi ponudnika.  H4: Obstaja razlika v rangiranju KDU pri uvajanju rešitev po metodologiji On Target in metodologiji ASAP. Vse štiri hipoteze je raziskava potrdila. Preostali rezultati in razprave v zvezi z drugimi hipotezami so objavljeni drugje (Sternad in Bobek 2006). 4 Rezultati raziskave V raziskavi smo izhajali iz nabora KDU, ki so se po predhodnih analiza raziskav v svetu izkazale za pomembne. Navajamo jih v tabeli 1. Ker smo želeli izpostaviti pomembnost komunikacije znotraj projektnega tima in komunikacije med projektnim timom in organizacijo, smo se odločili, da KDU »Komunikacija znotraj projektnega tima in med projektnim timom ter preostalimi v organizaciji« razdelimo na dva dela, in sicer na dejavnik »Komunikacija znotraj projektnega tima« in na dejavnik »Komunikacija med projektnim timom in organizacijo« in tako preučujemo namesto štirinajst KDU petnajst KDU. V vprašalniku so anketirani petnajst KDU razvrstili, glede na pomembnost KDU-ja (1 – najpomembnejši, 15 – najmanj pomemben). Na ta del vprašalnika je odgovorilo 65 odstotkov vprašanih. Izračunali smo aritmetično sredino (Mx) in razvrstili KDU po pomembnosti: 1. KDU: jasni cilji, strategija in obseg uvajanja rešitve (Mx = 2,72), 2. KDU: vključitev in podpora uprave (Mx = 5,66), NG, ŠT. 1–2/2007 IZVIRNI ZNANSTVENI ČLANKI/ORIGINAL SCIENTIFIC PAPERS 43 11. prenos podatkov iz starih rešitev v rešitev ERP (MX = 9,05), 12. čim manj prilagajanja rešitve ERP posebnostim organizacije (MX = 9,23), 13. uporaba principov projektnega menedžmenta (MX = 10,2), 14. menedžment sprememb (MX = 11,4), 15. izbira tehnološke arhitekture rešitve ERP (MX = 12,4). Če primerjamo dobljeni rezultat rangiranja KDU tistih odgovorov, ki so uvedli rešitev ERP po metodi ponudnika z rezultati rangiranja KDU vseh vprašanih, vidimo da metoda uvajanja rešitve ERP na splošno ne spremeni pomembnosti posameznih KDU. Zamenjal se je le vrstni red KDU »Komunikacija znotraj projektnega tima« in KDU »Izobraževanje končnih uporabnikov«, drugi KDU so po pomembnosti ostali na istih mestih. Zato lahko potrdimo hipotezo, da metoda uvedbe ne vpliva na pomembnost posameznih KDU. S pomočjo tretje hipoteze smo želeli preveriti, ali obstaja korelacija med posameznimi KDU, če je bila v tabeli 3 izbrana možnost »Po metodi ponudnika«. Izračunali smo korelacijsko matriko, ki je prikazana v tabeli 4 in s katere lahko razberemo, da obstaja med posameznimi KDU visoka pozitivna korelacija, zmerna pozitivna korelacija in tudi zmerna negativna korelacija. Visoka pozitivna korelacija na 1-odstotnem nivoju obstaja:  med KDU Jasni cilji, strategija in obseg uvajanja rešitve ter KDU Vključevanje in podpora uprave (r = 0,843) in  med KDU Jasni cilji, strategija in obseg uvajanja rešitev ter KDU Organizacija projektnega tima in njegove kompetence (r = 0,706). Zmerna pozitivna korelacija na 1-odstotnem nivoju obstaja:  med KDU Vključitev in podpora uprave ter KDU Organizacija projektnega tima in njegove kompetence (r = 0,631),  med KDU Komunikacija znotraj projektnega tima ter KDU Komunikacija med projektnim timom in preostalimi v organizaciji (r = 0,616),  med KDU Vključitev in sodelovanje uporabnikov ter KDU Izbira tehnološke arhitekture rešitve ERP (r = 0,576) in  med KDU Organizacija projektnega tima in njegove kompetence ter KDU Komunikacija znotraj projektnega tima (r = 0,57). Zmerna pozitivna korelacija na 5-odstotnem nivoju obstaja:  med KDU Vključitev in podpora uprave ter KDU Aktivna vloga sponzorja projekta (r = 0,478),  med KDU Vključitev in podpora uprave ter KDU Menedžment sprememb (r = 0,449),  med KDU Izobraževanje končnih uporabnikov ter KDU Prenos podatkov iz starih rešitev v rešitev ERP (r = 0,443),  med KDU Jasni cilji, strategija in obseg uvajanja rešitve ter KDU Menedžment sprememb (r = 0,436),  med KDU Vključitev in podpora uprave ter KDU Uporaba principov projektnega menedžmenta (r = 0,435),  med KDU Prenova poslovnih procesov ter KDU Prenos podatkov iz starih rešitev v rešitev ERP (r = 0,431) in  med KDU Organizacija projektnega tima in njegove kompetence ter KDU Uporaba principov projektnega menedžmenta (r = 0,426). ** Korelacija je pomembna na stopnji 0,01 (2-delna) – Pearsonova korelacija. * Korelacija je pomembna na stopnji 0,05 (2-delna) – Pearsonova korelacija. Tabela 4: Korelacijska tabela KDU glede na rang, če je bila rešitev ERP uvedena po metodi ponudnika R1 Jasni cilji, strategija in obseg uvajanja rešitve R2 Vključitev in podpora uprave R3 Aktivna vloga sponzorja projekta R4 Organizacija projektnega tima in njegove kompetence R5 Uporaba principov projektnega menedžmenta R6 Komunikacija znotraj projektnega tima R7 Komunikacija med projektnim timom in preostalimi v organizaciji R8 Vključevanje zunanjih svetovalcev R9 Vključitev in sodelovanje uporabnikov R10 Izobraževanje končnih uporabnikov R11 Menedžment sprememb R12 Prenova poslovnih procesov R13 Izbira tehnološke arhitekture rešitve ERP R14 Čim manj prilagajanja rešitve ERP posebnostim organizacije R15 Prenos podatkov iz starih rešitev v rešitev ERP STERNAD IDR.: MODEL KRITIČNIH DEJAVNIKOV USPEHA UVAJANJA REŠITEV SAP IN NAVISION 44 Obstaja tudi zmerna negativna korelacija na 5-odstotnem nivoju, in sicer:  med KDU Uporaba principov projektnega menedžmenta ter KDU Izobraževanje končnih uporabnikov (r = – 0,491),  med KDU Organizacija projektnega tima in njegove kompetence ter KDU Prenos podatkov iz starih rešitev v rešitev ERP (r = –0,477),  med KDU Komunikacija znotraj projektnega tima ter KDU Čim manj prilagajanja rešitve ERP posebnostim organizacije (r = –0,448) in  med KDU Organizacija projektnega tima in njegove kompetence ter KDU Izobraževanje končnih uporabnikov (r = –0,426). Tako lahko potrdimo hipotezo, da obstajajo tako pozitivne kot negativne povezave med posameznimi KDU, če je bila rešitev uvedena po metodi ponudnika. V zadnjem delu raziskave pa smo želeli preveriti našo hipotezo, da se rangiranje KDU razlikuje glede na izbrano metodo ponudnika. Od 23 odgovorov se 11 odgovorov nanaša na rešitev Navision, ki se uvaja po metodi On Target, 10 odgovorov na rešitev SAP, ki se uvaja po metodi ASAP, in 2 odgovora na rešitve GEAC. Ker je v Sloveniji samo 5 uvedb rešitve GEAC System 21, pri tem smo rezultate dobili iz treh organizacij, jih v podrobnejšo analizo KDU z vidika posameznih metod uvedbe nismo zajeli. Rezultati rangiranja KDU glede na metodo uvajanja On Target in metodologijo ASAP so prikazani v tabeli 5. Iz tabele 5 lahko tako razberemo, da so v obeh metodah uvedbe na prvih treh mestih enaki KDU, in sicer: Jasni cilji, strategija in obseg uvajanja, Vključitev in podpora uprave ter Organizacija projektnega tima in njegove kompetence. Največjo spremembo v rangiranju doseže KDU Aktivna vloga sponzorja projekta. Pri metodologiji ASAP je ta KDU na 4. mestu, medtem ko je pri metodologiji On Target na 10. mestu. Ta razlika je verjetno odraz tega, da rešitev Microsoft Navision uvajajo majhne in srednje velike organizacije (v vključenih odgovorih 6 majhnih organizacij ter 5 srednje velikih in velikih organizacij), medtem ko rešitev SAP uvajajo srednje velike in velike organizacije (vse organizacije, ki so bile vključene v raziskavo, so srednje velike ali velike organizacije). Tako predvidevamo, da v majhnih podjetjih direktor (uprava) prevzame vlogo sponzorja projekta in zaradi tega se ne uvršča med najpomembnejše KDU. Večje razlike med rangi obeh metodologij se pojavijo še pri KDU: Izobraževanje končnih uporabnikov (5. mesto Microsoft Navision, 10. mesto SAP), Vključevanje zunanjih svetovalcev (12. mesto Microsoft Navision, 7. mesto SAP), Komunikacija med projektnim timom in preostalimi v organizaciji (9. mesto Microsoft Navision, 5. mesto SAP), Prenos podatkov iz starih rešitev v rešitev ERP (8. mesto Microsoft Navision, 13. mesto SAP). Zanimivo je tudi, da pri rešitvi Microsoft Navision dajejo večjo vlogo vključitvi in sodelovanju uporabnikov (rang 4) in izobraževanju končnih uporabnikov (rang 5), medtem ko se pri rešitvi SAP KDU Vključitev in sodelovanje uporabnikov pojavi na 6. mestu, Izobraževanje končnih uporabnikov pa šele na 10. mestu. Tako lahko potrdimo hipotezo, da obstajajo razlike med rangiranjem KDU pri uvajanju rešitev po metodologiji On Target in metodologiji ASAP. V tabeli 4 vidimo povezave med posameznimi KDU, če je bila rešitev ERP uvedena po metodi ponudnika. Na osnovi obdelanih podatkov smo želeli preveriti, ali obstajajo povezave tudi med posameznimi KDU za rešitev Microsoft Navision (metodologija On Target) in za rešitev mySAP ERP in SAP R/ 3 (metodologija ASAP). Rezultate povezav vidimo v tabeli 6. Prvi del tabele 6 prikazuje korelacijsko tabelo KDU za metodo On Target. Vidimo, da med KDU Jasni cilji, strategija in obseg uvajanja rešitve ERP in KDU Vključitev in podpora uprave obstaja zelo visoka pozitivna statistična povezanost (r = 0,906) na 1-odstotnem nivoju. Prav tako obstaja visoka statistična povezanost med KDU Organizacija projektnega tima in njegove kompetence ter KDU Komunikacija znotraj projektnega tima (r = 0,797). Med naslednjimi KDU pa obstaja pozitivna zmerna statistična povezanost na 5- odstotnem nivoju:  med KDU Jasni cilji, strategija in obseg uvajanja ter KDU Organizacija projektnega tima in njegove kompetence (r = 0,645),  med KDU Vključitev in podpora uprave ter KDU Uporaba principov projektnega menedžmenta (r = 0,625), NG, ŠT. 1–2/2007 IZVIRNI ZNANSTVENI ČLANKI/ORIGINAL SCIENTIFIC PAPERS Tabela 5: Prikazuje pomembnost posameznih KDU glede na metodo uvajanja On Target in ASAP MXN, MXS – aritmetične sredine za posamezne rešitve 45  med KDU Vključitev in podpora uprave ter KDU Menedžmentom sprememb (r = 0,671),  med KDU Komunikacija znotraj projektnega tima in KDU Komunikacija med projektnim timom in preostalimi v organizaciji (r = 0,658),  med KDU Vključitev in sodelovanje uporabnikov ter KDU Prenova poslovnih procesov (r = 0,638). Drugi del tabele 6 prikazuje korelacijsko tabelo KDU za metodologijo ASAP. Iz tabele lahko razberemo, da obstajata tako visoka pozitivna kot visoka negativna povezanost med posameznimi KDU. Visoka pozitivna statistična povezanost na 1-odstotnem nivoju obstaja med KDU Jasni cilji, strategija in obseg uvajanja rešitve ter KDU Organizacija projektnega tima in njegove kompetence (r = 0,775). Prav tako obstaja tudi visoka negativna statistična povezanost na 1-odstotnem nivoju med KDU:  med KDU Jasni cilji, strategija in obseg uvajanja rešitve ter KDU Izbira tehnološke arhitekture rešitve ERP (r = –0,783),  med KDU Aktivna vloga sponzorja projekta in KDU Prenos podatkov iz starih rešitev v rešitev ERP (r = –0,889),  med KDU Organizacija projektnega tima in njegove kompetence ter KDU Prenova poslovnih procesov (r = – 0,809),  med KDU Organizacija projektnega tima in njegove kompetence in KDU Izbira tehnološke arhitekture rešitve ERP (r = –0,807),  med KDU Vključevanje zunanjih svetovalcev in KDU Menedžment sprememb (r = –0,813). Obstaja tudi visoka pozitivna korelacija na 5-odstotnem nivoju:  med KDU Vključitev in podpora uprave ter KDU Organizacija projektnega tima in njegove kompetence (r = 0,729),  med KDU Komunikacija znotraj projektnega tima in KDU Menedžment sprememb (r = 0,749),  med KDU Prenova poslovnih procesov in KDU Izbira tehnološke arhitekture rešitve ERP (r = 0,78),  med KDU Prenova poslovnih procesov ter KDU Prenos podatkov iz starih rešitev v rešitev ERP (r = 0,727), STERNAD IDR.: MODEL KRITIČNIH DEJAVNIKOV USPEHA UVAJANJA REŠITEV SAP IN NAVISION ** Korelacija je pomembna na stopnji 0,01 (2-delna) – Pearsonova korelacija. * Korelacija je pomembna na stopnji 0,05 (2-delna) – Pearsonova korelacija. R1 Jasni cilji, strategija in obseg uvajanja rešitve R2 Vključitev in podpora uprave R3 Aktivna vloga sponzorja projekta R4 Organizacija projektnega tima in njegove kompetence R5 Uporaba principov projektnega menedžmenta R6 Komunikacija znotraj projektnega tima R7 Komunikacija med projektnim timom in preostalimi v organizaciji R8 Vključevanje zunanjih svetovalcev R9 Vključitev in sodelovanje uporabnikov R10 Izobraževanje končnih uporabnikov R11 Menedžment sprememb R12 Prenova poslovnih procesov R13 Izbira tehnološke arhitekture rešitve ERP R14 Čim manj prilagajanja rešitve ERP posebnostim organizacije R15 Prenos podatkov iz starih rešitev v rešitev ERP Tabela 6: Korelacijska tabela KDU glede na rang, če je bila rešitev ERP uvedena po metodi On Target in po metodi ASAP 46 Obstaja pa tudi visoka negativna korelacija na 5- odstotnem nivoju, in sicer:  med KDU Jasni cilji, strategija in obseg uvajanja rešitve in KDU Izbira tehnološke arhitekture rešitve ERP (r = –0,783),  med KDU Vključitev in podpora uprave in KDU Prenova poslovnih procesov (r = –0,795),  med KDU Vključitev in podpora uprave in KDU Izbira tehnološke arhitekture rešitve ERP (r = –0,725),  med KDU Aktivna vloga sponzorja projekta in KDU Prenova poslovnega procesa (r = –0,889),  med KDU Uporaba principov projektnega menedžmenta in KDU Prenos podatkov iz starih rešitev v rešitev ERP (r = –0,779),  med KDU Komunikacija znotraj projektnega tima in KDU Vključitev in sodelovanje uporabnikov (r = –0,714),  med KDU Vključitev in sodelovanje uporabnikov in KDU Menedžment sprememb (r = –0,727). 5 Sklep Zaradi velikega števila neuspešno uvedenih rešitev ERP kritični dejavniki uspeha (KDU) pri uvajanju rešitev ERP pridobivajo na pomenu. KDU pri uvajanju rešitve ERP so dejavniki, ki usodno vplivajo na uspešnost in učinkovitost projektov uvedbe rešitve ERP. Objave v svetu izvedenih raziskav, ki so dosegljive v tiskanih in elektronskih virih, navajajo mnogo kritičnih dejavnikov uvajanja rešitev ERP. Na osnovi devetnajstih v svetu izvedenih raziskav smo ocenili, da štirinajst KDU, ki so bili v teh raziskavah omenjeni več kot petkrat, sodijo med pomembnejše. V raziskavi smo izhajali iz tega seznama KDU in želeli preveriti: ali metoda uvedbe vpliva na pomembnost KDU pri uvajanju rešitve ERP, ali obstajajo povezave med posameznimi KDU, ki so bili uvedeni po metodi ponudnika in ali obstajajo razlike v rangiranju KDU pri uvajanju rešitev Microsoft Navision in mySAP ERP po metodologijah ponudnikov teh dveh rešitev. Na osnovi izvedene raziskave v slovenskih podjetjih, ki imajo uvedeno rešitev SAP R/3 in mySAP ERP, Microsoft Navision in GEAC System 21 smo ugotovili, da obstaja visoka statistična povezanost med rangiranjem KDU slovenskih organizacij in rangiranjem KDU v raziskavah v svetu. Tako lahko potrdimo hipotezo, da ne obstajajo statistično pomembne razlike med pomembnostjo KDU pri uvajanju rešitev ERP v tuji strokovni literaturi in KDU pri uvajanju rešitev ERP v slovenskih organizacijah. Na osnovi raziskave smo potrdili tudi drugo hipotezo, da metoda uvedbe ne vpliva na pomembnost KDU pri uvajanju rešitve ERP. Izračunali smo korelacijsko matriko KDU, kjer so organizacije uvedle rešitev ERP po metodi ponudnika in ugotovili, da obstaja med dvema KDU visoka pozitivna statistična korelacija na 1-odstotnem nivoju, da pa obstaja kar nekaj zmernih pozitivnih korelacij in povezav med posameznimi KDU, s čimer smo potrdili tudi tretjo predpostavko, ki pravi, da obstajajo korelacije med posameznimi KDU rešitve ERP, ki so bili uvedeni po metodi ponudnika rešitve ERP. Da smo lahko potrdili še četrto hipotezo, smo izračunali aritmetične sredine KDU za rešitev Microsoft Navision in za rešitev mySAP ERP in ugotovili, da so pri obeh rešitvah na prvih treh mestih isti KDU, medtem ko se pomembnost drugih KDU med obema rešitvama precej razlikuje. Literatura 1. Aduri, R., Lin, W., Ma, Y. (2003). The price tag of Enterprise Resource Planning (ERP) system implementation failure: version 2.0. Dosegljivo na: http://erp.ittoolbox.com/ documents/document.asp?i=2374 (29. 8. 2003). 2. Akkermans, H., Helden, K. (2002). Vicious and virtuous cycles in ERP implementation: a case study of interrelations between CSF, European Journal of Information Systems, II, 35–46. 3. Al-Mashari M., Al-Mudimigh, A., Zairi, M. (2003). Enterprise resource planning: A taxonomy of critical factors, European Journal of Operational Research, 146 (2), 352–364. 4. Al-Sehali, S. (2000). The factors that affect the implementation of enterprise resource planning (ERP) in the international Arab gulf states and United states organizations with special emphasis on SAP software, dissertation, University of Northern Iowa. 5. Bancroft, N., Seip, H., Sprengel, A. (1998). Implementing SAP R/3, 2nd edition, Manning Pubilcations Co, Greenwich. 6. Bradford, M., Florin, J. (2003). Examining the role of innovation diffusion factors on the implementation success of enterprise resource planning systems, International Journal of Accounting Information Systems, 4 (3), 205–225. 7. Estaves J., Pastor J. A., Casanovas J. (2002). Using the Partial Least Squares (PLS) method to establish CSF interdependence in ERP implementation projects. Ittoolbox. Dosegljivo na: http://erp.ittoolbox.com/ documents/document.asp?i=2321 (15. 9. 2003). 8. Gattiker, T., CFPIM. (2002). Anatomy of an ERP implementation gone awry, Production and Inventory Management Journal, 43, 96–105. 9. Holland, C. P., Light, B. (1999). A critical success factors model for ERP implementation, IEEE Software, 5–6, 30–35. 10. Jarrar, Y. F., Al-Mudimigh, A., Zairi, M. (2000). ERP implementation critical success factors – the role and impact of business process management, ICMIT, 2, 122–127. 11. Khan, A. (2002). Implementing SAP with an ASAP methodology focus, Writers Club Press, San Jose. 12. Kosi, M. (2004). Microsoft Business Solutions – Navision – ERP sistem za majhna in srednje velika podjetja. Dosegljivo na: http://epf-oi.uni-mb.si/clani/ bobek/Informatika (10. 12. 2004). 13. Larocca, D. (2002). Naučite se sami SAP R/3 v 24. urah. Slovenj Gradec: D. Kuster [samozal.]. 14. Laudon, K. C., Laudon, J. P. (2000). Management information systems: organization and technology in the networked enterprise: sixth edition. London etc.: Prentice-Hall. 15. Mabert, V. A., Soni, A., Venkataramanan, M. A. (2003). Enterprise resource planning: Managing the implementation process, European Journal f Operational Research, 146(2), 302–314. NG, ŠT. 1–2/2007 IZVIRNI ZNANSTVENI ČLANKI/ORIGINAL SCIENTIFIC PAPERS 47 STERNAD IDR.: MODEL KRITIČNIH DEJAVNIKOV USPEHA UVAJANJA REŠITEV SAP IN NAVISION 16. O’Leary, D. E. (2000). Enterprise resource planning system: Systems, life cycle, electronic commerce and risk. Cambridge university press, USA. 17. Parr, A., Shanks, G. (2000). A model of ERP project implementation, Journal of Information Technology, 15, 289–303. 18. Reif, H. (2001). Complementing Traditional Information Systems Implementation Methodologies for Successful ERP System Implementations, dissertation, University of Virginia. 19. Skok, W., Legge, M. (2002). Evaluating enterprise resource planning (ERP) systems using an interpretive approach, Knowledge and Process Management, 9(2), 72–82. 20. Somers T. M., Nelson, K. G. (2004). A taxonomy of players and activities across the ERP project life cycle, Information & Management, 41(3), 257–278. 21. Sternad, S., Bobek, S. (2004). ERP solution implementation critical success factors: what does matter and what does not, Acta systemica (Lasker, G.E., Ed.) Windsor (Ont., Can.) 2004, pp. 27–31, International Institute for Advanced Studies in Systems Reserch and Cybernetics. 22. Sternad, S., Bobek, S. (2005). Critical success factors in ERP solution implementation: management challenges, Challenges and prospects/ International Conference on Information and Communication Technology in Management, Melaka 2005, pp. 132–133, Multimedia University, cop. 23. Sternad, S., Bobek, S. (2006). Management issues in ERP implementations: CSF’s in Slovenian organizations, Cybernetics and systems 2006 (Trappl, R., Ed.), Vienna 2006, pp. 460–465, Austrian Society for Cybernetic Studies. 24. Umble, E. J., Haft, R. R., Umble, M. M. (2002). Enterprise resource planning: Implementation procedures and CSF, European Journal of Operational Research, 146(2), 241–257. 25.Welti, N. (1999). Successful SAP R/3 implementation: Practical management of ERP projects, Addison-Wesley, England. 26. Zhang, L. idr. (2002). Critical Success Factors of Enterprise Resource Planning Systems Implementation Success in China, HICSS’03.