Embed Size (px)
Citation preview
REPUBLIKA SLOVENIJA UNIVERZA V MARIBORU
EKONOMSKO-POSLOVNA FAKULTETA
MAGISTRSKO DELO
PRIMERJALNA ANALIZA KRITIČNIH DEJAVNIKOV USPEHA UVAJANJA CELOVITIH INFORMACIJSKIH REŠITEV Z VIDIKA FAZ IN Z
VIDIKA METOD UVAJANJA
Kandidatka: Simona STERNAD, profesorica računalništva z matematiko, rojena leta 1974 v kraju Celje, zaposlena na Ekonomsko-poslovni fakulteti Maribor kot asistentka za poslovno informatiko. Absolventka na smeri Poslovna informatika. Tema je bila odobrena na seji senata EPF, dne 18. 2. 2005, z delovnima naslovom: Primerjalna analiza kritičnih dejavnikov uspeha uvajanja
celovitih informacijskih rešitev z vidika faz in z vidika metod uvajanja.
Mentor: prof. dr. Samo BOBEK, redni profesor
Zahvala Mentorju prof. dr. Samu Bobeku se zahvaljujem za strokovno pomoč in predloge. Zahvaljujem se podjetjem SAP Slovenija d.o.o., ProNet d.o.o. in LinkPro d.o.o., ki so mi priskočila na pomoč pri pridobivanju elektronskih naslovov podjetij z uvedenimi rešitvami ERP. Zahvaljujem se podjetjem, ki so si vzela čas in izpolnila vprašalnik o kritičnih dejavnikih uspeha uvajanja rešitev ERP ter mi tako omogočila, da sem lahko izvedla raziskavo o kritičnih dejavnikih uspeha uvajanja rešitev ERP v slovenskih organizacijah.
1
KAZALO VSEBINE
1 Uvod _________________________________________________________________ 6 1.1 Opredelitev področja in opis problema RAZISKAVE __________________________ 6 1.2 Namen, cilji in naloga raziskave ____________________________________________ 7 1.3 Predpostavke in omejitve raziskave _________________________________________ 8 1.4 Predvidene metode raziskovanja ___________________________________________ 9
2 Celovite informacijske rešitve ____________________________________________ 10 2.1 Opredelitev celovitih informacijskih rešitev _________________________________ 10 2.2 Razvoj celovitih informacijskih rešitev _____________________________________ 11 2.3 Koncepti in zgradba celovitih informacijskih rešitev __________________________ 16 2.4 Življenjski cikel celovitih informacijskih rešitev _____________________________ 18 2.5 Funkcijsko usmerjene celovite informacijske rešitve __________________________ 23
3 Uvajanje celovitih informacijskih rešitev ___________________________________ 27 3.1 Potek uvajanja celovitih informacijskih rešitev ______________________________ 27 3.2 Strategije uvajanja celovitih informacijskih rešitev ___________________________ 29
3.2.1 Hitra implementacija __________________________________________________________ 29 3.2.2 Druge strategije ______________________________________________________________ 34
3.3 Projektna organizacija __________________________________________________ 35 3.3.1 Zgradba projektne organizacije __________________________________________________ 36 3.3.2 Člani projektne organizacije in njihove vloge _______________________________________ 38
4 Izbira in nakup celovitih informacijskih rešitev ______________________________ 43 4.1 Razlogi za posodabljanje in prenovo informacijskega sistema __________________ 43 4.2 Analiza poslovnih procesov _______________________________________________ 49
4.2.1 ARIS ______________________________________________________________________ 51 4.3 Pristopi k izbiri celovite informacijske rešitve _______________________________ 55
4.3.1 Pristop podrobnih zahtev _______________________________________________________ 57 4.3.2 Pristop ključnih zahtev ________________________________________________________ 58 4.3.3 Pristop dokaz koncepta ________________________________________________________ 58
4.4 Ocenitev celovitih informacijskih rešitev ____________________________________ 59 4.4.1 Standard 9126 – Ocenjevanje kakovosti v uporabi ___________________________________ 60 4.4.2 Metrike za ocenjevanje kakovosti v uporabi s strani končnega uporabnika ________________ 61
4.5 Ocena investicije ________________________________________________________ 69 4.6 Management nakupa celovitih informacijskih rešitev _________________________ 72
5 Metode uvajanja celovitih informacijskih rešitev _____________________________ 74 5.1 Pristopi k uvajanju celovitih informacijskih rešitev ___________________________ 75
5.1.1 Pristop velikega poka _________________________________________________________ 75 5.1.2 Fazni pristop ________________________________________________________________ 76 5.1.3 Vzporedni pristop ____________________________________________________________ 77 5.1.4 Procesni pristop ______________________________________________________________ 77 5.1.5 Hibridni pristop ______________________________________________________________ 77
2
5.2 Metodologija ASAP _____________________________________________________ 77 5.2.1 Uvod ______________________________________________________________________ 77 5.2.2 Metodologija ASAP __________________________________________________________ 79 5.2.3 Priprava projekta _____________________________________________________________ 83 5.2.4 Poslovni načrt _______________________________________________________________ 84 5.2.5 Izvedba ____________________________________________________________________ 84 5.2.6 Končne priprave _____________________________________________________________ 85 5.2.7 Zagon v živo ________________________________________________________________ 86
5.3 Metodologija On Target _________________________________________________ 87 5.3.1 Uvod ______________________________________________________________________ 87 5.3.2 Implementacijska metodologija – On Target _______________________________________ 90 5.3.3 Analiza ____________________________________________________________________ 91 5.3.4 Oblikovanje _________________________________________________________________ 92 5.3.5 Razvoj in testiranje ___________________________________________________________ 93 5.3.6 Namestitev__________________________________________________________________ 95 5.3.7 Aktivnosti po zagonu v živo ____________________________________________________ 95
5.4 Primerjalna analiza metodologij ASAP in On Target _________________________ 96 6 Kritični dejavniki uspeha pri uvajanju celovitih informacijskih rešitev ___________ 98
6.1 Analiza kritičnih dejavnikov uspeha uvajanja celovitih informacijskih rešitev ____ 98 6.1.1 Vključitev in podpora uprave __________________________________________________ 100 6.1.2 Jasni cilji, strategija in obseg uvajanja rešitve ______________________________________ 100 6.1.3 Organizacija projektnega tima in njegove kompetence _______________________________ 101 6.1.4 Izobraževanje uporabnikov rešitve ERP __________________________________________ 102 6.1.5 Prenova poslovnih procesov ___________________________________________________ 103 6.1.6 Management sprememb ______________________________________________________ 103 6.1.7 Komunikacija znotraj projektnega tima ter med projektnim timom in ostalimi v organizaciji _ 104 6.1.8 Vključitev in sodelovanje uporabnikov pri uvedbi rešitve ERP ________________________ 104 6.1.9 Prenos podatkov iz starih rešitev ERP____________________________________________ 105 6.1.10 Vključevanje zunanjih svetovalcev ___________________________________________ 105 6.1.11 Uporaba principov projektnega managementa ___________________________________ 106 6.1.12 Aktivna vloga sponzorja projekta _____________________________________________ 107 6.1.13 Izbira primerne rešitve ERP _________________________________________________ 107 6.1.14 Minimalno prilagajanje rešitve ERP posebnostim organizacije ______________________ 108
6.2 Analiza kritičnih dejavnikov uspeha informacijskih projektov ________________ 108 6.3 Raziskovalni model kritičnih dejavnikov uspeha ____________________________ 111
6.3.1 Kritični dejavniki uspeha z vidika faz uvajanja _____________________________________ 112 6.3.2 Kritični dejavniki uspeha z vidika metodologij _____________________________________ 113
6.4 Raziskava kritičnih dejavnikov uspeha ____________________________________ 115 6.4.1 Priprava vprašalnika _________________________________________________________ 116 6.4.2 Zbiranje podatkov ___________________________________________________________ 117 6.4.3 Obdelava podatkov __________________________________________________________ 118
6.5 Analiza kritičnih dejavnikov uspeha ______________________________________ 128 6.5.1 Analiza kritičnih dejavnikov uspeha z vidika faz uvajanja ____________________________ 130 6.5.2 Analiza kritičnih dejavnikov uspeha z vidika metodologij uvajanja _____________________ 134 6.5.3 Analiza kritičnih dejavnikov uspeha z vidika pristopa uvajanja ________________________ 139
7 Sklep _______________________________________________________________ 143
Literatura _______________________________________________________________ 144
Seznam uporabljenih kratic _________________________________________________ 150
Kazalo slik _______________________________________________________________ 151
Kazalo tabel ______________________________________________________________ 152
Kazalo grafikonov _________________________________________________________ 153
3
Priloga A ________________________________________________________________ 154
Priloga B ________________________________________________________________ 155
Priloga C ________________________________________________________________ 158
Priloga D ________________________________________________________________ 159
Priloga E ________________________________________________________________ 162
Priloga F ________________________________________________________________ 163
Priloga G ________________________________________________________________ 164
Priloga H ________________________________________________________________ 165
DELOVNI ŽIVLJENJEPIS ________________________________________________ 166
4
POVZETEK Konkurenčnost, hitre spremembe v poslovanju, zastareli obstoječi informacijski sistemi, itd. je samo nekaj izmed številnih razlogov, zakaj se v zadnjem času vse več organizacij odloča za zamenjavo obstoječih informacijskih sistemov predvsem s celovitimi informacijskimi rešitvami. Organizacije se raje odločijo za nakup in uvedbo rešitev ERP kot pa za razvoj programske opreme na ključ zaradi razlogov, kot so: nižji stroški razvoja rešitve, krajši čas trajanja projekta uvedbe IS kot tudi zaradi razloga, da jim je zagotovljen določen obseg funkcionalnosti. Danes večina organizacij pri uvajanju rešitev ERP uporablja hitro strategijo, saj organizacija nima časa, da bi spreminjala rešitev ERP in mora zato prilagoditi svoje poslovne procese rešitvi ERP. Ponudniki rešitev ERP zato zahtevajo od organizacij, da prenovijo poslovne procese tako, da bodo združljivi s poslovnimi procesi rešitve ERP. Zaradi zgoraj omenjenega razloga mora organizacija izbrati tako rešitev ERP, ki se kar najbolje prilega njenim poslovnim procesom, zagotavlja funkcionalnost v organizaciji, podpira spreminjajoče poslovno okolje, jo je enostavno integrirati z ostalimi informacijskimi sistemi, nudi pomoč ponudnika rešitve ERP pri uvedbi rešitve, itd. Veliko rešitev ERP ni uvedenih v predvidenem času, s predvidenimi stroški in/ali v predvidenem obsegu zaradi razlogov, ki lahko tičijo v procesu izbire rešitve ERP in/ali procesu uvajanja rešitev ERP. Organizacije uvajajo rešitve ERP dvofazno, zato je tudi raziskava zgrajena iz dveh delov. V prvem delu se mora organizacija osredotočiti na postopek izbire rešitve ERP in nakupa rešitve ERP. Kot eden izmed pomembnih dejavnikov pri izbiri rešitve ERP so tudi končni uporabniki. Vrednotenje rešitve ERP s strani končnih uporabnikov lahko izvedemo s pomočjo metrik za ocenjevanje kakovosti proizvoda (standard 9126), zato smo v magistrski nalogi predstavili primer metrik za ocenjevanje kakovosti v uporabi s strani končnega uporabnika. Ko pa organizacija izbere rešitev ERP, se začne druga faza, in sicer uvajanje rešitve ERP. V okviru uvajanja rešitev ERP smo opredelili splošne pristope uvajanja rešitev ERP, kot tudi metodologiji ASAP in On Target ter izdelali primerjalno analizo metodologij. V zadnjem delu magistrske naloge smo na osnovi literature (knjig in »online« baz) opredelili najpomembnejše kritične dejavnike uspeha (KDU) rešitev ERP ter izdelali raziskovalni model KDU z vidika faz uvajanja in raziskovalni model KDU znotraj posameznih metodologij. Modela KDU smo verificirali s pomočjo raziskave na izbranem vzorcu, ki je zajemal slovenske organizacije, ki imajo uvedeno rešitev ERP. Na osnovi rezultatov raziskave smo naredili analizo KDU z vidika faz uvajanja, z vidika metodologij uvajanja in z vidika pristopa uvajanja. Ključne besede Celovite informacijske rešitve, rešitve ERP, rešitve ERP II, rešitve BoB, življenjski cikel informacijski sistem, izbira rešitve ERP, prenova poslovnih procesov, ARIS, pristopi izbire rešitve ERP, standard 9126, metrike za ocenjevanje kakovosti v uporabi s strani končnega uporabnika, uvedba rešitve ERP, hitra implementacija, hitra strategija, pristopi k uvajanju rešitev, metodologija ASAP, metodologija MSB Methodology, metodologija On Target, kritični dejavniki uspeha uvajanja rešitev ERP
5
ABSTRACT COMPARISON ANALYSIS CRITICAL SUCCESS FACTORS ERP SOLUTIONS ACCORDING TO PHASES AND TO METHODOLOGIES OF IMPLEMENTATION Competition, ongoing changes in business, obsolete existing information systems etc. are some of many reasons why lots of organizations are changing existing information systems with enterprise resource planning solutions (ERP solutions). They willingly buy and implement ERP solutions instead of developing software on demand of an organization because of: lower costs of development, shorter period of implementation projects of information system and also because of ERP solutions assured scope of functionality. Today rapid implementation is used for implementing of ERP solutions because organizations do not have time to change ERP solutions. So they must change their business processes to fit business processes of ERP solution. Vendors of ERP solutions demand that organizations, which implemented their solution, must reengineer their business processes in a way that they will be compatible with business processes of ERP solution. Because of that organizations must choose ERP solution which fits the best their business processes, assures functionality of organizations, supports changing business environment, which we can easily integrate with other information systems, offers help of vendor ERP solutions by implementing ERP solutions etc. A lot of ERP solutions are not implemented in due time, with expected costs and in expected scope because of reasons, which are in process of choosing ERP solutions and/or in process of implementing ERP solutions. Our survey consists of three parts. In the first part we have to focus on process of choosing an ERP solution and also on buying it. At choosing ERP solution the most important factor is involvement of end users. Today many approaches are known in choosing ERP solutions and all of them use estimation and validation in advance prepared criterions. One of the ways to estimate and evaluate the ERP solution by end users are in advance prepared metrics for estimation of a software product by the standard ISO/IEC 9126, part quality in use. We have developed a quality model by standard ISO/IEC 9126: "Software engineering - Product quality" on basis of characteristics of ERP solutions, to estimate quality in use, which we can use as one of criterion of choosing an ERP solution. In second part – implementing of ERP solutions we are discussing general approaches of implementing ERP solutions, methodologies ASAP and On Target and we have presented comparison of these two methodologies. In last part we have researched the critical success factors (CSF) in ERP implementation by studying published prior research on the field of ERP implementation. We have built a model of CSFs for ERP implementation according to phases of implementation and also to methodologies. We have verified research models of CSFs by questionnaire on a chosen sample of Slovenian organizations which has implemented ERP solutions. On the bases of the results we performed CSFs analysis according to phases of implementation, to methodologies of implementation and also to approaches of implementation.
6
1 UVOD
1.1 Opredelitev področja in opis problema RAZISKAVE
Konkurenčnost, hitre spremembe v poslovanju, zastareli obstoječi informacijski sistemi, itd. je samo nekaj izmed številnih razlogov, zakaj se v zadnjem času vse več organizacij odloča za zamenjavo obstoječih informacijskih sistemov (v nadaljevanju IS) predvsem s celovitimi informacijskimi rešitvami (v nadaljevanju rešitve ERP). Organizacije se raje odločijo za nakup in uvedbo rešitev ERP kot pa za razvoj programske opreme na ključ, predvsem zaradi sledečih razlogov: nižji stroški razvoja sistema, krajši čas trajanja projekta uvedbe IS kot tudi zaradi razloga, da jim je zagotovljen določen obseg funkcionalnosti. Rešitve ERP so programski paketi z več moduli, ki podpirajo poslovne procese v organizaciji na operativni ravni. Glavne značilnosti rešitev ERP so: integriranost modulov, relacijska podatkovna baza, varnost podatkov in pomoči ter enostaven uporabniški vmesnik. Rešitve ERP pa ne omogočajo samo pridobivanje podatkov v realnem času, pač pa tudi izboljšujejo delovanje poslovnega toka v organizaciji. Narejene so po principu »najboljše prakse«, kar pomeni, da ponudniki rešitev ERP poiščejo najboljše organizacijske poslovne modele v panogi in posvojijo njihov poslovni model v svoji rešitvi ERP. Kot navaja Anderegg et al (2000), danes večina organizacij pri uvajanju rešitev ERP uporablja hitro strategijo zaradi naslednjih razlogov: ostali pristopi so se izkazali za manj uspešne, ekonomija elektronskega poslovanja zahteva hitre rešitve problemov, pravilo 80/20 je v pomoč majhnim projektom in majhno število faz implementacije prinaša poslovne prednosti hitreje kot ostale strategije. Pri hitri uvedbi organizacija nima časa, da bi spreminjala rešitev ERP, zato mora prilagoditi svoje poslovne procese rešitvi ERP. Zato ponudniki rešitev ERP zahtevajo od organizacij, da prenovijo poslovne procese tako, da bodo združljivi s poslovnimi procesi rešitve ERP (Davenport, 1999). Zaradi zgoraj omenjenega razloga, mora organizacija izbrati tako rešitev ERP, ki se kar najbolje prilega njenim poslovnim procesom, zagotavlja funkcionalnost v organizaciji, podpira spreminjajoče poslovno okolje, jo je lahko integrirati z ostalimi IS, nudi pomoč ponudnika rešitve ERP pri uvedbi rešitve, itd. (Shields, 2001). Veliko rešitev ERP ni uvedenih v predvidenem času, s predvidenimi stroški in/ali v predvidenem obsegu zaradi različnih razlogov, ki lahko tičijo:
1. v procesu izbire rešitve ERP in/ali 2. v procesu uvajanja rešitev ERP.
Na našem tržišču tako danes najdemo rešitve ERP svetovnih ponudnikov, kot so: SAP, Baan, Oracle... kot tudi množico rešitev ERP, ki jih ponujajo domače programerske hiše (Comtron, SAOP, Perftech itd.). Iz vse te možice ponudnikov rešitev ERP je izbira »prave« rešitve ERP zelo pomembna odločitev (Shilds, 2001), saj se z uvedbo rešitve ERP ponavadi spremeni tudi organizacijska struktura podjetja (Skok et al, 2001). Zato želimo v prvem delu magistrske naloge najprej opredeliti razloge, zaradi katerih se organizacija odloči za zamenjavo obstoječih IS z rešitvijo ERP. Kot navaja več avtorjev, ni vedno modro kupiti rešitev ERP, ki jo ima naša konkurenca, saj ima lahko konkurenca drugačne poslovne procese kot mi in zaradi tega uvedba enake rešitve ERP ob nespremenjenih poslovnih procesih ne bo prinesla takšnih pozitivnih učinkov, kot jih je prinesla konkurenci. Organizacija mora zato v množici rešitev ERP s pomočjo različnih pristopov ovrednotiti in izbrati zanjo najprimernejšo rešitev ERP.
7
V drugem delu magistrske naloge se bomo osredotočili na probleme, ki se lahko pojavijo med uvajanjem izbrane rešitve ERP. Ker je uvedba rešitve ERP ponavadi strateški projekt v organizaciji in se pri uvajanju rešitev ERP uporablja hitra strategija, ne preseneča dejstvo, da je samo med 10 do 30 % uvajanj rešitev ERP (Gartner Group; povzeto po Kosi, 2004) uvedenih v predvidenem času, s predvidenimi stroški in v predvidenem obsegu. Zaradi zelo malo uspešno uvedenih rešitev ERP danes vsi večji ponudniki rešitev ERP in svetovalne hiše, ki uvajajo rešitve ERP, uporabljajo za uvajanje rešitev ERP lastne metodologije, kot so npr. metodologija ASAP za rešitev mySAP ERP podjetja SAP, metodologijo uvedbe imenovano On Target za rešitev Navision podjetja Microsoft, metodologijo The total solution svetovalne hiše Ernst & Young, metodologijo Fast track workplan svetovalne hiše Deloitte & Touche, itd. Organizacija bo pri uvajanju izbrane rešitve ERP uporabila metodologijo uvajanja, ki jo uporablja ponudnik rešitve ERP. Mi pa želimo v drugem delu magistrske naloge preučiti različne pristope uvajanja rešitev ERP, in sicer: pristop velikega poka, fazni pristop, vzporedni pristop, procesni pristop in druge. Nato želimo podrobneje preučiti metodologijo ASAP rešitve mySAP ERP in metodologijo on Target rešitve Microsoft Navision ter narediti primerjalno analizo teh dveh metodologij. Zaradi velikega števila neuspešno uvedenih rešitev ERP veliko avtorjev (Aduri, Lin in Ma (2002), Akkermans in Helden (2002), Bancroft, Seip in Sprengel (2001), Bradford in Florin (2003), Estaves, Pastor in Casanovas (2002), Jarrar, Al-Mudimigh in Zairi (2000), Khan (2002), Mabert (2003) in drugi) navajajo kritične dejavnike uspeha (v nadaljevanju KDU) uvajanja rešitev ERP. Ker morajo biti organizacije pri uvajanju rešitev ERP pozorne nanje, bomo najprej razvrstili KDU uvajanja rešitev ERP po pomembnosti, ki jim jih pripisujejo različni avtorji. Ker pa vsi KDU niso enako pomembni v posameznih fazah uvajanja, bomo izdelali raziskovalni model KDU z vidika faz uvajanja. Prav tako bomo izdelali raziskovalni model KDU znotraj posameznih metodologij uvajanja. Na osnovi obeh modelov bomo izvedli raziskavo KDU na izbranem vzorcu in izdelali analizo KDU z vidika faz uvajanja, z vidika metodologij uvajanja ter z vidika pristopa uvajanja.
1.2 Namen, cilji in naloga raziskave
Magistrsko delo je razdeljeno na tri dele. V prvem delu se mora organizacija osredotočiti na postopek izbire rešitve ERP in nakupa rešitve ERP. Kot eden izmed pomembnih dejavnikov pri izbiri rešitve ERP so tudi končni uporabniki. Vrednotenje rešitve ERP s strani končnih uporabnikov lahko izvedemo s pomočjo metrik za ocenjevanje kakovosti proizvoda (standard 9126), zato bomo pripravili primer metrik za ocenjevanje kakovosti v uporabi s strani končnega uporabnika. Ko pa organizacija izbere rešitev ERP, se začne druga faza, in sicer uvajanje rešitve ERP. V okviru uvajanja rešitev ERP bomo opredelili tako splošne pristope uvajanja rešitev ERP kot tudi metodologiji ASAP in On Target ter izdelali primerjalno analizo metodologij. V zadnjem delu magistrske naloge želimo na osnovi literature (knjige in »online« baze) opredeliti najpomembnejše KDU rešitev ERP ter izdelati raziskovalni model KDU z vidika faz uvajanja in raziskovalni model KDU znotraj posameznih metodologij. Modela KDU bomo verificirali s pomočjo raziskave na izbranem vzorcu, ki bo zajemal slovenske organizacije, ki imajo uvedeno rešitev ERP. Na osnovi rezultatov raziskave bomo naredili analizo KDU z vidika faz uvajanja, z vidika metodologij uvajanja in z vidika pristopa uvajanja.
8
Cilji magistrske naloge so: • izdelati primer metrike za ocenjevanje kakovosti v uporabi po standardu 9126, • izdelati primerjalno analizo metod ASAP in On Target, • izdelati in ovrednotiti KDU uvajanja rešitev ERP z vidika faz uvajanja ter • izdelati in ovrednotiti KDU uvajanja rešitev ERP z vidika metodologij uvajanja in
pristopov uvajanja. Raziskava je teoretični prikaz procesa izbire in uvedbe rešitve ERP s poudarkom na KDU uvajanja rešitev ERP in je sestavljena iz naslednjih poglavij: 1. Prvo poglavje vsebuje splošen pregled raziskave.
2. V drugem poglavju bomo opredelili, kaj so rešitve ERP, prikazali razvoj rešitev ERP, predstavili koncepte in zgradbo rešitev ERP ter življenjski cikel rešitev ERP.
3. Tretje poglavje vsebuje podroben potek uvajanja rešitev ERP, strategije uvajanja ter zgradbo in organizacijo projektne skupine.
4. V četrtem poglavju bomo opredelili razloge, zaradi katerih se organizacija odloči za uvedbo rešitve ERP, predstavili postopke izbire rešitev ERP, kdaj in zakaj mora organizacija izvesti analizo poslovnih procesov, kako lahko s pomočjo metrik ocenimo rešitev ERP s strani končnega uporabnika in nato izdelamo oceno investicije. Na koncu tega poglavja pa želimo opozoriti še na management nakupa rešitev ERP.
5. V petem poglavju bomo najprej razložili pristope uvajanja rešitev ERP, potem pa bomo podrobneje opisali metodologijo ASAP in metodologijo On Target. Na koncu poglavja bomo naredili primerjavo omenjenih metodologij.
6. V šestem poglavju bomo na osnovi objavljenih člankov v revijah in knjigah ugotovili, kateri KDU uvajanja rešitev ERP se pojavljajo v literaturi najpogosteje in jih tudi opisali. Nato bomo preverili, kateri so KDU informacijskih projektov, in/ali se pojavljajo isti KDU v obeh skupinah, oziroma kateri KDU so pomembnejši pri uvajanju rešitev ERP in kateri KDU so pomembnejši pri uvajanju informacijskih projektov. Na osnovi pridobljenega znanja o KDU, bomo izdelali dva raziskovalna modela, in sicer: (1) raziskovalni model KDU uvajanja rešitev ERP z vidika faz uvajanja in (2) raziskovalni model KDU uvajanja rešitev ERP znotraj posameznih metodologij. Po opravljeni raziskavi bomo izdelali analizo KDU uvajanja rešitev ERP z vidika faz uvajanja, z vidika metodologij uvajanja in z vidika pristopa uvajanja.
7. Sedmo poglavje vsebuje povzetek in razmišljanja za nadaljnje raziskave.
1.3 Predpostavke in omejitve raziskave
Predpostavke: • vse omenjene rešitve ERP v raziskavi se po znanih kriterijih uvrščajo med rešitve
ERP; • raziskava se ne omejuje na posamezno rešitev ERP, pač pa se nanaša na rešitve ERP
na splošno, razen v delu poglavja pet, kjer bomo natančneje opisali metodologijo ASAP in metodologijo On Target ter primerjalno analizo med njima;
• predpostavljamo, da organizacija želi uvesti najprimernejšo rešitev ERP v predvidenem času, s predvidenimi viri in v predvidenem obsegu;
9
• primer metrik za ocenjevanje kakovosti v uporabi s strani končnega uporabnika se nanaša na rešitve ERP na splošno in jih je potrebno za ocenjevanje posamezne rešitve ERP prilagoditi značilnostim izbrane rešitve ERP.
Omejitve:
• rešitve ERP bomo obravnavali na splošno in se ne bomo osredotočili na posamezno organizacijo niti ne na posamezno panogo;
• ne bomo se spuščali v podrobno razpravo, katera rešitev ERP je najprimernejša za posamezno organizacijo niti ne za posamezno panogo;
• v okviru poglavja 4.4 bomo razložili, ne bomo pa se podrobneje ukvarjali z metrikami za notranjo (interno) in zunanjo (eksterno) kakovost ter njunim vrednotenjem;
• ker je metodologija MSB Methodology rešitve Microsoft Navision poslovna skrivnost podjetja, v nalogi ne bomo razkrili tistih delov, ki so poslovna skrivnost podjetja;
• v raziskavi KDU uvajanja rešitev ERP se bomo osredotočili na slovenske organizacije, ki imajo uvedeno rešitev mySAP ERP, MS Navision oziroma GEAC System21.
1.4 Predvidene metode raziskovanja
Raziskava je sestavljena: • iz poslovne raziskave v prvem delu magistrskega dela ter • iz mikroekonomske raziskave v šestem poglavju, kjer bomo izvedli raziskavo KDU
v slovenskih organizacijah, ki imajo uvedeno rešitev ERP. Raziskava bo statična, saj bo ugotavljala odvisnost med ekonomskimi pojavi v določenem trenutku. V raziskavi bomo tako uporabili deskriptivni kot tudi analitični pristop. V okviru deskriptivnega pristopa (opis rešitev ERP, izbira in nakup rešitev ERP ter pristopi k uvajanju rešitev ERP) bomo uporabili naslednje metode:
• metodo deskripcije, • metodo klasifikacije, • komparativno metodo.
V šestem poglavju bomo uporabili analitični pristop, in sicer interakcijo deduktivnega in induktivnega načina sklepanja po naslednjih korakih:
• deduktivno sklepanje, • induktivno sklepanje, • ponovno deduktivno sklepanje.
Ne bomo pa naredili zadnjega koraka, ki obsega induktivno ponavljanje na primeru. Zadnji korak, kjer bomo naš model preizkusili v praksi na posameznih organizacijah, bomo izvedli v nadaljnjih raziskavah.
10
2 CELOVITE INFORMACIJSKE REŠITVE
2.1 Opredelitev celovitih informacijskih rešitev
V začetku 90-ih so začele programerske hiše ponujati popolnoma integrirane rešitve aplikacij, ki so podpirale večino oziroma vse (odvisno od velikosti, kompleksnosti in panoge) funkcije podjetja. Takšne rešitve so poimenovali celovite informacijske rešitve oziroma s kratico rešitve ERP (angl. Enterprise Resource Planning). Programerske hiše, ki so razvile in ponujale rešitve ERP, so poimenovali »Ponudniki celovitih informacijskih rešitev« oziroma s kratico ponudniki rešitev ERP (Shields, 2001, 6). V nadaljevanju bomo predstavili nekatere opredelitve rešitev ERP izbranih avtorjev. V devetdesetih letih je organizacija Gartner Inc. predstavila kratico ERP kot (Harwood, 2004; povzeto po Gartner Inc. definicija: www.gartner.com): koncept, ki opisuje naslednjo generacijo proizvodnih poslovnih IS in planiranje vseh proizvodnih virov (kratica MRP II – ang. Manufacturing Resource Planning). Rešitev ERP vključuje arhitekturo odjemalec/strežnik, uporabniški grafični vmesnik in je prepletena z različnimi sistemi. Poleg standardne funkcionalnosti, omogoča tudi zagotavljanje kakovosti, urejeno poročanje, itd. Tehnologija, uporabljena v rešitvah ERP, daje uporabnikom programsko in strojno neodvisnost, omogoča pa tudi enostavno pot do nadgradenj. Ključ do uspešne rešitve ERP je prikrojitev rešitve ERP tako, da je enostavna za uporabo. Kalakota in Robinson (2001, 240) definirata rešitev ERP kot skupek več aplikacij - modulov, ki sestavljajo ogrodje za avtomatiziranje financ, proizvodnje in distribucije, človeških virov in administrativnih funkcij. Tako rešitve ERP združujejo naslednje poslovne procese: proizvodnjo, proces naročanja, urejanje inventarja in skladišč, prejem in plačevanje računov, glavno knjigo in plače. Anderegg s sodelavci (2000, 5) opredeljuje rešitve ERP kot celovite organizacijsko-poslovne programske rešitve. Sestavljene so iz programskih modulov, kot so npr: marketing in prodaja, načrtovanje proizvodnje in razvoj, proizvodnja in kontrola inventarja, nabava, distribucija, kakovost, človeški viri, finance in računovodstvo, informacijske storitve, itd. Pri tem pa je integracija modulov dosežena brez podvajanja informacij. Harwood (2004, 29) pravi, da rešitve ERP ne smemo opredeliti kot podatkovne baze z nekaj v naprej vgrajenim programjem. Rešitve ERP se nanašajo na zagotavljanje avtomatizirane podpore poslovnim procesom ter zagotavljajo tudi:
• izboljšan dostop do informacij, • pomoč pri uvajanju, vključno s procesnim modeliranjem in dokumentacijo ter • orodja, ki podpirajo izobraževanje in razvoj rešitev ERP.
Wallace in Kremzar (2001, 5) opisujeta rešitve ERP kot podjetniški skupek managerskih orodij, s pomočjo katerih uravnavamo povpraševanje in ponudbo, povezovanje kupcev in dobaviteljev v zaključeno dobavno verigo, so izdelane na podlagi preizkušenih poslovnih procesov, zagotavljajo visoko stopnjo med-funkcijske integracije med poslovnimi funkcijami, omogočajo večjo produktivnost zaposlenih, kar se odraža na visoki stopnji
11
zagotavljanja storitev kupcem ter znižanju stroškov in zalog, hkrati pa zagotavljajo tudi temelje za učinkovito e-poslovanje (angl. e-commerce). O'Leary (2000, 27) pravi, da lahko rešitve ERP prepoznamo po naslednjih značilnostih:
• 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, • v nekaterih primerih omogočajo tudi integracijo obdelave transakcij in planiranje
aktivnosti (npr. planiranje proizvodnje). Poleg tega se od rešitev ERP pričakuje, da podpirajo več valut in jezikov, imajo podporo za podjetja v različnih panogah ter možnost prilagoditve rešitve brez programiranja (tako imenovano mehko programiranje oziroma prilagajanje, kamor spada tudi konfiguriranje). Če pa opisujemo rešitve ERP z vidika uporabnikov, potem jih lahko opišemo kot skupek, ki (Hamilton, 2002):
• definira pot izdelave vsakega izdelka in storitve, • določajo zahteve posameznih izdelkov oziroma točno določene kupčeve zahteve, • določajo realne poslovne plane in s tem točne dobavne roke izdelkov in storitev, • uporabljajo urnik za koordiniranje aktivnosti dobavne verige ter • omogočajo točno kalkulacijo stroškov izdelkov in zagotavljajo uporabne
informacije managerjem.
2.2 Razvoj celovitih informacijskih rešitev
Rešitve ERP so z razvojem vse zmogljivejše strojne in programske opreme ter omrežji, postale nepogrešljiv pripomoček pri poslovanju. Kot navaja Anderegg et al (2000, 2), se je v času od sredi dvajsetega stoletja skozi več ravni razvijala tudi poslovna programska oprema (glej slika 1). V 50-ih letih so razvili poslovne programe, ki so se uporabljali za avtomatiziranje enostavnih rutinskih opravil. Zajemali so naročanje količin materiala, varne zaloge, planiranje kosovnic (seznam materiala) in delovne naloge. V začetku 60-ih let so podjetja prišla na idejo, da bi bilo bolj smiselno imeti en računalniški program, ki bi skrbel za naročanje materiala in ostalih komponent v podjetju. Program so poimenovali »Planiranje zahtev materiala« oz. s kratico MRP (ang. Material Resource Planning)1. Program MRP so sestavljali:
o plan dela (kaj bomo delali), o planiranje kosovnic (kaj potrebujemo za izdelavo) in o seznama inventarja (kaj imamo).
S pomočjo teh treh modulov so lahko določili bodoče zahteve (kaj moramo še nabaviti) (Wallace, 2001, 6). S pomočjo programa MRP so tako lahko določili količino vseh 1 V nadaljevanju bomo programe za planiranje materiala imenovali s kratico MRP.
12
potrebnih komponent in materialov ter datum naročila novih komponent in materialov. Uporabljali so se predvsem za avtomatiziranje rutinskih opravil in za avtomatiziranje pogosto uporabljenih funkcij zadnje pisarne (Shields, 2001, 3). Izdelani so bili po meri za posamezna podjetja. Kot navaja Shields (2001, 4), so bili ti programi slabi zaradi naslednjih lastnosti:
• ker so jih napisali ljudje, ki niso imeli programerskega znanja, • za programiranje so uporabljali nižje programske jezike, • ni bilo podpore relacijskih podatkovnih baz, • ni bilo zmogljivih pomnilnikov in • uporabljali so se znakovni vmesniki, ki niso vedno komunicirali z velikimi
računalniki v realnem času. Pri razvoju teh programov niso sodelovali ključni uporabniki organizacij, kar nas pripelje do rezultata, da programi niso zadovoljevali potreb uporabnikov, niso bili končani v predvidenem času in s predvidenimi stroški (Shields, 2001, 4). SLIKA 1: Zgodovina rešitev ERP
Vir: prirejeno po Anderegg (2000,2)
Programi MRP so se hitro razvili v nekaj več, kot je samo boljši način naročanja zalog, in sicer v programe za planiranje vseh proizvodnih virov oz. s kratico sistemi MRP II (angl. Manufacturing Resource Planning)2. Kot navaja združenje APICS3 (in tudi Wallace, 2001, 9), so lahko v organizacijah s pomočjo sistema MRP II učinkovito planirali vse vire v proizvodnem podjetju, kar zajema:
• operativno planiranje količinskih enotah, • finančno planiranje v denarnih enotah in • zmožnost simuliranja vprašanj »kaj-če«.
2 V nadaljevanju bomo programe za planiranje virov imenovali s kratico MRP II. 3 Združenje APICS je izobraževalno združenje za upravljanje z viri (http://www.apics.org).
13
Sestavljen je iz množice povezanih funkcij, kot so: poslovno planiranje, planiranje prodaje, planiranje proizvodnje, planiranje potreb po nabavi materiala, planiranje potrebnih kapacitet ter sisteme za podporo kapacitet in materiala. Izpisi iz sistema MRP II so povezani s finančnimi poročili, kot so: poslovni plan, poročilo o nabavi, poročilo o stroških transporta in stanje zalog v denarnih enotah. Sistemi MRP II so bili najprej razviti za eno organizacijo in nato prodani tudi drugim organizacijam (npr. ista glavna knjiga), kar pomeni, da so postali standardni programi. Prednost takšnega pristopa je skrajšani čas razvoja in uvajanja. Poleg tega so se ponudniki standardnih programov specializirali v izdelavi posameznih modulov (tako imenovanih »best-of-breed« programov). Tako je imela ena organizacija uvedenih več modulov različnih programskih hiš. Vsak modul je imel svojo bazo in med temi bazami ni bilo vmesnikov, ki bi delali v realnem času (Shields, 2001, 5). Ponudniki MRP II rešitev so dodajali obstoječim modulom nove module (Shields, 2001, 6), ki so predstavljali najboljšo prakso (angl. best practice) v avtomatizirani podpori poslovnih procesov. To pomeni, da so ponudniki standardnih rešitev uporabili najboljše ideje njihovih kupcev in strokovnjakov ter jih vključili v svoje rešitve. Poleg tega so ponudniki začeli spreminjati tehnološko arhitekturo svojih modulov, tako da so le-ti omogočali, da so aplikacije potekale na različnih platformah, v različnih operacijskih sistemih4 in različnih sistemih za urejanje podatkovne baze5. In tako so sistemi MRP II prerasli v devetdesetih letih prejšnjega stoletja v celovite informacijske rešitev oziroma s kratico rešitve ERP. Tako so rešitve ERP nadgradnja programov MRP II z dodatno funkcionalnostjo financ, distribucije in človeških virov (Siriginidi, 2000, 378). Poleg teh vključujejo rešitve ERP tudi drugo funkcionalnost »back office«, kot so urejanje naročil, finančni management, skladiščenje, distribucija, kontrolo kvalitete, management premoženja in management človeških virov. Rešitve ERP so od rešitev MRP II zmogljivejše zaradi (Wallace in Kremzar, 2001, 12):
• vključujejo orodje za planiranje virov v organizaciji, • zagotavljajo integracijo prodaje, proizvodnje in finančnih podatkov v realnem
času in • vključujejo pristope planiranja virov na razširjeno oskrbovalno verigo kupcev in
dobaviteljev. Rešitve ERP je bilo mogoče razviti šele v 90-ih, tudi zaradi pojava tehnoloških izboljšav, kot so:
• 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 Aded Software Engineering) in • arhitekture odjemalec/strežnik.
Z letom 2000 se je začelo obdobje rešitev ERP II (Harwood, 2004, 39), ki se kaže v spreminjanju koncepta rešitev ERP iz podpore »back office« ene organizacije v povezovanju in podpori več medsebojno povezanih organizacij. Glavna značilnost tega
4 V nadaljevanju bomo za operacijski sistem uporabljali kratico OS. 5 V nadaljevanju bomo za sistem za upravljanje s podatkovno bazo uporabljali kratico SUPB.
14
obdobja je, da so organizacije odprle svoje sisteme drugim organizacijam, dobaviteljem ali kupcem (Harrington et al, 2001). Tako se je obseg funkcionalnosti rešitev ERP povečal tudi na funkcionalnost »front office-a«, kamor spada e-poslovanje (angl. e-business), obvladovanje nabavnih verig in logistike oziroma s kratico sistem SCM (angl. Supply Change Management) in upravljanje s človeškimi viri oziroma s kratico sistem CRM (angl. Customer Relation Management). Gartner Group (Harwood, 2004) tako definira rešitve ERP II kot poslovno strategijo in skupek industrijsko prilagojenih aplikacij v verigi od dobaviteljev do kupcev. V tabeli 1 imamo prikazane razlike med konceptoma rešitev ERP in ERP II. TABELA 1: Primerjava med ERP in ERP II
Element ERP ERP II Vloga aplikacije Optimiziranje poslovanja v
organizaciji Sodelovanje v vrednostni verigi
Poslovna področja Proizvodnja in distribucija Vsi sektorji / segmenti Funkcije znotraj področja Proizvodnja, prodaja in
distribucija, ter finance Procesi med industrijskimi sektorji in posebnimi sektorji
Procesi, ki so potrebni za izvedbo funkcij
Notranji, skriti Zunanji, povezani
Sistemska arhitektura Zavedanje se spleta, zaprt, monolitski
Temelječ na spletu, odprt, sestavljen s komponent
Vir: prirejeno po Gartner Inc (2000; povzeto po Harwood, 2004, 40) Razvoj ERP, ki smo ga opisali v tem poglavju, je povzet v tabeli 2. TABELA 2: Primerjava razvojnih faz rešitev ERP
1950 1965 1975 1990 2000
Urejanje zalog MRP MRP II ERP ERP II Značilnosti Varčno
naročanje količine zalog
Skupno planiranje proizvodnje
CIM EIS
Dokončno načrtovanje, OLAP, diagram poteka, e-pošta
Portali, poslovna inteligenca (BI)
Managementski koncepti
TQM, JIT, OPT
Principi najboljše prakse
SCM, CRM, e-poslovanje
Usmerjenost aplikacij
Nadziranje zalog
Operativno planiranje in kontrola
Integracija Notranja učinkovitost
Povezljivost med aplikacijami različnih organizacij
Metodološki pristop
Ročni sistemi Znanstvene rešitve
Enostavnost Poslovne rešitve
Virtualne poslovne rešitve
Vključene tehnologije
Strojni jezik Proceduralni jeziki kot npr. Fortran, COBOL
Odprti sistemi, 4 generacija jezikov kot npr. SQL
GUI, objekti, komponente, TCP/IP
WAP, VoIP
Strojna oprema Mehanski Paketna obdelava
Mini računalniki, delovne postaje, PC-i
Stranka/strežnik, LAN
Porazdeljena omrežja
Vir: prirejeno po Harwood (2004, 41)
15
Kot navaja Anderegg et al (2000, 9), izmed več kot tisoč ponudnikov rešitev ERP obvladuje večino trga (med 60 in 70 odstotki) približno 10 ponudnikov. Po raziskavi organizacije IDC so v letu 2003 ponudniki rešitev ERP imeli 25 milijard ameriških dolarjev prihodkov (Framingham, 2004). Od tega 10 največjih ponudnikov 46 odstotkov (11 milijard ameriških dolarjev). Pet največjih ponudnikov leta 2003 vidimo v tabeli 3. Poleg teh ponudnikov rešitev ERP pa se pojavljajo tudi ponudniki rešitev ERP, kot so: Baan (rešitev iBaan), GEAC (rešitev System 21), Quad (rešitev MFG/PRO) in drugi. TABELA 3: Pet največjih svetovnih ponudnikov rešitev ERP
Ponudnik ERP Rešitev Spletni naslov Logotip
SAP MySAP.com www.sap.com
PeopleSoft PeopleSoft www.peoplesoft.com
Oracle Oracle E-Business Suite www.oracle.com
Microsoft Microsoft Navision Axapta www.navision.com
Sage Sage Line 500 www.sage.com
Vir: povzeto po Framingham (2004) Med domačimi ponudniki rešitev ERP pa imamo: Kopa (Kopa; www.kopa.si), Comtron (Tron InterCenter; www.comtron.si), SAOP (SOAP; www.soap.si), Micropis (www.micropis.si), GOinfo (GoSoft 2000, www.Goinfo.si), Perftech (Perftech.Largo; www.perftech.si) ... V zadnjem času se v literaturi vse bolj pojavlja tudi izraz celovita integracija aplikacij oziroma s kratico sistemi EAI (angl. Enterprise Application Integration), ki združuje tradicionalne ERP rešitve (podpirajo poslovne procese v podjetju) in vse druge aplikacije, ki skupaj z drugimi med-organizacijskimi sistemi sestavljajo vrednostno verigo od kupca do dobavitelja. Organizacija Ittoolbox je definirala EAI sisteme kot (Gormly, 2001):
• integracijo poslovnih procesov, • aplikacijsko integracijo, • podatkovno integracijo, • integracijo standardov in • integracijo platform.
Integracija poslovnih procesov vključuje in ureja procese za izmenjavo informacij podjetja med neenakimi poslovnimi sistemi. To omogoča sledenje naravnemu toku operacij, zmanjšanju stroškov in boljšo dostopnost do kupčevih zahtev. Cilj aplikacijske integracije je prenos podatkov in funkcij z ene aplikacije v drugo aplikacijo v realnem času. Uporablja se za integracijo podjetja s podjetjem oziroma s kratico B2B (angl. Business to Business), sisteme CRM, spletno integracijo itd. V primeru, da sta aplikacijska integracija in integracija poslovnih procesov uspešni, potem lahko pride do integracije podatkov in podatkovnih baz. Da lahko dosežemo podatkovno integracijo, morajo biti podatki razvrščeni v skupine, poleg tega pa mora biti zgrajen meta podatkovni model. Ko so opravljeni ti koraki, potem so lahko podatki porazdeljeni po podatkovnih bazah. Popolno integracijo podatkov dosežemo z določenimi standardnimi formati za deljenje in
16
distribuiranje informacij in poslovnih podatkov. Ti standardi vključujejo COM+/DCOM, CORBA, EDI, JavaRMI in XML. Integracija platform vključuje procese in orodja, ki so potrebna, da lahko različna strojna in programska oprema komunicira med sabo optimalno in varno. Podatki lahko potujejo skozi različne aplikacije brez težav. Po raziskavah organizacije IDC bo svetovni prihodek na področju EAI sistemov skočil iz 5 milijard ameriških dolarjev v letu 2000 na skoraj 21 bilijonov ameriških dolarjev v letu 2005. Vodilni proizvajalci EAI rešitev so: BEA Systems, CrossWorlds Software, IONA Technologies itd. (Gormy, 2001).
2.3 Koncepti in zgradba celovitih informacijskih rešitev
Kot navaja Anderegg et al (2000, 15), je koncept rešitev ERP sestavljen iz osnovnih delov, ki jih vidimo na sliki 2. Temelj koncepta rešitve ERP so podatki organizacije. Organizacija potrebuje podatke za poslovanje. Podatke lahko obdeluje (različne kalkulacije), hrani na enem mestu v podatkovni bazi in prenaša med različnimi programi, podatkovnimi bazami in zunanjimi napravami s pomočjo integracije programov in podatkovne baze6. S pomočjo integracije programov in PB je zagotovljena funkcionalnost rešitev ERP. SLIKA 2: Koncept rešitve ERP kot trikotnika
Vir: prirejeno po Anderegg et al (2000, 15) Koncept rešitev ERP pa lahko opazujemo tudi skozi celovit proces predvidevanja in uravnavanja med povpraševanjem po izdelkih/storitvah kupcev ter nabavo vseh potrebnih virov organizaciji (slika 3). Rešitve ERP nam tako omogočajo s pomočjo orodij (Wallace in Kremzar, 2001, 10):
• predvidevanje, planiranje in načrtovanje, • povezovanja kupcev in dobaviteljev v zaključeno oskrbovalno verigo, • odločanje na osnovi preizkušenih procesov, • module prodaje, marketinga, proizvodnje, distribucijo (logistiko), proces
naročanja, finance, razvoj izdelkov in človeške vire.
6 V nadaljevanju bomo za podatkovno bazo uporabili kratico PB.
17
SLIKA 3: Grafični prikaz koncepta rešitve ERP
Vir: prirejeno po Wallace in Kremzar (2001) SLIKA 4: Razširjeno programsko okolje organizacije
Vir: prirejeno Shields (2001, 10) Ponudniki ERP so obstoječim modulom (proizvodnja, logistika (distribucija), finance in človeški viri) z razvojem novih tehnologij (npr. omrežje internet) dodali naslednje module (Shields et al, 2001, 10):
18
• modul oskrbovalne verige7, • modul odnosov s kupci8, • modul elektronske nabave in druge, kot je prikazano na sliki 4.
Po navedbah Krella (2003) so se podjetja množično odločala za rešitve ERP zaradi integriranosti modulov, relacijskih podatkovnih baz, zagotovljene boljše varnosti in pomoči ter enostavnega uporabniškega vmesnika. To pomeni enkratni vnos podatkov ali prenos z drugega mesta, zmanjšano število napak, časa in napora pri pripravi poročil, analiz ter planiranju, kar vidimo na sliki 5 (Aduri et al, 2003). SLIKA 5: Tehnična arhitektura ERP sistema
Vir: prirejeno po Aduri et al (2003)
2.4 Življenjski cikel celovitih informacijskih rešitev
Življenjski cikel vsake programske rešitve je lahko razdeljen na več faz. Tako imamo pri štiri-faznem življenjskem ciklu faze: izbira (angl. selection), definiranje (angl. definition), uvajanje (angl. implementation) in delovanje (angl. operation). Veliko avtorjev (Harwood, Baywa, O'Leary itd.) pa opisuje življenjski cikel rešitev ERP pet-fazno. Harwood (2004) deli življenjski cikel rešitev ERP na naslednje faze (slika 6):
1. faza potreb (angl. needs),
7 Angl. Supply Chain Management oz. s kratico SCM. 8 Angl. Customer Relationship Management oz. s kratico CRM.
19
2. faza izbire ponudnika rešitve ERP(angl. vendor selection), 3. faza uvedbe (angl. implementation), 4. faza zagona v živo (angl. GoLive) in 5. faza izboljševanja delovanja rešitve ERP (angl. improvement).
Življenjski cikel ERP se začne s potrebo po novem IS, saj je obstoječi IS neprimeren. To vodi v fazo izbire najprimernejšega ponudnika rešitev ERP in nato sledi v fazo uvajanja. V njej prilagodimo poslovne procese organizacije rešitvi ERP ter pripravimo vse potrebno za fazo zagona v živo. Faza izboljševanja delovanja rešitve ERP in organizacijskega učenja po zagonu v živo vodi v popolnejše izkoriščanje rešitve ERP. S časom se življenjski cikel zaključi s spoznanjem, da je trenutna rešitev ERP neprimerna in začne se prva faza novega življenjskega cikla. V novem življenjskem ciklu lahko nadgradimo obstoječo rešitev ERP z novimi moduli obstoječe rešitve ERP, novimi moduli druge rešitve ERP ali pa zamenjamo rešitev ERP z drugo programsko rešitvijo. SLIKA 6: Življenjski cikel rešitve ERP
Baywa et al (2004) je pripravil ogrodje življenjskega cikla petih faz in poudarja, da se vsaka faza konča z mejnikom (slika 7). SLIKA 7: Življenjski cikel rešitve ERP z mejniki
Začetna faza se imenuje »zavest« (angl. awareness) in vodi v odločitev o nakupu IS (rešitev ERP) namesto lastnega razvoja programske rešitve. V fazi zavesti so glavne aktivnosti: ocenitev trenutnega stanja s poslovnega in tehničnega zornega kota ter zbiranje dejstev in informacij o možnih razlogih za menjavo (problemi in priložnosti) obstoječih programskih rešitev. Faza zavesti nas pripelje do odločitve, da bomo kupili rešitev ERP. V fazi »izbor« (angl. selection) organizacija izbere rešitev ERP enega ponudnika rešitev ERP
ZAVEST
ODLOČITEV ZA NAKUP ERP
IZBOR PRIPRAVA UVEDBA DELOVANJE
ODLOČITEV ERP oz. BoB
ŠTUDIJA AS-IS/TO-BE
ZAGON V ŽIVO ORGANIZA-CIJSKO UČENJE
POTREBE
IZBIRA PONUDNIKA
UVEDBA ZAGON V ŽIVO
IZBOLJŠAVE
20
ali pa module različnih ponudnikov rešitev ERP9. V večini primerov proces izbire vodi notranji tim, ki je sestavljen iz ključnih funkcijskih managerjev, uporabnikov in informatikov organizacije. Lahko pa v timu sodelujejo tudi zunanji svetovalci. Ključne aktivnosti v procesu izbire so: določitev projektnih ciljev, zbiranje informacij o rešitvah ERP, analiza potreb, vrednotenje ponudnikov in svetovalcev, vrednotenje infrastrukture IT, študija izvedljivosti (angl. feasibility study) in finaliziranje pogodbe. Ta faza se zaključi s podpisom pogodbe med organizacijo in izbranim ponudnikom rešitve ERP. V fazi »priprave« (angl. preparation) je potrebno določiti obseg projekta, vzpostaviti tim za uvajanje rešitve ERP in časovni okvir uvajanja, poslati tim na izobraževanje ter začeti s prototipiranjem. Aktivnosti te faze so usmerjene tudi v določitev najprimernejšega pristopa uvajanja rešitve. Faza se zaključi s študijo »je/bo« (angl. as-is/to-be), ki bo zemljevid za naslednjo fazo. S pomočjo te študije zaznamo tudi obstoječe praznine in ozka grla. Faza »priprave« je zelo povezana s fazo »uvedbe« (angl. implementation). Faza uvedbe je najbolj kritična faza v življenjskem ciklu rešitve ERP. Aktivnosti faze vključujejo: podrobno analizo praznin, prenovo poslovnih procesov, določitev komplementarnih rešitev, pripravo prototipa, pretvorbo podatkov, določitev delovnih procedur, namestitev rešitve ERP, uporabniško izobraževanje in test odobritve (angl. acceptance test). Faza se zaključi z zagonom v živo, kar pomeni, da postane uvedena rešitev ERP operativna. Zadnja faza življenjskega cikla se imenuje »delovanje« (angl. operation). Aktivnosti v njej se nanašajo na vzdrževanje rešitve ERP in vse večje poslovne integracije. Vzdrževanje rešitve ERP je osredotočeno na zagotavljanje tehnične zmogljivosti sistema, medtem ko se poslovna integracija nanaša na doseganje vse večje procesne zmogljivosti. Pogosto je čas zadnje faze odločilen, saj se ob uporabi rešitve ERP organizacija prilagaja novim načinom poslovanja, ki so podprti s strani rešitve ERP. Tipične aktivnosti vzdrževanja vključujejo: odpravo napak, izboljšanje zmogljivosti delovanja sistema, dodajanje strojne opreme po potrebi, nadgradnje, prenos podatkov, itd. Poslovna integracija pa je osredotočena na spreminjanje procesov in procedur, dodatno izobraževanje, izboljšanje poslovanja, itd. Zaključek faze delovanja je organizacijsko učenje. Kljub temu, da na začetku ne izkoriščamo vseh prednosti integriranih procesov, ki jih omogoča rešitev ERP, je proces asimilacije možnost za organizacijsko učenje, vsaj vključuje veliko število uporabnikov, ki so doživeli izobraževanje in so bili vključeni v uvajanju. Te izkušnje vodijo organizacijo v veliko večjo učinkovitost uvajanja prihodnjih IT projektov. V nadaljevanju magistrske naloge bomo faze življenjskega cikla podrobneje opisali. Kot navaja Laudon et al (2000, 371), je življenjski cikel IS približno 8 let. To pomeni, da če uvajamo nov sistem dve do tri leta, potem bomo lahko takšen IS uporabljali samo še 5 do 6 let. Na sliki 8 je prikazan življenjski cikel IS-a, kjer smo za uvajanje nove rešitve uporabili standardno metodo. Čas t0 je čas, ki je potreben, da se po standardni metodi razvije nov IS. V tem času imamo samo vlaganja v razvoj nov IS, kar nam prikazuje padajoča krivulja. Ko je IS po približno dveh do treh letih zgrajen, lahko obstoječi IS zamenjamo z novim. Čas, ko se uporablja novo uvedeni IS, nam prikazuje td. Po zagonu v živo se na začetku že pokaže nekaj pričakovanih učinkov. Na začetku delovanja so le-ti nižji zaradi napak, ki se pojavijo ob delovanju in zaradi neizkušenosti končnih
9 V nadaljevanju bomo za uvedbo modulov različnih ponudnikov rešitev ERP uporabljali kratico BoB ((angl. Best of Bread).
21
uporabnikov glede uporabe IS10. S časom se uporabniki naučijo dodobra uporabljati IS in tudi programske oziroma sistemske napake se v tem času odpravijo, zato se krivulja pričakovanih učinkov strmo dviguje. Proti koncu življenjske dobe IS-a se začnejo pojavljati večji stroški. To so stroški amortizacije obstoječe tehnologije (nova tehnologija je cenejša in zmogljivejša), vse dražji posegi v programsko kodo in drugo. SLIKA 8: Življenjski cikel IS
Vir: prirejeno po Haucu (2002, 101) in Laudonu et al (2000, 371) Uvedba novega IS-a po standardni metodi traja 2 do 3 leta, pogosto pa se zgodi, da projekti niso končani v predvidenem času, s predvidenimi stroški in v predvidenem obsegu. Če se zgodi, da projekt ni končan v predvidenem času, ima organizacija možnost, da omeji obseg projekta, ali pa da podaljša čas izvedbe projekta. Organizacije ponavadi izberejo slednjo možnost. SLIKA 9: Življenjski cikel IS, kjer projekt razvoja in uvedbe IS ni končan v predvidenem času in s predvidenimi stroški
Vir: prirejeno po Haucu (2002, 99) in Laudonu et al (2000, 371)
10 Krivulja izkušenj temelji na ugotovitvah, da lahko pridobljene izkušnje za podjetje povzročijo znižanje stroškov te dejavnosti. Osemdeset odstotna krivulja izkušenj pomeni, da se znižajo stroški po enoti proizvoda, pri vsaki podvojitvi izkušenj, na 80-odstotkov prejšnje višine (Belak, 2002, 223-224). Zaradi večanja izkušenj so se torej znižali stroški in zvišali pričakovani učinki.
22
Preden organizacija odobri kasnejši rok zagona v živo se mora zavedati, da se s tem povečajo stroški. S podaljšanjem uvajanja novega IS-a pa organizacija ne bo mogla podaljšati življenjskega cikla IS-a in tudi ne bo dosegla načrtovanih pričakovanih učinkov (črtkana krivulja). Največje učinke bo dosegla kasneje (točka B), kot so bili načrtovani. Primer, kjer je organizacija podaljšala čas uvajanja za eno leto vidimo na sliki 9. Če se razvoj in uvajanje novega IS-a zavleče, se lahko zgodi, da se v tem času na vidiku pojavi nova tehnologija, s pomočjo katere bi hitreje in ceneje vpeljali nov IS. Vpliv prihajajoče tehnologije na obstoječo prikazujemo na sliki 10, (povzeta po Reberniku (1990, 74-75) v Belaku, 2002, 228). Rebernik se sklicuje na Twissova (1986) spoznanja ter pojasnjuje spodnjo sliko: »Slika ponazarja spopad obstoječe tehnologije (tehnologija 1) in prihajajoče tehnologije (tehnologija 2) in opozarja na križanje S – krivulj v odvisnosti od tega, ali se ne odzivamo na novo tehnologijo (krivulja A) ali pa odgovarjamo na izziv s povečanim vlaganjem (krivulja B) oziroma z zmanjšanim vlaganjem (krivulja C) v obstoječo tehnologijo«. SLIKA 10: Vpliv prihajajoče tehnologije na obstoječo
Vir: povzeto po Rebernik (1990, 74) v Belak (2002, 228)
Zaradi zgornjih ugotovitev lahko narišemo krivuljo vlaganja in pričakovanih učinkov, kot vidimo na sliki 11. Zaradi krajšega uvajanja rešitve ERP (od 6 do 18 mesecev) se skrajša tudi čas vlaganja. Ker ni potrebno toliko testiranja in razvoja, pričakujemo tudi nižje stroške, kot pa bi jih imeli, če bi razvijali lastni IS po standardni metodi. Če si pogledamo krivuljo pričakovanih učinkov, potem vidimo, da ta krivulja prej doseže svoj vrh in da je krivulja strmejša, kar pomeni, da so pričakovani učinki večji kot pričakovani učinki po standardni metodi. Pričakovani učinki so v prvem delu večji predvsem zaradi tega, ker ni toliko napak po zagonu v živo, kot je napak pri standardni metodi in zaradi izobraževanja končnih uporabnikov, ki so del uvajanja rešitve ERP. Višji vrh krivulje pa dosegajo zaradi nadgradenj in popravkov, ki jih rešitve ERP omogočajo. Višje pričakovane učinke po enakem obdobju uporabe rešitve ERP oziroma IS-a vpeljanega s standardno metodo pričakujemo tudi zaradi tega, ker so rešitve ERP izdelane po principu najboljše prakse. Iz zgoraj opisanega lahko pričakujemo, da na lego in strmino krivulje pričakovanih učinkov rešitev ERP vplivajo tudi različni način vpeljave rešitve ERP, kot je npr. pristop velikega poka (angl. big bang), malega velikega poka (angl. mini big bang) in drugi. Na
23
višino in lego krivulje vpliva tudi način uvajanja nove funkcionalnosti, saj lahko uvedemo vse module enega ponudnika rešitev ERP, lahko pa se odločimo za uvedbo več povezanih programskih rešitev, ki jih s kratico imenujemo BoB (angl. Best of Breed). Slika 11: Življenjski cikel rešitve ERP
2.5 Funkcijsko usmerjene celovite informacijske rešitve
Standardne rešitve (angl. standard software) sestavljajo programi, ki so jih razvile programerske hiše ali proizvajalci strojne opreme za anonimni trg. Poleg programov vsebujejo standardne rešitve tudi dodatne ugodnosti in storitve, kot so: podrobna dokumentacija, izobraževanje, pomoč pri namestitvi ter vzdrževanje za vnaprej določeno ceno. Prednosti standardnih rešitev pred zase razvitimi aplikacijami so (Kirchmer, 1999):
• nižji stroški uvajanja standardne rešitve, saj se razvojni stroški rešitve delijo med vse kupce;
• posvojitev standardne rešitve je neprekinjena, saj je vsak korak poznan, zato ga lahko planiramo oz. se mu izognemo;
• nižji stroški vzdrževanja; • skrajšan čas procesa nabave; • manjši pritisk na oddelek IT, da reši nestandardne probleme glede procesiranja
podatkov; • zaščita investicije; • vključuje podatkovno in funkcijsko integracijo; • zmogljivost standardne rešitve temelji na tako imenovani najboljši praksi (angl.
best practice); • uporaba najnovejše programske tehnologije; • vsi uporabniški vmesniki imajo enako zasnovo in obliko ter zagotavljajo visok
ergonomski standard; • ponavadi vključuje tudi programe za osebno rabo, kot je npr. odjemalec za
elektronsko pošto itd. Pojavljajo pa se tudi naslednje slabosti standardnih rešitev (Kirchmer, 1999): navzkrižje med standardno rešitvijo in uporabniškimi zahtevami, problemi z vmesniki med standardnimi rešitvami oz. med standardno rešitvijo in zase razvitimi programi, skromna
24
zmogljivost standardnih rešitev zaradi ozkih grl med standardno rešitvijo in zase razvitimi programi, omejeni privilegiji uporabnikov, saj jim ni dovoljeno spreminjanje programske kode, odvisnost od proizvajalca standardne rešitve ter zaskrbljenost zaposlenih, da bodo nepotrebni, ker se bo delovni proces standardiziral oz. avtomatiziral. Med standardne rešitve spadajo tudi rešitve ERP. Izbira in uvedba rešitve ERP v organizacijo je pogosto kritična naloga organizacije, saj lahko nastopijo velike težave zaradi neenakosti med procesno usmerjenostjo organizacije in funkcijsko usmerjenostjo standardnih rešitev. Prenova poslovnih procesov temelji na procesni usmerjenosti organizacije, medtem ko danes na trgu prevladujejo funkcijsko orientirane rešitve ERP. Procesni in hierarhični vidik organizacije predstavljata dinamični in statični pogled na organizacijo, kjer procesna organizacija opisuje, kako člani podjetja izvajajo funkcije, medtem ko hierarhična organizacija opisuje, kaj se naj izvaja po oddelkih, skupinah itd. Hierarhična organizacija je ponavadi zgrajena funkcijsko (iz npr. prodaje, proizvodnje, računovodstva itd). Medtem ko je procesna organizacija zgrajena objektno iz npr.: proizvodov (proizvod 1, proizvod 2, itd), kupcev (kupec A, kupec B, itd) ali trgov (trg I, trg II, trg III itd.). Danes je v večini podjetij še vedno prisotna funkcijsko orientirana organizacijska struktura z naslednjimi značilnostmi:
• toga delitev funkcijskih področij, • podrobna delitev dela, • veliko hierarhičnih ravni, • delitev administrativnih in odločitvenih aktivnosti ter delovnega procesa.
Prednosti funkcijsko orientirane organizacijske strukture so: enostavna pravila posameznih procesov, sistematična uporaba orodij in ljudi, natančno določene odgovornosti in manjša stopnja investiranja. Slabosti funkcijsko orientirane organizacije so: zahtevna koordinacija med procesi, slaba fleksibilnost, malo izkušenj administrativnega dela organizacije o operativnem delu organizacije ter veliko vmesnikov za pretok informacij. Kot smo omenili že zgoraj, pa je poslovni proces definiran kot niz opravljenih funkcij znotraj organizacijske enote. S primerno procesno logiko se uporabijo le nujno potrebni podatki in pravila ter opustijo nepotrebna opravila, kot npr. proces naročila se začne z vnosom kupčevega naročila in konča z dostavo izdelka h kupcu. Ker je posamezen oddelek odgovoren za celoten poslovni proces, se zmanjša število vmesnikov med organizacijskimi enotami. Tisti vmesniki, ki so še vedno potrebni med organizacijskimi oddelki, pa se poenostavijo. Rezultat procesno orientirane organizacije so organizacijske enote deljene na proizvode, trge ali kupce. Ker je vsaka organizacijska enota samostojna, mora biti tržno usmerjena. Proizvodi morajo biti konkurenčni na trgu, zato se organizacijske enote osredotočijo na poslovanje (t. i. profitni centri). Vsi podatki, ki se nanašajo na posamezni poslovni proces, so združeni znotraj te organizacijske enote. Poleg tega lahko znotraj organizacijske enote ves čas nadzorujemo poslovne cilje, stopnjo razvoja, spreminjamo in opuščamo dele poslovnega procesa. Procesna usmerjenost vodi zaposlene v večjo usposobljenost, zmanjša se število kontrol, saj ni kontrol med organizacijskimi enotami, poveča se fleksibilnost ter se zmanjša število nivojev v organizacijski hierarhiji (Kirchmer, 1999). Ker so bile v preteklosti skoraj vse organizacijske strukture funkcijsko usmerjene (pogosta praksa še danes), je to dejstvo vodilo programerske hiše, da so razvile funkcijsko usmerjene rešitve ERP. Najprej so bili razviti programi za posamezne poslovne funkcije,
25
kot npr. finance in računovodstvo. Kasneje pa so programerske hiše razvile rešitve ERP, kjer je ostalo osnovno vodilo pri izdelavi funkcijska usmerjenost. Danes so programski moduli rešitve ERP med sabo povezani, uporabljajo skupno podatkovno bazo in vendar se nanašajo na posamezne funkcije. Takšne rešitve so poznane kot funkcijsko usmerjene celovite standardne rešitve (angl. function integrated standard software), kar vidimo na sliki 12. Slika 12: Funkcijsko usmerjen razvoj standardnih rešitev
Vir: Prirejeno po Kirchmer (1999, 20) Funkcijska orientiranost v standardnih rešitvah je v konfliktu s procesno razvito organizacijsko strukturo, kot smo jo opisali zgoraj. Moduli standardnih rešitev omogočajo poslovanje po funkcijskih področjih proizvodnih linij in trgov ter s tem manjšajo prepad med funkcijsko usmerjenimi standardnimi rešitvami in procesno usmerjeno organizacijo oz. poslovanjem. SLIKA 13: Funkcijski in procesni pogled na podjetje
Vir: Prirejeno po Skok et al (2001, 4)
26
Standardni programski moduli tako zajemajo podatkovno integracijo, integracijo podatkovnih struktur, funkcijsko integracijo, modularno integracijo ter standardizirane vmesnike. Nadalje omogočajo porazdeljeno procesiranje podatkov na arhitekturi odjemalec/strežnik; dinamično prilagajanje parametrov (konfiguriranje), moduliranje, standardizacijo okolja sistema, dinamično nameščanje sistemskih popravkov ter dinamično dodeljevanje uporabniških pravic. Za njih je značilna tudi velika usmerjenost v zaposlene, kar se kaže v uporabniško prijaznih standardiziranih grafičnih vmesnikih, ki delujejo v »on-line« načinu in zato imajo zaposleni na voljo tudi »on-line« dokumentacijo. Eden izmed najbolj poznanih predstavnikov funkcijsko usmerjenih celovitih rešitev je rešitev mySAP ERP (oz. SAP R/3), ki vsebuje module, kot so: finančno računovodstvo, kadrovski sistem, proizvodnja in logistika, prodaja in distribucija itd. Ponavadi se z uvedbo rešitve ERP spremeni tudi organizacijska struktura organizacije iz funkcijsko orientiranega poslovanja v procesno orientirano poslovanje. Organizacije so bile oz. so organizirana po funkcijah, medtem ko rešitve ERP podpirajo procesno orientirano poslovanje, kar vidimo tudi na sliki 13.
27
3 UVAJANJE CELOVITIH INFORMACIJSKIH REŠITEV
3.1 Potek uvajanja celovitih informacijskih rešitev Raziskave kažejo, da velik odstotek projektov uvajanja novih IS oz. tudi prenova IS, ni izvedena v predvidenem času, s predvidenimi stroški ali v predvidenem obsegu. Organizacija Standish Group International Inc. je v raziskavi prišla do zaključka, da je bilo 28 odstotkov vseh podjetniških razvojnih 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 (Whiting, 1998; povzeto po Laudon et al, 2000, 400). 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,82). Frederick Brooks je opozoril, da imajo informacijski projekti določene značilnosti, ki jih dela drugačne od drugih projektov (Brooks, 1987, 10-20, povzeto v Cotterell et al, 1995, 3). Te značilnosti so:
• nevidnost, saj pri razvoju IS napredka ni moč videti, • kompleksnost in • prilagodljivost (oz. fleksibilnost) informacijskih projektov, kar pomeni, da lahko
programe relativno enostavno spremenimo, kar štejemo kot eno izmed programskih moči.
Če imamo na voljo 2 možnosti: spremeniti IS ali npr. strukturo organizacije, se ponavadi odločimo za spremembo programa. To pomeni, da so programi pogosto predmet velike stopnje sprememb. Problemi, ki se lahko pojavijo pri uvajanju ali prenovi informacijskih projektov, so lahko (povzeto po raziskavi Thayera, Pystera in Wooda, povzeta v Cotterell et al, 1995, 8):
• slaba ocenitev in planiranje informacijskega projekta, • pomanjkanje standardov za preverjanje kakovosti, • pomanjkanje smernic o načinu sprejemanja organizacijskih odločitev, • pomanjkanje tehnik za spremljanje napredka projekta, • slabo definirane vloge v projektni skupini (kdo dela kaj), • napačna opredelitev dejavnikov uspeha in drugo.
Potek uvajanja rešitev ERP lahko delimo v dva večja sklopa (slika 14):
1. »izbira rešitve ERP«, kjer mora organizacija na osnovi potreb izbrati zanje najprimernejšo rešitev ERP. Ta sklop se konča s podpisom pogodbe z izbranim ponudnikom rešitve ERP. Sklop izbire rešitev ERP bo podrobneje opisan v poglavju »Izbira in nakup celovitih informacijskih rešitev« (stran 43) in
2. »uvedba rešitve ERP«, kjer ponudnik rešitve ERP in organizacija uvedeta rešitev ERP po vnaprej znani metodologiji. Ta sklop se konča z zagonom v živo. Ta sklop bomo podrobneje opisali v poglavju »Metode uvajanja celovitih informacijskih rešitev« (stran 43).
28
SLIKA 14: Potek projekta uvajanja rešitve ERP
Vsem projektom uvajanja rešitev ERP so danes skupne aktivnosti in cilji (Anderegg et al, 2000, 84). Aktivnosti so vse značilnosti, ki sestavljajo projekt. Glavne aktivnosti faz uvajanja rešitev ERP glede na faze življenjskega cikla so predstavljene v tabeli 4. V tabeli prikazujemo tudi proces izboljšav, ki sledi zaključku projekta uvedbe rešitve ERP. TABELA 4: Glavne aktivnosti v procesu uvajanja rešitve ERP
Faza
življenjskega cikla
Fokus Aktivnosti
PRO
CES
IZ
BIR
E
Opredelitev potreb Zahteve
Razlogi za odločitev Opredelitev stroškov in določitev prednosti Določitev zahtev
Izbira ponudnika Ponudbe
ponudnikov in prileganje rešitev
Oblikovati potek izbire Izvesti izbiro Aktivnosti ob podpisu pogodbe
PRO
CES
UV
EDB
E
Uvedba
Priprava in vzdrževanje pogojev za
projekt uvedbe
Določiti organizacijo projektnega tima in opredeliti njihove vloge Vzpostaviti, nadzirati in vzdrževati podporo projektu Določiti obseg Pripraviti, nadzirati in posodabljati plan Osnovati, nadzirati in posodabljati proračun projekta Izpostavitev in urejanje problemov, ki se pojavijo ob uvajanju Merjenje in urejanje zmogljivosti Urejanje odnosa z izbranim ponudnikom rešitve ERP Namestitev in priprava strojne opreme, programske opreme in omrežja Razviti strategijo izobraževanja
Projektni plan uvedbe
Izobraževanje projektnega tima Opredeliti in razviti procese Prilagoditi rešitev ERP Pripraviti dokumentacijo Izobraževanje uporabnikov Prenos podatkov iz obstoječih IS
Zagon v živo Reševanje problemov Revizija
PRO
CES
IZ
BO
LJŠA
V
Aktivnosti po zagonu
Zmogljivost procesa
Izboljšati procese
Velik vpliv na uspeh projekta ERP pa imajo tudi cilji projekta, ki so lahko:
• čas uvajanja projekta, • obseg projekta, • viri projekta, • riziko projekta, • zahtevnosti projekta in • prednosti, ki jih prinaša nova rešitev ERP.
POTREBEMEJNIK MEJNIK
PROCES IZBIRE
PROCES UVEDBE
PODPIS POGODBE ZAGON V ŽIVO
29
Čas uvajanja projekta je čas, ki je namenjen izvedbi projekta uvajanja rešitve ERP. Določen je z datumom zagona rešitve ERP v živo. Obseg projekta vsebuje vse funkcijske in tehnične zmogljivosti, ki jih želimo uvesti. Viri projekta so ljudje, strojna in programska oprema, tehnična pomoč in svetovalci, ki so potrebni pri uvedbi. Riziko projekta je faktor, ki ima vpliv na splošni uspeh uvedbe. Uspeh lahko merimo na naslednje načine: kako so zaposleni sprejeli ERP sistem, ROI11 oziroma merimo čas, ki je bil potreben za uvedbo. Zahtevnost projekta je stopnja težavnosti uvedbe in vzdrževanja programov ter prednosti, ki jih prinaša nova rešitev ERP. Med zgoraj naštetimi cilji lahko obstaja pozitivna, nevtralna ali negativna korelacija kot je prikazano v tabeli 5. TABELA 5: Odvisnost ciljev
Prednosti Viri Riziko Zahtevnost Hitrost Obseg Prednosti + 0 0 0 +
Viri 0 + 0 + Riziko + + +
Zahtevnost - + Hitrost - Obseg + = pozitivna korelacija, 0 = nevtralna korelacija, - = negativna korelacija
Vir: Prirejeno po Anderegg et al (2000, 55) Različne kombinacije strateških ciljev vodijo podjetja do različnih standardnih strategij izbire in uvedbe rešitev ERP, ki so lahko (Anderegg et al, 2000, 58):
• hitra strategija (angl. breakneck strategy), • strategija zvezde (angl. star strategy), • strategija na ključ (angl. turnkey strategy), • strategija pristopa v hiši (angl. in-house approach strategy), • strategija proračuna (angl. budged strategy), • strategija partnerstva (angl. partner approach strategy) in • strategija majhnega rizika (angl. low risk strategy).
Strategije izbire in uvedbe rešitev ERP bomo opisali v nadaljevanju poglavja.
3.2 Strategije uvajanja celovitih informacijskih rešitev
3.2.1 Hitra implementacija
Današnja poslovna dinamika sili organizacije, da nimajo časa uvajati rešitev ERP več let. Uvajanje rešitve ERP, ki traja več let, ponuja konkurenci organizacije možnost, da prevzame njihovo mesto na trgu. Kot navaja Web (1998), izkušnje kažejo, da dolgotrajno uvajanje povečuje riziko neuspeha projekta uvedbe rešitve ERP, povečuje vpliv sistemske funkcionalnosti in/ali integracije ter zmanjšuje zavzetost in zaupanje projektnega tima v uspeh projekta uvedbe rešitve ERP. Zaradi tega so se ponudniki rešitev ERP in sistemski integratorji12 odzvali na potrebo organizacij po hitri in enostavni uvedbi rešitev ERP. Pripravili so metodologije, ki temeljijo na hitri strategiji. Ideja hitre strategije je, da organizacija najde in uvede rešitev ERP kolikor hitro je mogoče in najceneje, kot je mogoče. Prednosti hitre strategije so (Anderegg et al, 2000, 84): enostavnost, hitrost, zahteva malo planiranja in nizki začetni stroški. Medtem ko so glavne slabosti te strategije: velik riziko,
11 Koeficient rentabilnosti oz. s kratico ROI (angl. Return of Investment). 12 Namesto sistemski integratorji (angl. system integrator) uporabljajo nekateri avtorji izraz partnerji.
30
ogromna količina predelav, organizacijsko zavračanje, problemi z zmogljivostjo rešitve ERP ter funkcijski problemi. Danes uporablja večina podjetij pri uvajanju rešitev ERP hitro strategijo zaradi naslednjih razlogov (Anderegg et al, 2000, 58 in 84; Shields, 2001, 32 in 255):
• ostali pristopi so se izkazali za manj uspešne, • ekonomija elektronskega poslovanja zahteva hitre rešitve problemov, • pravilo 80/20, ki je v pomoč manjšim projektom13 in • hitra uvedba prinaša poslovne prednosti hitreje kot ostale strategije.
Ponudniki rešitev ERP, ki uporabljajo to strategijo pri uvajanju, jo imenujejo kar hitra implementacija (angl. rapid implementation). Hitra implementacija vsebuje majhno število faz, ki jih ponavadi uvedemo po pristopu velikega poka oz. malega velikega poka14. Vodilni ponudniki rešitev ERP in svetovalne hiše imajo na osnovi hitre strategije izdelane svoje metodologije uvajanja, ki vključujejo vsa potrebna orodja za uvajanje, predloge za modeliranje, vmesnike in integracijo. V tabeli 6 so naštete metodologije vodilnih ponudnikov rešitev ERP in svetovalnih hiš. TABELA 6: Seznam metodologij ponudnikov rešitev ERP in svetovalnih hiš
Ime rešitve Ime metodologije SAP MySAP.com Accelerated SAP oz. s kratico ASAP Microsoft Microsoft Navision Microsoft Business Solution Implementation
Methodology oz. s kratico MBS Implementation Methodology15
svetovalna hiša Ernst & Young The total solution svetovalna hiša Deloitte&Touche Fast track workplan Vsem metodologijam je skupna osnovna razdelitev na več faz (angl. work breakdown structure), ki se odvijajo pred, med in po uvedbi rešitve ERP. Strukturo faz lahko razdelimo v tri sklope (slika 15)16:
1. pred-projektne aktivnosti, kamor spada faza Zaveze; 2. projektne aktivnosti, ki jo sestavljajo faze: Začetek, Vodenje, Analiziranje,
Konfiguriranje, Testiranje, Spremembe, Pomoč, Pretvorba, Priprava in Zagon v živo ter
3. po-projektne aktivnosti, kamor spada faza Izboljšav. I. Zaveza. Preden začne organizacija s projektom uvedbe rešitve ERP je potrebno izpeljati nekaj aktivnosti, ki jih bomo opisali v nadaljevanju. Najprej je potrebno izbrati projektnega managerja in pridobiti člane projektnega tima. Poleg izbire ustreznega projektnega tima mora podjetje v fazi pred uvedbo rešitve ERP pripraviti tudi poslovni plan, ki je osredotočen na tiste cilje, ki prinašajo največje koristi (merljive in nemerljive koristi). Prednosti priprave poslovnega plana so:
13 Pravilo 80/20 govori o tem, da 80 % poslovnih koristi novega sistema prinaša 20 % transakcij paketa, 80 % sistemskih napak bo odkritih v 20 % testnih scenarijev, 80 % časa bo porabljenega za 20 % opravil itd. 14 Posamezni pristopi so podrobneje opisani v poglavju »Pristopi k uvajanju celovitih informacijskih rešitev« na strani 75. 15 Preden je podjetje Microsoft prevzelo rešitev Navision, se je metodologija imenovala »Navision OnTarget«, danes pa se imenuje MSB Implementation Methodology. Še danes pa večina uvajalcev rešitve Microsoft Navision uporablja izraz »OnTarget« namesto MSB Implementation Mehtodology. 16 Strukturo faz smo povzeli po Shieldsu (2001, 33) in jo bomo v nadaljevanju na kratko razložili.
31
• predvideva pot projekta, • predvideva druge koristi projekta ter • vodi tim k tistim procesom, na katere morajo biti pozorni.
Poleg tega je potrebno pripraviti delovno sobo za projektni tim (angl. war room), v kateri bo projektni tim lahko testiral razvojno in testno verzijo programa. V primeru, da podjetje ne more pravočasno zagotoviti ustrezne delovne sobe, potem jo lahko najame pri ponudniku programskih storitev. Pripraviti je potrebno tudi začetni projektni plan, ki vsebuje: plan kriznega managementa, delovni plan in organizacijsko strukturo projekta. SLIKA 15: Zemljevid hitre implementacije
Vir: prirejeno po Shields (2001, 35) II. Začetek. Začetek uvajanja se začne z zagonskim sestankom razširjenega projektnega tima (angl. kickoff meeting). Nato sledi osnovno usposabljanje članov glavnega projektnega tima. Usposabljanje ponavadi traja 4 do 5 dni in pokriva metodologijo in pristope uvajanja rešitve ERP, ki bodo uporabljeni v projektu. Izobraževanje se lahko izvede pri ponudniku rešitve ERP (izobraževanje splošne funkcionalnosti paketa) ali v organizaciji, kjer ponudnik pripravi prilagojeno rešitev (tisto, ki bo po funkcionalnosti ustrezala organizaciji). III. Vodenje. Ta faza vključuje planiranje in kontrolo projekta, ki ga izvaja projektni manager. Orodje, ki ga pri tem uporablja projektni manager, se imenuje projektni delovni plan. Projektni delovni plan vsebuje časovni seznam vseh opravil, ki jih je potrebno opraviti med uvedbo. V delovnem planu projekta so določena ključna opravila, čas, viri projekta in status projekta. Delovni plan vsebuje dve ravni: pregledni plan in podrobni plan, ki mora vsebovati vse projektne aktivnosti. Projektni manager mora pri pripravi opravil paziti, da nobeno opravilo zaradi pravila 80/2017 ne bo trajalo več kot 2 dni. IV. Analiziranje. Projektni tim določi, kako bo dosegel vizijo in cilje, ki so bili določeni v prejšnjih fazah ter kako bo izboljšal poslovni proces in rešil poslovne probleme. To lahko naredi z analizo praznin (angl. gap analysis), v kateri primerja obstoječe poslovne procese, prihodnje poslovne procese ter zmožnost rešitve ERP (O'Leary, 2000, 105). 17 Pravilo 80/20 govori med drugim tudi o tem, da pride 80 % poslovnih koristi novega sistema v 20 % časa.
32
V. Konfiguriranje. Konfiguriranje je proces, v katerem prilagodimo rešitev ERP našim potrebam. Vsaka rešitev ERP vsebuje več tisoč parametrov, ki jih je potrebno nastaviti. Za nastavitev parametrov lahko uporabimo 3 pristope konfiguracijskih vprašanj (Anderegg et al, 2000, 22):
• ročni pristop, • delno avtomatiziran pristop in • avtomatiziran pristop.
V ročnem pristopu ima ponavadi ponudnik ERP seznam vprašanj, ki so povezana s funkcionalnostjo organizacije. Obravnava jih skupaj s projektnim timom. Ponavadi so vprašanja sestavljena tako, da so odgovori že povezani s konfiguracijskimi parametri. V delno avtomatiziranem pristopu se uporablja isti pristop kot pri ročnem, vendar rezultate vnesejo v računalniški sistem in potem program avtomatsko nastavi konfiguracijske parametre. V avtomatiziranem pristopu projektni tim, lahko tudi s pomočjo svetovalcev, odgovarja na vprašanja objektivnega tipa preko računalnika in ko odgovori na vsa vprašanja, rešitev ERP avtomatično posodobi konfiguracijske nastavitve. VI. Testiranje. Testiranje obsega več korakov, pri katerih morajo sodelovati tudi ključni uporabniki. Ti koraki so:
• kreiranje testnih primerov, • priprava testnih podatkov, • definiranje pričakovanih rezultatov, • testiranje, • evalvacija testiranih rezultatov, • popravljanje problemov in • ponovno testiranje ter dokumentiranje testiranja.
Aktivnosti faz analiziranja, konfiguriranja in testiranja se ponavljajo tako dolgo, da ustrezajo vsem zastavljenim pričakovanjem na začetku projekta uvedbe. Nato projektni tim shrani konfiguracijske nastavitve in jih dokumentira. VII. Spremembe. Z uvedbo rešitve ERP v organizacijo pride ponavadi do treh vrst sprememb:
• tehnoloških sprememb, • procesnih sprememb in • sprememb organizacijske strukture.
Da se projektni tim izogne neuspešni uvedbi, mora posvetiti pozornost naslednjim področjem: • preveriti moramo, kdo so zavezniki in nasprotniki uvedbe rešitve ERP v organizaciji, • zagotoviti udeleženost ključnih uporabnikov med uvedbo, • zagotoviti komunikacijo med člani razširjenega projektnega tima, • pripraviti dokumentacijo in • izobraževati končne uporabnike.
Komunikacija med člani projektnega tima obsega sestanke, statusna poročila, okrožnice, elektronsko pošto itd. Osnovna dokumentacija mora biti dostopna s strani ponudnika rešitev ERP v obliki sistemskih priročnikov. Pogosto so informacije dostopne tudi v elektronski obliki, ki si jih lahko organizacija prilagodi svojim potrebam. Uporabnikom rešitve ERP je potrebno zagotoviti ustrezno izobraževanje, če želimo, da bo projekt uspel. Dobro izobraževanje zahteva kakovosten izobraževalni material in dobro pripravljene inštruktorje s strani projektnega tima, če je mogoče, oz. svetovalce/učitelje s strani ponudnika ERP.
33
VIII. Pomoč. Pomoč se nanaša na aktivnosti oddelka IT. Kljub temu, da je uvedba ERP rešitev poslovno voden proces, vseeno predvideva precejšen poudarek na informacijski tehnologiji. V prvi fazi mora oddelek IT pripraviti delovne postaje za vse člane tima ter razvojni strežnik v delovni sobi. V času uvajanja pa mora:
• kreirati razvojno, testno in produkcijsko instanco18, • določiti pravice dostopa do novega sistema, • pripraviti varnostne kopije, • napisati programe za pretvorbo podatkov, • iskati potencialne sistemske napake, • pripraviti specialna poročila in obrazce z uporabo orodij, ki jih predvidi ponudnik, • razvoj programskih vmesnikov itd.
Oddelku IT lahko pri določenih opravilih pomagajo tehnični svetovalci za podatkovne baze, varnost, operacijske sisteme itd. Če se ugotovi, da organizacija ne more zagotoviti ustrezne podpore s strani oddelka IT, potem je smiselno, da razmisli o najemu sistema pri ponudniku programskih storitev19. IX. Pretvorba. V tem koraku je potrebno pretvoriti podatke iz obstoječega sistema v podatkovno bazo novega sistema. Pretvorba podatkov obsega pet korakov:
1. Potrebno je preučiti, katere podatke iz obstoječega sistema potrebujemo v novem sistemu in kje jih najdemo.
2. Podatke je potrebno očistiti, saj so podatki v obstoječih sistemih večkrat netočni, se ponavljajo (so redundantni), nesistematični ali ne vsebujejo vseh potrebnih atributov.
3. Sledi polnjenje podatkovne baze novega sistema, ki lahko poteka na tri načine: avtomatično, preko vmesnikov ali ročnega vnosa.
4. Verifikacija podatkov, kar pomeni pregled točnosti in celovitosti podatkov. 5. Nazadnje sledi še sinhronizacija, kjer moramo na dan zagona v živo imeti vse
potrebne podatke v podatkovni bazi novega sistema. Statične podatke, kot so podatki o kupcih, dobaviteljih itd., lahko v organizaciji prenesejo v novo bazo pred zagonom v živo, ne morejo pa prenesti dinamičnih podatkov, kot je npr. odprto naročilo, ki ga morajo prepisati v novo bazo na dan zagona v živo. X. Priprava. Ključna opravila, ki jih je potrebno opraviti pred zagonom v živo se nanašajo na testiranje vseh delov (veliko število različnih procesov) – integracijski test, učenje končnih uporabnikov (2 do 4 tedne pred zagonom v živo), pripravo produkcijskega okolja, pretvorbo podatkov in vzpostavitev zunanje pomoči. XI. Zagon v živo. Zagon v živo je dan, ko se začne uporabljati nov sistem v organizaciji. Organizacija mora pričakovati, da se bodo ne glede na obsežno pripravo in planiranje pojavili problemi. Predvsem bodo zaposleni potrebovali veliko pomoči v dneh po zagonu v živo, zato bo organizacija potrebovalo več strokovnjakov, ki bodo poskušali rešiti nastale probleme. Ko se problemi umirijo, je smiselno narediti tudi revizijo uvedbe in tako izboljšati možnosti za uspeh novih uvedb. Smiselno je organizirati tudi zaključni projektni sestanek in na njem predebatiriati dobre in slabe strani projekta. XII. Izboljšave. Obsega pomoč po uvedbi ter nadaljevanje izobraževanja in vzdrževanja rešitve ERP. Ker pa se bo podjetje verjetno kmalu odločilo za novo uvedbo rešitve ERP, je
18 Instance so različne verzije aplikacije, ki se uporabljajo med uvedbo novega IS-a. 19 Za ponudnike programskih storitev se uporablja tudi kratica ASP (angl. Application Solution Provider).
34
smiselno, da pretehta tudi koristi in stroške hitre implementacije preden začne z novo hitro implementacijo.
3.2.2 Druge strategije
Strategija malega rizika20 (angl. loe risk strategy) ima veliko število korakov in je zapletena. Čas uvajanja je približno dve leti. Sestavljena je iz skoraj vseh posameznih korakov, ki jih lahko ima projekt uvedbe rešitve ERP. V to strategijo sta vključena tudi proces revizije in veliko število aktivnosti, ki se izvajajo sočasno. Celoten obseg projekta je lahko razdrobljen v manjše podrobnosti, kot jih predvideva podrobni projektni plan. Prednosti strategije malega rizika so: bolj točno napovedljivi rezultati, manjše polzenje obsega, boljše prilagajanje proračunu, manj razdiralen za poslovanje, doseganje maksimalnih prednosti in malo velikih presenečenj. Vključuje pa tudi nekaj slabosti: dolgotrajna uvedba, konceptualno težka za učenje, zahteva podporo uprave, zahteva predane vire in je draga. Strategija proračuna (angl. budget strategy) je podobna hitri strategiji v meri, da je tudi pri njej relativno malo število korakov. Njen glavni cilj je uvesti rešitev ERP z najmanjšim možnim proračunom. Tako vključuje tudi korake, ki dodajajo rešitvi vrednost in ne povzročajo stroškov. Aktivnosti strategije proračuna so: RFI in splošna raziskava, analiza ROI, raziskava referenc ponudnikov, demonstracija rešitve ERP, proces izbire, pogajanje ob podpisu pogodbe, namestitev, odgovori na vprašanja konfiguracije, pretvorba podatkovne baze in zagon v živo. Prednosti strategije so: enostavna, zahteva malo planiranja in nizki začetni stroški. Slabosti te strategije so: visoki riziko, zelo dolgo uvajanje, ogromna količina predelav, organizacijsko zavračanje, problem z zmogljivostjo ter funkcijski problemi. Strategija lastnega razvoja (angl. in house strategy) vključuje programerje organizacije, da razvijejo rešitev na ravni izvorne kode. Vključuje malo število korakov: analiza potreb, poslovno integracijsko planiranje, vizijo in poslanstvo, funkcijsko mapiranje, testiranje in prototipiranje, prilagajanje programja, pretvorbo podatkovne baze, izobraževanje končnih uporabnikov, zagon v živo in podporo v času delovanja. Strategija lastnega razvoja je opazno drugačna od hitre strategije in strategije proračuna, ker vključuje ključne elemente uvajanja rešitve ERP, kot je funkcijsko mapiranje, testiranje in prototipiranje in programske prilagoditve. Uvajanje po strategiji lastnega razvoja lahko traja precej časa zaradi razvoja rešitve in razhroščevanja v času podpore delovanja. Prednosti strategije lastnega razvoja so: zahteva uporabo ključnih elementov uvajanja rešitev ERP, gradi močne tehnične vire, se prilega poslovnim procesom, izvorna koda je ponavadi jedrnata in sili organizacijo v križne komunikacije. Slabosti te strategije so: visok riziko, veliko podpore v času delovanja, ranljiv obrat za zaposlene, nefleksibilen, počasi osvaja tehnologijo, ni zunanje dobro obveščene pomoči in pomanjkanje integracije. Strategija zvezde (angl. star strategy) ima podobne aktivnosti in zaporedni red kot strategija malega rizika, s poudarkom na ciljih napredovanja. Prednosti te strategije so: nizek riziko, veliko prednosti, predvideni rezultati, gradi močno bazo znanja, visoka stopnja uporabniškega lastništva in močna integracija. Slabosti te strategije so: je draga, organizacijske vire lahko močno izpostavi pritisku, psihološko naporno. Strategija na ključ (angl. turnkey strategy) ima podobno strukturo in cilje kot strategija malega rizika. Glavna razlika je, kdo izvaja večino aktivnosti in planiranje projekta uvajanja rešitve ERP. Uvajanje po strategiji na ključ vedno vključuje zunanje vire za planiranje in 20 Druge strategije smo povzeli po Andereggu et al (2000, 85 – 91).
35
uvajanje rešitve. Prednost te strategije je, da organizacija potrebuje malo notranjih virov. Slabosti pa so: visok riziko, draga, pomanjkanje lastništva, predelave in manjkajoča funkcionalnost, sovražen odnos zaposlenih in je ranljiv v primeru ponudnikovega obrat.
3.3 Projektna organizacija Shields (2001, 105) navaja, da je eden izmed razlogov za probleme pri informacijskih projektih nerazumevanje odnosov med predvidenim obsegom projekta, vir projekta in časom za dokončanje projekta. Na sliki 16 vidimo, da s spremembo enega izmed odnosov pride tudi do sprememb v drugih dveh. SLIKA 16: Odnosi med obsegom projekta, viri projekta in časom za izvedbo projekta
Vir: prirejeno po Shields (2001, 105-106) Na primer, če v projektu zamujamo z dokončanjem opravil v časovnih rokih, potem se bodo zaradi zamude povečali viri projekta ali zmanjšal obseg projekta, kar pa ponavadi ne želimo. Isti avtor tudi navaja, da se lahko kljub temeljnim odnosom med časom, viri in obsegom oblika trikotnika spremeni z dodatno spremenljivko - s projektnim managementom (slika 17)21. Uvajanje rešitve ERP vključuje niz aktivnosti, ki ponavadi niso vključene v normalni poslovni krog aktivnosti v organizaciji. PM sestavlja projektna organizacija, obseg projekta, projektni plan, proračun projekta, reševanje problemov v zvezi s projektom, ocenitev rizika, zmogljivost ter urejanje ponudnikov (Harwood, 2004, 98). PM v večini informacijskih projektov ni dovolj dobro izveden. Z izjemnim PM lahko dosežemo celo to, da se v predvidenem času in s predvidenimi viri poveča obseg projekta ali pa da se z manjšimi viri in v krajšem času doseže vnaprej določen obseg. SLIKA 17: Učinek dobrega projektnega managementa
Vsak projekt uvajanja rešitve ERP je sestavljen iz dveh podprojektov: (1) izbira rešitve ERP in (2) uvedba rešitve ERP. Oba podprojekta sta najhitreje izvedena, če se jih lotimo kot projekta z jasnimi cilji in določenimi časovnimi okvirji. Tako lahko imamo dva ločena projektna tima, ki sta:
1. projektni tim za izbiro rešitve ERP in
21 Za projektni management bomo v nadaljevanju poglavja uporabljali kratico PM.
36
2. projektni tim za uvedbo rešitve ERP. Ker pa mora že projektni tim za izbiro rešitve ERP dobro poznati funkcionalnost rešitev ERP in poslovne procese organizacije, ponavadi organizacija po izbiri rešitve ERP, razširi projektni tim za izbiro z dodatnimi člani, ki nato uvaja rešitev ERP. Projektni tim za izbiro rešitve ERP je sestavljen iz ljudi, ki predstavljajo ključne dele organizacije: management, ključne poslovne funkcije, IS in ključne uporabnike novega sistema. Glavne vloge v projektu izbire so (Shields, 2001, 88-90):
• Sponzor projekta (angl. project sponsor), ki je član uprave in ni z oddelka IT. Njegova naloga je, da sprejema hitre odločitve ter da pomaga premostiti ovire in rešiti probleme v procesu izbire.
• Nadzorni odbor (angl. steering committtee) je sestavljen iz funkcijskih managerjev področij, v katerih bo uvedena izbrana rešitev ERP. Nadzorni odbor se sestane 2 do 3 krat v času procesa izbire in potrdi priporočila projektnega tima za izbiro.
• Projektni manager ureja projekt izbire. Njegova naloga je, da bodo projektna opravila opravljena kakovostno v naprej predvidenem času. Dobro je, da je ta oseba spoštovan manager v organizaciji in je potem tudi glavni kandidat, da nadaljuje delo kot projektni manager v projektu uvedbe izbrane rešitev ERP.
• Svetovalce potrebuje organizacija zaradi treh dejavnikov, ki niso prisotni med njihovimi viri. Ti dejavniki so: (1) imajo metodologijo za izbiro in izkušnje v procesu izbire; (2) vedo, kdo so ključni ponudniki in poznajo njihove rešitve ter lahko pomagajo pri določitvi kratkega seznama ponudnikov; (3) imajo zaposlene, ki imajo izkušnje z uvedbo vseh pomembnejših rešitev na trgu in tako lahko posredujejo vpogled v slabosti in prednosti posameznih rešitev ERP.
• Predstavniki funkcijskih področij morajo dobro poznati poslovni proces organizacije in znati predstaviti svoje poslovno področje v procesnih modelih, določiti zahteve sistema in kriterije za izbiro, razviti demo scenarije in skripte ter morajo ovrednotiti rešitve ERP.
• Ključni uporabniki različnih funkcijskih področij bodo zapolnili veliko lukenj z zagotavljanjem informacij projektnemu timu izbire in tako pomagali pri razvoju zahtev projekta. Njihova vključitev je pomembna, saj so njihovo znanje, razumevanje, ideje in izkušnje zelo pomembne v procesu izbire.
• Predstavniki oddelka oz. službe za informatiko bodo pomagali pri določitvi in izbiri tehničnih zahtev projekta. Kasneje bodo tudi odgovorni za namestitev rešitve ERP in po potrebi za prilagoditev delovanja ostalih IS v organizaciji.
Pri tem lahko več vlog v projektu opravlja ista oseba. Projektni manager in člani glavnega projektnega tima (predstavniki pomembnejših funkcijskih področij) so na projektu zaposleni za polni delovni čas, ostali pa sodelujejo v projektu izbire 2 do 3-krat tedensko. Podrobneje bodo zgradba in naloge projektne organizacije predstavljene v nadaljevanju poglavja za projekt uvajanja rešitve ERP.
3.3.1 Zgradba projektne organizacije
Izbira projektnega tima ima velik vpliv na uspeh uvedbe rešitve ERP pa tudi na vzdrževanje in nadgradnje, ki jih zahteva rešitev ERP (Anderegg et al, 2000, 93; Shields, 2001, 130 in Wallace e tal, 2001, 111). Po raziskavi Deloitte & Touche iz leta 199822 med desetimi
22 Raziskava organizacije Deloitte&Touche je razložena v Shields (2001, 125).
37
najpogostejšimi razlogi za neuspešno uvedbo rešitev ERP ne najdemo odgovorov povezanih s tehnologijo, pač pa z ljudmi. Teh deset razlogov lahko razdelimo v dve skupini, ki sta: (1) rezultati slabega planiranja in (2) rezultati slabe izvedbe uvedbe rešitve ERP, kjer pa igra pomembno vlogo projektna organizacija. Zgradbo projektne organizacije, ki je primerna za hitro uvedbo rešitve ERP, vidimo na sliki 18. SLIKA 18: Razširjena projektna organizacija
Vir: prirejeno po Shields (2001, 130) in Anderegg et al (2000, 101) Projektno organizacijo sestavljajo naslednje skupine projektnih timov:
• vodstveni tim, • tim prenove procesa in podpore ter • zunanji tim.
Vodstveni tim sestavlja:
• nadzorni odbor oziroma naročnik projekta (angl. steering committee), • sponzor projekta (angl. executive sponosor), • projektni manager (angl. project manager), • svetovalci (angl. consulting advisor) in • predstavniki rešitve ERP (angl. vendor representative).
Vodstveni tim je odgovoren za vodenje projekta in za dosego predvidenih poslovnih ciljev organizacije s pomočjo rešitve ERP. Poleg tega daje tudi podporo ostalim timom. Tim prenove procesov in podpore je največji in ga sestavlja več procesnih timov in tehnični tim. Tim prenove procesov in podpore opravil večino dela na projektu uvedbe rešitve ERP.
38
Zunanji tim sestavljajo specialisti, ki jih organizacija najame za pomoč projektnim timom na zahtevnejših področjih uvedbe oziroma za reševanje problemov, do katerih naletijo projektni timi in za katere bi le-ti potrebovali preveč časa. V razširjeni projektni organizaciji sodeluje nekaj polno zaposlenih članov (imenujemo jih tudi glavni tim) in nekaj, ki sodelujejo samo občasno. Pri hitri uvedbi rešitve ERP morajo biti v glavnem timu najboljši predstavniki oddelkov, ki so motivirani, inteligentni, kreativni, delovni, timsko – orientirani ter razumejo poslovanje in strategije organizacije.
3.3.2 Člani projektne organizacije in njihove vloge
Vodstveni tim Projektni manager (angl. project manager) je odgovoren za napredek projekta in doseganje zastavljenih ciljev projekta. Kot navajajo avtorji (Shields, Anderegg, Wallace, Harwood itd.), mora vodstvo organizacije izbrati projektnega managerja, ki zelo dobro pozna poslovanje organizacije in ni informatik v organizaciji, saj je uvedba rešitve ERP poslovni projekt in ne informacijski projekt. Projektnega managerja izberemo na osnovi naslednjih kriterijev (Anderegg et al, 2000; Wallace in Kremzar, 2001): razpoložljivost, poznavanje delovanja organizacije, organizacijsko znanje, politična moč v organizaciji, izkušen manager, dalj časa zaposlen v organizacij, privolitev s strani ponudnika rešitev ERP, komunikacijske sposobnosti, informacijsko pismen in spoštovan v organizaciji. Projektni manager je zaposlen na projektu za polni delovni čas. Njegove naloge se nanašajo predvsem na komuniciranje in koordiniranje vseh virov, ki pa so (Cadle in Yeates, 2001, 39):
• izdelati časovni plan in finančni proračun, • doseganje ciljev projekta v predvidenem času, s predvidenimi stroški in predvidene
kakovosti; • voditi dokumentacijo projekta; • planirati, nadzirati in kontrolirati projekt; • izbrati, graditi in motivirati projektni tim; • obveščati sponzorja projekta in nadzorni odbor o napredku projekta in težavah na
projektu … Nadzorni odbor (angl. steering comittee ali angl. steering counsel) sestavljajo člani uprave organizacije in managerji vseh funkcijskih področij, kjer bomo uvedli rešitev ERP. Naloga nadzornega odbora pred pričetkom projekta uvedbe je, da določi strategijo projekta uvedbe rešitve ERP v odnosu do organizacije in na osnovi tega pripravi vizijo in poslanstvo rešitve ERP. Med projektom uvedbe rešitve ERP pa so naloge nadzornega odbora sledeče (Shields, 2001, 133):
• nadzira status projekta, • sprejema pomembnejše odločitve v zvezi z uvedbo rešitve ERP, • spremlja projektne aktivnosti, pri katerih so vključeni končni uporabniki.
Nadzorni odbor se srečuje enkrat do dvakrat mesečno za eno uro oziroma v času uvedbe lahko tudi pogosteje (do enkrat tedensko). Na sestankih ima standardno agendo, ki vključuje status projekta, rezultate projekta, sprejete odločitve projektnega tima in odločitve, ki jih mora sprejeti nadzorni odbor. Nadzorni odbor obvešča projektni manager, ki poroča o statusu projekta, možnih zaostankih na projektu in različnih možnostih za rešitev zaostankov.
39
Sponzor projekta (angl. executive sponsor) je ponavadi manager iz uprave, ki ne predstavlja posameznega funkcijskega področja, pač pa je odgovoren za področja, na katere bo imela vpliv uvedena rešitev ERP. Sponzor projekta je pogosto tudi vodja nadzornega odbora. Sponzor projekta podpira odločitve projektnega managerja in odstranjuje razne ovire med projektom, kot so npr.: zagotovitev virov, reševanje nesoglasij med nadzornim odborom in ključnimi uporabniki ter sprejemanje hitrih odločitev, za katere projektni manager ni pooblaščen. Sponzor projekta mora sodelovati oziroma biti prisoten na sestankih projektnega tima in večkrat tedensko obiskati projektni tim in preveriti napredek projekta. Aktivna vloga sponzorja projekta omogoča, da le-ta bolje razume težave, ki se pojavljajo ob projektu uvajanja rešitve ERP. Svetovalec (angl. consulting advisor) dopolnjuje sposobnosti in izkušnje projektnega managerja v organizaciji. V projektu uvedbe rešitve ERP je kar nekaj področij, na katerih ima projektni manager manj izkušenj, to so (Shields, 2001, 132):
• manj izkušenj z orodji, tehnikami in metodologijami, ki so uporabljene v hitri implementaciji;
• ima manj izkušenj s velikim – obsežnim projekti; • nima izkušenj, kako uvesti izbrano rešitev ERP; • ni nujno da ima izkušnje v procesu prenove poslovnih procesov, urejanju sprememb in
razvoju infrastrukture IT. Svetovalec v vlogi trenerja vodi projektnega managerja preko številnih potencialnih težav. Lahko je tudi odgovoren za del projekta. Poleg tega lahko skupaj s ponudniki rešitve ERP pomaga poiskati specialiste, ki bodo nadomestili manjkajoče znanje in sposobnosti projektnega tima. Predstavnik(i) ponudnika rešitve ERP (angl. vendor representative) je oseba s strani ponudnika rešitve ERP. Njegova vloga je, da ugotovi, ali je organizacija zadovoljna z njihovo rešitvijo ERP, saj bo potem verjetno tudi podpisala vzdrževalno pogodbo oziroma uvedla dodatne module njihove rešitve ERP. Zato mora predstavnik ponudnika periodično izvajati pregled kakovosti uvedbe rešitve ERP. Ker obiskuje organizacijo občasno, lahko neodvisno vrednoti napredek projekta. V primeru, da projekt naleti na nepričakovane ovire, predstavnik ponudnika pomaga odkriti napake in predlaga (pokliče) strokovnjake, ki pomagajo projektnemu timu razrešiti kompleksne probleme in vrniti projekt v časovne okvire. Ponudnik rešitve ERP mora imeti med svojimi zaposlenimi vrhunske strokovnjake za različna področja rešitve ERP, ki jo uvaja. Vloga tima prenove procesov in podpore Število ljudi v timu prenove procesov in podpore je odvisno od obsega projekta (koliko procesov hkrati prenavljamo). Sestavljen je iz več skupin. Vsaka skupina predstavlja posamezen proces in jo sestavlja vodja procesa, procesni analitiki, analitiki rešitve ERP ter ključni uporabniki. Vodja procesa (angl. process lead) daje in koordinira aktivnosti posameznega procesa. Vloga vodje procesa ni za polni delovni čas. Poleg tega poroča projektnemu managerju in predstavlja procesni tim na skupnih sestankih projekta. Vodja procesa je prva vez z lastnikom procesa in ključnimi uporabniki, ki bodo uporabljali uvedeno rešitev ERP. Skupaj s projektnim managerjem ocenjuje napredek tima in dosežene rezultate ter opredeli potrebne akcije, če projekt sklene z začrtane smeri.
40
Procesni analitiki (angl. process analysts) analizirajo obstoječe poslovne procese in jih prenovijo tako, da upoštevajo poslovne cilje organizacije ter prednosti zmogljivosti rešitve ERP. So strokovnjaki za poslovne procese in metode ter za kreiranje inovativnih rešitev zapletenih poslovnih procesov. Procesni analitiki razvijejo model procesov. Začnejo z industrijskimi modeli in jih spremenijo v modele procesov, kot naj bi bili v organizaciji po uvedeni rešitvi ERP. Simulirajo različne načrte procesov in določijo njihove slabosti in prednosti. Razumejo zahteve poslovanja in izkušnje ljudi, povezanih z menjavo procesov, in poskušajo določiti najboljšo pot za dosego ciljev projekta z minimalnim vplivom na organizacijo in zaposlene. Vedo, katere procese je potrebno zelo spremeniti in pri katerih so potrebne minimalne spremembe. Udeleženi so tudi pri pretvorbi podatkov, testiranju in šolanju končnih uporabnikov. Lahko, ni pa nujno, delajo z rešitvijo ERP. Kljub temu pa se morajo naučiti zmogljivosti rešitve ERP, da lahko določijo kateri načrt procesa je mogoč in najbolj praktičen. Njihova vloga v projektu je osredotočena na poslovanje in načrtovanje procesov v uvedeni rešitvi ERP. Analitik(i) rešitve ERP (angl. package analyst) poznajo zmožnosti in omejitve ERP sistema, ki ga želimo uvesti, razumejo različne možnosti, ki jih omogoča rešitev ERP in znajo prilagoditi rešitev ERP tako, da bo podpirala možnosti, ki so jih določili procesni analitiki. Analitiki rešitve ERP so ljudje, ki imajo predhodno znanje z uvajanjem rešitve ERP. Pomembna vloga analitikov rešitve ERP je, da prenesejo svoje znanje tudi na ostale člane tima. Če podjetje izvaja prvi projekt hitre implementacije, potem analitiki rešitve ERP niso zaposleni organizacije, ampak zunanji svetovalci (pogosto s svetovalnih hiš ali s strani ponudnika ERP rešitve). Analitiki rešitve ERP so ponavadi osredotočeni na eno področje rešitve ERP, zato bo pri uvedbi rešitve sodelovalo več analitikov. Ključni uporabniki (angl. key users ali power users) sodelujejo pri projektu uvedbe rešitve ERP po potrebi in so pomemben vir informacij za glavni tim. Ključni uporabniki so vključeni med uvedbo rešitve ERP, vendar je njihovo vključevanje odvisno od opravil. Tako igrajo pomembno vlogo pri pripravi zahtev, prototipnih rešitvah, čiščenju podatkov, pregledu učnega materiala, predstavitvi učnih sej drugim uporabnikom ter testiranju sistema. Vsekakor morajo biti izbrani tisti ključni uporabniki, ki podpirajo projekt uvedbe rešitve ERP. Tim tehnične podpore (angl. technical support team). V timu prenove procesov in podpore je tudi tim tehnične podpore, ki ga sestavlja od 12 do 15 strokovnjakov IT s področij programiranja, sistemskih analitikov in administratorjev podatkovnih baz, ki so zaposleni na projektu za polni delovni čas. Tim tehnične podpore sestavljajo: tehnični vodja, programerji in administratorji podatkovnih baz ter administratorji rešitve ERP. Tehnični vodja je odgovoren za planiranje in pregled dela vseh članov tima tehnične podpore ter mora koordinirati tehnične aktivnosti z ostalimi v projektni skupini. Je vmesni člen med timom in oddelkom IT in med timom in skupino tehnične pomoči ponudnika rešitve ERP. Tako kot ostali vodje tima, tudi on/ona pripravlja podrobna opravila na projektu. Programerji in administratorji podatkovnih baz so odgovorni za izvajanje večino tehničnih opravil na projektu. Pišejo in analizirajo vmesnike in skrbijo za pretvorbo podatkov iz obstoječega sistema v rešitev ERP. Poleg tega nameščajo popravke rešitve ERP in testirajo te spremembe v testni instanci. Uporabljajo orodja rešitve ERP za izdelavo obrazcev in podrobnih poročil. Poleg tega je ena izmed njihovih ključnih nalog ta, da zagotavljajo primerno hranjenje varnostnih kopij in po potrebi ponovno namestitev sistema in PB. Administrator rešitve (angl. package administrator) namesti programsko opremo izbrane rešitve ERP. Namestitev vključuje vzpostavitev vseh OS in PB s rešitvijo ERP. Nato administrator pripravi in vzdržuje
41
vse različne instance sistema: razvoj (angl. develop), test (angl. test), zagotovitev kakovosti (angl. quality assurance) in produkcijo (angl. production). Vloga zunanjega tima Zunanji tim sestavljajo tri skupine svetovalcev, ki sodelujejo v organizaciji po potrebi, ko jih pokliče projektni manager. Njihova odgovornost je, da poslušajo stranko, postavijo diagnozo problema in nato priporočajo, kako rešiti problem. Njihova vloga v projektu je kritična, saj so zaradi svojih sposobnosti in znanja nepogrešljivi v projektih uvajanja rešitev ERP. V projekt uvedbe so vključeni po potrebi takrat, ko je potrebno rešiti kompleksno opravilo oziroma rešiti problem, s katerim se je srečal projektni tim. Projektni manager mora vedeti, kdaj poklicati svetovalce in kateri profil svetovalcev bo primeren za rešitev problema. Projektni managerji se ponavadi najprej odločijo in pokličejo svetovalce ponudnika rešitve ERP ali pa svetovalce svetovalnih hiš, ker so le-ti cenovno ugodnejši. Kadar pa ti niso dovolj, potem mora projektni manager poiskati pomoč pri drugih svetovalcih. V grobem imamo tri kategorije svetovalcev: svetovalce rešitve ERP, tehnične svetovalce in organizacijske svetovalce. Približno 80 odstotkov časa, ki ga prebijejo svetovalci v organizaciji, je namenjeno poslušanju stranke (Anderegg et al, 2000, 198), kot vidimo na sliki 19. SLIKA 19: Karakteristike svetovalcev
Rang znanja po
izobraževanju
Normalni rang znanja
svetovalcev
100 %
100 %80 %
80 %
20 %
20 %0 %
Poslušati
Govoriti + poslušati
Zakaj
Zakaj + kako
Vir: prirejeno po Anderegg et al (2000, 198) Cilj vključitve svetovalcev v projekt uvedbe rešitve ERP je izobraziti stranke (zakaj rešiti problem na določen način) in ne trenirati (kako rešiti problem). Svetovalci pripravijo alternativne pristope za vse probleme, ki so jim predstavljeni. Svetovalci morajo posredovati informacije na tak način, da lahko sami logično izberemo metodo, ki je najprimernejša za našo organizacijo. Poleg tega pregledujejo napredek in opozarjajo organizacijo, kadar zaide s poti. Vsak svetovalec potrebuje nekaj časa, da bolje razume delovanje organizacije. Dober svetovalec bo hitro opozoril na napake in ponudil več alternativnih rešitev. Projektni manager pa mora izbrati za organizacijo najprimernejšo rešitev problema.
42
Svetovalci za rešitev ERP se osredotočijo na proces komuniciranja, učenja, demonstracij in konfiguriranja rešitve ERP. Pokazali bodo organizaciji, kako potekajo toki poslovnih procesov v rešitvi ERP. Svetovalci rešitve ERP zelo dobro poznajo zmožnosti in zahteve posameznih modulov ponudnikove rešitve ERP. Vedo, kako ti moduli sodelujejo z drugimi moduli rešitve ERP in kako prilagoditi modul, da bo podpiral določen pristop poslovnih procesov. Organizacije jih ponavadi vključijo v uvajanje pri najbolj kompleksnih modulih rešitve ERP, kjer je krivulja učenja najbolj strma, ali pa pri uvajanju novih modulov oziroma modulov, ki ne delujejo tako, kot je zapisano v dokumentaciji. Tehnični svetovalci se soočajo s tehničnimi problemi, kot so: pretvorba podatkovne baze, prilagajanje izvorne kode, komunikacijski protokoli, operacijski sistemi, namestitev rešitve ERP, strojna oprema in integracija programov. Sodelujejo s timom tehnične podpore. Tehnični svetovalci so strokovnjaki za posamezne operacijske sisteme (npr. MS Windows Server 2003, UNIX, …) ali podatkovne baze (npr. Oracle, SQL Sever, …). Pomagajo odpraviti napake v programu, razviti programe za pretvorbo podatkov, nastaviti varnostne mehanizme uvedene rešitve ERP, prilagoditi bazo, da deluje optimalno z rešitvijo ERP, načrtovati omrežno arhitekturo in razvijati vmesnike med deli tehnične arhitekture. Organizacijski svetovalci se osredotočajo na funkcije managementa, ki so povezane z viri organizacije in toki poslovnih procesov. Organizacijski svetovalci pomagajo pri managementu sprememb, ki jih projektni tim ne more oziroma ne zna rešiti. Vključimo pa jih lahko tudi pri pripravi: navodil nove organizacijske strukture, načrta delovnih mest, strategij komuniciranja, tehnik izobraževanja in urnika, ki bo podpiral hitro uvedbo rešitve ERP.
43
4 IZBIRA IN NAKUP CELOVITIH INFORMACIJSKIH REŠITEV
4.1 Razlogi za posodabljanje in prenovo informacijskega sistema
Organizacija se lahko loti projekta prenove IS-a zaradi različnih razlogov, kot so (Khan, 2002, 4):
• pomanjkljiv pretok podatkov med različnimi IS, • neskladnost med IS v organizaciji, • netočni in/ali podvojeni podatki v IS, • ni mogoče dobiti podatke iz IS v realnem času, • omejena možnost nadgradenj obstoječih IS (strojne opreme, programske opreme in
funkcionalnosti), • problemi, ki se pojavijo med povezanimi IS po nadgradnjah, • potreba po sodelovanju med dobavitelji preko IS, • visoki stroški vzdrževanja za neskladne in zastarele sisteme itd.
Lahko pa se organizacija odloči za zamenjavo obstoječih IS, ker se zaveda, da lahko preživi in dolgoročno uspe le, če razvije strategije, ki se prilagajajo petim konkurenčnim vplivom (t. i. Porterjev konkurenčni model). Pri dosegi teh strategij pa lahko organizaciji pomaga tudi zmogljiv IS (O'Brien, 2003, 400). Ti vplivi so:
• konkurenca med podjetji - IS lahko trajno zniža stroške poslovnih procesov, pomaga pri diferenciaciji proizvodov/storitev, omogoča hitrejše iskanje tržnih niš, pospešuje širitev na globalne trge itd. (Robson, 1994, 32);
• vstopne pregrade za nove konkurente - izgradnja zmogljivega IS je po eni strani velika investicija v organizaciji, po drugi strani pa omogoča znižanje stroškov poslovanja organizacije, višjo kakovost poslovanja, skrajša čas proizvodnje oziroma poveča obseg proizvodnje, skrajša pot do dobaviteljev itd. (Robson, 1994, 33);
• vstopne pregrade za nadomestke (substitute) - IS nudi pomoč pri razvoju diferenciacije proizvodov/storitev in vezavi kupcev nase;
• pogajalska moč kupcev - večji odjemalci določijo, kateri IS naj uporabimo, da bo skladen z njihovim IS;
• pogajalska moč dobaviteljev - dobavitelji zahtevajo od organizacije, da jim dovoli vpogled v zaloge, kar pa bi bilo brez ustreznega IS nemogoče.
Kot smo razložili v Poterjevem konkurenčnem modelu, se lahko organizacija odloči za uvedbo novega IS tudi zato, da prehiti konkurente. To lahko stori s pomočjo naslednjih strategij (O'Brian, 2003, 401-403): 1. strategijo stroškov vodenja (angl. cost leadership strategy), kjer postanemo proizvajalec z
najnižjimi proizvodnimi stroški na enoto, saj IS zniža stroške poslovnih procesov in stroške do kupcev ter dobaviteljev;
2. strategijo diferenciacije (angl. differentiation strategy), kjer s pomočjo IS diferenciramo proizvode/storitve;
3. strategijo inoviranja (angl. innovation strategy), kjer lahko IS pomaga pri razvoju edinstvenih proizvodov/storitev ali pa pri vključitvi le-teh na edinstvene trge;
4. strategijo rasti (angl. growth strategy), kjer lahko IS občutno poveča zmogljivost proizvodnje v podjetju, pospeši širitev na globalne trge, pospeši vlaganja v nove izdelke in storitve, itd.
44
5. strategijo zavezništva (angl. allinace strategy), kjer lahko s pomočjo IS vzpostavimo poslovne povezave/zavezništva s kupci, dobavitelji, konkurenti, svetovalci in drugimi podjetji.
Najvišje vodstvo organizacije se na osnovi različnih dejavnikov, ki so bili navedeni zgoraj, odloči za zamenjavo obstoječ-ega/-ih IS. Preden pa poda zeleno luč za začetek projekta izbire in uvedbe novega IS-a, mora vedeti:
• katere prednosti (merljive in nemerljive) bo prinesla uvedba nove rešitve, • okvirne stroške uvedbe nove rešitve, • kako se bo povečala konkurenčnost podjetja itd.
Zato mora najvišje vodstvo poznati kratkoročne in dolgoročne informacijske zahteve, ki jih lahko dobi s pomočjo dveh vrst analiz (Laudon et al, 2000, 334 - 335):
1. Analiziranje podjetja z anketiranjem managerjev. Tako pridobimo informacije o celotni organizaciji, njenih organizacijskih enot, funkcijah, procesih in podatkih. Rezultate obširne raziskave združimo v matriko in znotraj nje določimo logične skupine podatkovnih razredov in procesov. Prednost tega pristopa je obširna analiza v podjetju, njenih IS in podatkov ter praznin, ki se pojavijo. Slabost analize pa je veliko število podatkov, ki jih je potrebno zbrati in obdelati.
2. Strateško analiziranje, imenovano tudi analiza kritičnih dejavnikov uspeha, zagovarja tezo, da je mogoče potrebne informacije pridobiti z anketiranjem majhnega števila ključnih managerjev. S ključnimi managerji, ki poznajo kritične dejavnike uspeha, se opravijo osebni intervjuji. Posamezne kritične dejavnike uspeha nato združimo v kritične dejavnike uspeha organizacije in tako dobimo podlago za odločanje. Prednost tega pristopa je manjša količina podatkov za obdelavo in analiziranje. Slabosti te analize pa sta neprilagojenost med osebnimi in organizacijskimi kritičnimi dejavniki uspeha ter usmerjenost rezultatov v upravo.
Uprava organizacije mora nato na osnovi analiz odločiti, kakšno stopnjo sprememb želi doseči z uvedbo nove rešitve. Na izbiro ima (Laudon et al, 2000, 339; slika 20):
1. avtomatizacijo, 2. racionalizacijo, 3. prenovo poslovnih procesov in 4. pragmatičen premik.
SLIKA 20: Stopnja sprememb
Vir: prirejeno po Laudon et al (2000, 339)
45
Vsaka izmed možnosti vsebuje različno stopnjo prihodkov in različno stopnjo rizika (slika 20). Prve programske rešitve so omogočale podporo zaposlenim tako, da so avtomatizirale ponavljajoča dela (npr. izračun in izpis plačilnih čekov itd). Zaposleni so tako opravili svoje delo bolj učinkovito in bolj uspešno. Večje organizacijske spremembe je kmalu po avtomatizaciji prinesla stopnja racionalizacije. Z racionalizacijo postopkov (procedur) se je povečal naravni tok podatkov in zmanjšal zastoj zaradi ozkih grl. Do še večjih organizacijskih sprememb nas pripelje prenova poslovnih procesov. S prenovo poslovni procesov se analizirajo, poenostavijo in ponovno načrtujejo poslovni procesi. Prenova zahteva velike premike v toku dela in poslovnih procesih ter tako drastično zniža stroške poslovanja. Organizacije se danes, odločajo za prenovo poslovnih procesov. Zadnja možnost je pragmatičen premik, ki zahteva premislek o nadaljnjem poteku poslovanja podjetja (poslovanje na drugem področju oz. drugi panogi). Predstavlja nov koncept poslovanja in organizacije.
Če se organizacija odloči za prenovo poslovnih procesov, to ne pomeni, da mora samo namestiti rešitev ERP ali razviti svoj IS (Davenport; povzeto po Skok et al, 2001, 4). Organizacija mora vedeti, da z uvedbo rešitve ERP ali s razvojem lastnega IS-a, spreminja tudi strukturo organizacije in poslovne procese v organizaciji (Laudon et al, 2000, 332). Kar pomeni, da spada projekt izbire in uvedbe rešitve ERP v organizaciji med enkratne projekte. Kot navaja Hauc (2002, 78-79), so temeljne značilnosti le-teh:
• namenski in objektni cilji so posebnega poslovnega ali strateškega pomena, kjer gre za kompleksne in za organizacijo večje projekte;
• aktivnosti projekta zajemajo dela, ki niso običajna za organizacijo in zato veliko del izvajajo zunanji izvajalci;
• projektno vodenje se organizira samo za projekt, objektni cilji projekta se kot njegovi rezultati razlikujejo od izdelkov ali storitev v organizaciji;
• ponavadi zahtevajo večja finančna sredstva ter obstaja večji riziko izpeljave projekta. Na osnovi narejenih analiz in želene stopnje sprememb v poslovanju organizacije mora najvišje vodstvo sprejeti odločitev ali razviti lasten IS ali kupiti standardno rešitev (slika 21). SLIKA 21: Proces pristopa izbire EPR sistema
Vir: prirejeno po Robson (1994, 406)
46
V primeru, da se uprava odloči za razvoj lastnega IS, mora nadalje sprejeti odločitev, ali bo razvila nov IS izbrana programerska hiša ali bodo razvili IS znotraj organizacije (informatiki in končni uporabniki). Zaradi prednosti uvedbe standardnih rešitev23 in slabosti razvoja lastnega IS se ponavadi uprava organizacije odloči za uvedbo standardne rešitve. Uprava organizacije se mora pred izbiro rešitve ERP odločiti, ali bo (Kežmah, 2003, 48):
1. uvedla samostojno rešitev ERP v obliki ene programske rešitve, ki je narejena po principu najboljše prakse (angl. best practice),
2. uvedla več med seboj povezanih, komplementarnih programskih rešitev, izdelanih v podjetju ali kupljenih pri različnih ponudnikih (angl. best of breed oz. s kratico BoB) ali
3. izbrala zunanje izvajanje oz. »outsourcing«, kjer organizacija najame programsko rešitev pri ponudniku programskih storitev. Zunanje izvajanje danes še ni preveč uveljavljeno, vendar se bo po raziskavah organizacije IDC najem rešitev ERP pri ponudnikih programskih storitev nadaljeval z 12 % letno rastjo do leta 2005 ter leta 2004dosegel delež 7,8 milijard dolarjev (Thickins, 2003, 16).
Organizacija bo izbrala tisti pristop, ki bo ustrezal želeni prenovi poslovanja (Shields, 2001,232). Če želimo prenoviti poslovne procese, ki so usmerjeni v zadnjo pisarno (angl. back office), potem bomo verjetno izbrali uvedbo samostojne rešitve ERP. Če pa želimo uvesti module s področja e-poslovanja (napredno planiranje, CRM, e-naročanje itd.), ki jih ponudniki rešitev ERP še ne ponujajo na trgu, potem imamo na voljo dve možnosti: (1) izberemo aplikacije neodvisnih programerskih hiš, ki so se specializirale za posamezno področje oziroma (2) počakamo, da naš ponudnik rešitve ERP izda želeni modul. Poleg tega se bo organizacija odločila za uvedbo več med seboj povezanih rešitev takrat, kadar se njihovo poslovanje in organizacija hitro spreminja, oziroma kadar organizacija ni pripravljena na prenovo vseh poslovnih procesov (Brady et al, 2001, 29). Glavne razlike med uvedbo samostojne rešitve ERP in uvedbo rešitev BoB so prikazane v tabeli 7. TABELA 7: Glavne razlike med rešitvijo BoB in rešitvijo ERP
Rešitve BoB Rešitev ERP Organizacija določi funkcionalnost uvedene rešitve BoB.
Ponudnik rešitve ERP določa funkcionalnost uveden rešitve
Organizacija sama odloči, do kakšne stopnje bo prenovila poslovne procese (prilagodljiv pristop).
S strani ponudnika rešitev določen pristop prenove poslovnih procesov, ki pogosto izboljšuje tudi organizacijsko kohezijo.
Ker imamo na izbiro module različnih proizvajalcev, lahko med temi izberemo takega, ki se kar najbolje prilega našim poslovnim procesom in s tem zmanjšamo število sprememb.
Ker je na voljo samo en referenčni model, je omejena prilagodljivost modulov našim načrtom prenove poslovanja. Zato mora organizacija spremeniti poslovanje, kar povzroči velike spremembe v poslovanju (ang. change management).
Pristop več ponudnikov omogoča porazdeljen riziko, ki je povezan z dolgoročnim zagotavljanjem vzdrževanja in podpore uvedenih modulov.
Ker smo odvisni glede vzdrževanja in podpore rešitve ERP od enega ponudnika rešitve je riziko večji, v primeru, da ta ponudnik propade.
Zaradi raznolikih modulov (komponent) in različnih platform, na katerih le-te tečejo morajo zaposleni v oddelku IT poznati uvedene module in platforme, na katerih le-ti tečejo.
Ker je rešitev ERP grajena na skupni arhitekturi, morajo zaposleni v oddelku IT poznati eno platformo in uvedeno rešitev ERP.
23 Standardne rešitve so razložene v poglavju »Funkcijsko usmerjene celovite informacijske rešitve« na strani 23.
47
Vloge posameznikov z oddelka IT so večje kot pri ERP, saj so zadolženi za vzdrževanje in prilagajanje posameznih modulov (komponent) in vmesnikov.
Ker je celotna rešitev izdelana po isti logiki, se vsi moduli vzdržujejo in prilagajajo na enak način.
Zmogljivost rešitve BoB je potrebno določiti pred začetkom uvedbe in poiskati najbolj kakovostne module (najboljšega v razredu), ki se tudi najbolje prilegajo želenim poslovnim procesom. Vsak modul se uvede kot samostojen projekt.
Na račun nadgradenj in zagotovljene kakovosti rešitve ERP je omejena fleksibilnost in zmogljivost poslovanja.
Ker imamo module različnih ponudnikov, moramo izdelati vmesnike za komuniciranje med posameznimi moduli. Ob nadgradnji posameznega modula moramo prilagoditi in testirati vse vmesnike s katerimi modul sodeluje.
Moduli rešitve ERP so integrirani in zaradi tega ni težav pri vzdrževanju rešitve ERP in pri nadgradnjah le te.
Vir: prirejeno po Light et al (2001) Raziskava podjetja Deloitte & Touche (O'Leary, 2000, 90) je pokazala, da lahko navedemo štiri različne skupine razlogov, na osnovi katerih se organizacija odloči za uvedbo rešitev ERP. Ti razlogi so:
1. tehnološki razlogi: nekompatibilnost z letom 2000, nezdružljivi IS v organizaciji, sistemske napake v obstoječem IS, zastarelost obstoječega IS in nemogoča razširitev IS ob rasti organizacije;
2. spremembe poslovnega procesa: zmanjšanje števila zaposlenih, zmanjšanje inventarja, zmanjšanje stroškov za IT, povečanje produktivnosti, urejanje časa naročil, dohodek/dobiček, nabavni proces, zaključen finančni krog in vzdrževanje,
3. strateški razlogi, kot so izboljšana odzivnost do kupcev, večja kakovost, sodelovanje in komunikacija z dobavitelji in kupci itd.;
4. konkurenčni razlogi. Po raziskavi AMR (O'Leary, 2000, 95), veliko organizacij izbere rešitev ERP zato, da »ostane v poslu«. Če imajo konkurenčne organizacije uvedeno rešitev ERP, mi pa ne, potem imajo konkurenčne organizacije prednost, saj lahko npr. hitreje odgovorijo kupcem, hitreje posredujejo informacije managerjem itd.
Kot navaja Robson (1994, 397) mora uprava organizacije poznati potencialne praznine, ki se pojavijo med izbrano rešitvijo ERP in poslovnimi procesi podjetja. Sprejeti morajo aktivno vlogo pri izbiri rešitve ERP oziroma vsaj podpirati odločitve projektnega managementa pri izbiri rešitve ERP. V procesu izbire rešitve ERP je potrebno preveriti odnose med poslovnimi in informacijskimi strategijami ter na osnovi le-teh določiti metodologijo izbire in uvedbe rešitve ERP. Pri tem pa morajo upoštevati dolgoročne cilje kot tudi kratkoročne zahteve in želje. Poleg tega morajo določiti tudi dodatno funkcionalnost, ki je rešitev ERP ne zagotavlja. Naročnik projekta - organizacija mora tudi vedeti, katere poslovne prednosti prinaša uvedba rešitve ERP:
• krajši čas postavitve novega sistema, • nižji stroški, ker se stroški razvoja delijo med vse uporabnike rešitve, • zagotovljeno pomoč in podporo ter • sistemske izboljšave ponudnika rešitve ERP.
Poleg tega morajo vedeti tudi, katere slabosti prinaša: • paket se ne bo povsem prilegal zahtevam organizacije, • ni nujno, da bo deloval primerno na obstoječi strojni in programski opremi ter • organizacija postane odvisna od ponudnika rešitve ERP.
Organizacija se mora odločiti, ali bo rešitev ERP omejila delovanje organizacije (angl. package-constrained), oziroma ali bo rešitev ERP temelj delovanja organizacije (angl. package-based) (Cadle et al, 2001, 67). Če se organizacija odloči za prvo možnost, potem
48
mora podrobno analizirati svoje zahteve in poiskati rešitev ERP ali rešitev BoB, ki se kar najbolje prilagaja tem zahtevam. V delih, kjer se paket ne prilega zahtevam, je potrebno procese v organizaciji spremeniti tako, da se bodo prilegali izbrani rešitvi ERP. Če pa se organizacija odloči za možnost, da bo rešitev ERP temelj delovanja organizacije, potem izbere rešitev ERP, ki zagotavlja večino želene funkcionalnosti in nato z lastnim razvojem oz. s pomočjo programerske hiše razvije dodatno funkcionalnost. Če se odločimo za rešitev ERP pri ponudniku rešitev ERP, potem moramo vedeti, da nobena rešitev ERP ne bo povsem zadostila naših potreb. Ker je mogoče večino rešitev ERP prilagoditi, obstaja več možnosti, med katerimi mora organizacija izbrati. Pomembno je, da identificiramo in določimo prioritete zahtevane funkcionalnosti prej, preden izberemo rešitev ERP. Kot smo že omenili, moramo vedeti, kje obstajajo praznine v rešitvi ERP in kako bomo le-te odstranili. Slika 22 prikazuje različne možnosti spopadanja organizacije z neujemanjem zahtev organizacije in ponujenih zahtev s strani rešitve ERP. Zavedati se moramo, da nobena rešitev ERP ne bo pokrivala več kot 80 odstotkov naših zahtev (pravilo 80/20; Robson, 1994, 409). SLIKA 22: Možnosti ukrepanja, kadar poslovne zahteve in zmožnosti paketa niso enake
Vir: prirejeno po Robson (1994, 410)
Ni vedno modro prilagoditi rešitev ERP, saj lahko to povzroči dodatne stroške prilagoditve in tudi dodatne stroške testiranja ob vsaki novi različici rešitve ERP. Zato je smiselno, da organizacija premisli o spremembi svojih poslovnih procesov tako, da jih prilagodi rešitvi ERP. Kot smo že omenili, ponudniki rešitev ERP sledijo principu najboljše prakse. S tem, ko organizacija prilagodi svoje poslovne procese tako, da ustrezajo rešitvi ERP, lahko tudi izboljša svoj poslovni proces. Zaradi velikih stroškov prilagajanja včasih organizacije namerno spregledajo neskladja med rešitvijo ERP in zahtevano funkcionalnostjo. Kot zadnjo možnost rokovanja z razlikami pa lahko podjetje dopolni manjkajočo funkcionalnost z dodatnimi moduli drugih ponudnikov (rešitev BoB) ali z aplikacijami razvitimi v podjetju in tako prepreči prilagajanje rešitve ERP.
49
4.2 Analiza poslovnih procesov
Na vprašanje, zastavljeno vodstvu podjetij, kaj bi spremenili, če bi še enkrat vpeljali rešitev ERP, jih je 80 odstotkov odgovorilo, da bi več pozornosti posvetili optimizaciji poslovnih procesov (Bakija, 2004). Si pa avtorji niso enotni, ali naj bo prenova poslovnih procesov pred uvedbo rešitve ERP ali med uvedbo rešitve ERP. Ne glede na to, kdaj bo podjetje prenovilo poslovne procese, mora v začetni fazi opredeliti obstoječe poslovne procese ter jih optimirati, kar stori s pomočjo procesnih modelov. Med več procesnimi modeli poišče tiste, ki najbolj učinkovito podpirajo poslovne zahteve organizacije. V fazi opredelitve in optimizacije ter racionalizacije poslovni procesov sodelujejo vsi izvajalci procesov (analitiki, organizatorji, referenti, komercialisti, pravniki, tehnologi, informatiki, ..), zato morajo biti procesni modeli enostavni, da jih vsi razumejo. Po drugi strani, pa so dovolj formalizirani, da jih je moč uporabiti kot izhodišče za vsebinsko opredelitev poslovnih procesov. V fazi prenove IS na podlagi zahtev skrbnikov in izvajalcev poslovnih procesov procesne modele prevzamejo informatiki in jih po metodološko opredeljenih postopkih pripravijo za izbiro, dokumentacijo in/ali uvedbo programske rešitve. Organizacije si pomagajo pri izdelavi procesnih modelov z orodji za analiziranje poslovnih procesov. Orodja so namenjena uporabnikom, svetovalcem in zaposlenim s področja IT in organizacije, katerih naloga je zaznati, planirati in dokumentirati procese, ki bodo predmet vpeljave rešitve ERP. Organizacija Gartner Group je glavne predstavnike orodij za analiziranje poslovnih procesov predstavila v matriki 2x2, kjer na vodoravni osi spremlja vizijo ponudnikov rešitev za optimiranje poslovnih procesov, na horizontalni osi pa funkcionalnost orodja (zmožnost izvedbe). Vizija se nanaša na tehnologijo, tržno prednost, komunikacijo in vlaganja, medtem ko se funkcionalnost orodja nanaša na izdelke, storitve, podporo ter management. Matriko orodij za analiziranje poslovnega procesa vidimo tudi na sliki 23. SLIKA 23: Orodja za analiziranje in načrtovanje poslovnih procesov organizacije
Vir: Gartner group (2002)
50
Organizacija na osnovi zahtev izdela načrt zahtev in opis zahtev. Zahteve preveri v procesnem modelu in jih optimizira. Prav tako preveri poslovne procese rešitve ERP in prilagodi svoje poslovne procese procesom rešitve ERP. Iz poslovnih procesov rešitve ERP izdela optimizacijo poslovni procesov, ki se uporabi pri načrtovanju zahtev v organizaciji in tudi pri opisu zahtev. Procesni model se nahaja med standardno rešitvijo (tudi ERP) in opisom organizacije, kot vidimo na sliki 24. SLIKA 24: Procesni model poslovno usmerjene uvedbe standardne rešitve
Vir: prirejeno po Kirchmer (1999) Pri pripravi procesnih modelov v začetni stopnji nismo odvisni od rešitve ERP. Zato se nam ni potrebno ukvarjati z usklajevanjem med poslovnim konceptom (zahtevami) rešitve ERP in med strategijo po optimizaciji poslovnih procesov. Strategija optimizacije poslovnih procesov je razdeljena na naslednjih šest korakov:
1. določiti poslovne cilje, 2. določiti tako poslovne procese kot celotni informacijski model, 3. določiti posamezne poglede IS, 4. razdeliti celotni informacijski model na podmodele, 5. določiti obseg rešitve ERP in 6. določiti strategijo uvajanja.
Nato izbere organizacija (oziroma projektni tim) rešitev ERP. Vsaka rešitev ERP ima svoj poslovni koncept (zahteve), ki jih je potrebno uskladiti s poslovnimi procesi organizacije. Z uskladitvijo poslovnih procesov rešitve ERP in poslovnimi procesi organizacije imamo izdelano poslovno ogrodje za načrtovanje poslovnih procesov in uvedbo rešitve ERP. Rezultat uskladitve so podrobni procesni modeli, ki so izdelani v orodju za analiziranje in načrtovanje poslovnih procesov (kot npr. v orodju ARIS). V tej fazi je tudi nepomembno, ali je rešitev ERP razdeljena na posamezne module, ali v katerem programskem jeziku je kodirana. Stopnja podrobnosti procesnih modelov se nanaša na raven transakcij in zaslonov. Poslovni koncept optimizacije rešitve ERP je sestavljen iz petih korakov, ki so:
1. točna določitev poslovne terminologije, 2. nadomestitev koncepta poslovne procesne optimizacije z informacijami materialnega
toka, 3. razdrobitev procesnega modela do transakcijske ravni, 4. razdrobitev procesnega modela do ravni zaslonov in 5. določitev plana selitve.
51
Nato sledi uvedba poslovnega modela. Rezultat opisa sistema so različni človeški faktorji, opravila in tehnološki faktorji. Merjenje primernosti vnaprej definiranega procesnega modela zagotavlja uvedbo strateških ciljev. Meritve pripravimo in izvedemo na konceptu IS ali uvedbeni ravni arhitekture ARIS. Osredotočimo se na koncept IS, ker je rešitev že uvedena in s področja poslovnih modelov ni več tako pomembna. Sestavljena je iz štirih korakov:
1. meritve IT, 2. meritve sistema, 3. zagon v živo in 4. optimizacijske meritve v fazi delovanja.
Te meritve je potrebno opraviti za vsak poslovni proces in podproces rešitve ERP. Kadar določi definicijo zahtev oziroma poslovni koncept proizvajalec programske opreme, potem imenujemo procesni model referenčni model (angl. reference model). V referenčnih modelih je podrobno določena vsebina informacij kot so posamezni rezultati, usposobljenost, strukturiranost, ki jih organizacija enostavno povzame v posebnih situacijah. Delimo jih na industrijsko specifične referenčne modele in referenčne modele standardnih rešitev kot, je npr. SAP referenčni model. V nadaljevanju poglavja bomo na kratko opisali orodje ARIS, ki se ga organizacije uporabljajo pri uvajanju rešitve SAP.
4.2.1 ARIS
Danes vodilni proizvajalec orodij za modeliranje poslovnih procesov je IDS Scheer s svojo arhitekturo, metodologijo in orodji za modeliranje, ki se imenujejo ARIS (angl. ARchitecture of integrated Information systems). Arhitektura ARIS omogoča opis poslovnih procesov in določa metode modeliranja in meta strukturo informacijskih modelov ter je temelj za programsko orodje ARIS (Scheer, 2000). Arhitektura ARIS opisuje poslovne procese s pomočjo ARIS hiše, ki je sestavljena iz različnih pogledov (IDS Scheer, 2004, slika 25):
• organizacijski pogled, • podatkovni pogled, • kontrolni pogled in • funkcijski pogled.
SLIKA 25: Arhitektura ARIS hiše
Vir: Nosan (2005)
kontrolni pogled
organizacijski pogled
funkcijskipogled
podatkovni pogled
52
ARIS temelji na analizi procesnih verig, kar pomeni, da spremlja celoten proces od naročila do izpolnitve naročila. Elementi verig procesnega modela so:
• funkcije – časovno definirane aktivnosti, kot je npr. odobritev naročila; • dogodki – začetni in končni dogodki, ki določajo začetek in konec procesa/funkcije
npr. prispetje kupčevega naročila, potrditev proizvodnega naročila itd.; • pogoji okolja, ki morajo biti izvršeni za izvedbo funkcij, npr. potrebna informacija za
kontrolo procesa je zaloga v skladišču; • uporabniške in organizacijske enote (npr. oddelki) ter • viri IT.
Elementi so strukturirani in klasificirani v naslednje poglede, kar vidimo tudi na sliki 26:
• podatkovni pogled (dogodki in pogoji okolja), • funkcijski pogled (procesi ali funkcije), • organizacijski pogled (uporabniške in organizacijske enote) , • kontrolni pogled, v katerem so določene odvisnosti med ostalimi pogledi.
SLIKA 26: Razdelitev posameznih elementov poslovnega procesa v različne poglede
Vir: Nosan (2005) Rezultati faze modeliranja podatkovnega, organizacijskega, funkcijskega in kontrolnega pogleda so:
• poslovni koncept (angl. business concept), ki je opisan in strukturiran do takšne mere, da ga lahko uporabimo kot začetno točko uvedbe programske rešitve;
• specifikacije modela (angl. design specification), kjer so zahteve poslovnega koncepta pretvorijo v terminologijo IT;
KONTROLNI POGLED ORGANIZACIJSKI ORGANIZACIJSKI ORGANIZACIJSKI POGLED
DOGODEK 1 FUNKCIJA 1 DOGODEK 2
ORGANIZACIJA
DELAVEC
FUNKCIJA 2
FUNKCIJSKI POGLED
PODATKOVNI POGLED
PODATKI
53
• na osnovi specifikacije modela se izdela opis uvedbe (angl. implementation description) npr. posvojitev konceptov točno določene strojne in programske opreme.
Modeli poslovnih procesov metodologije ARIS omogočajo analizo učinkovitosti poslovanja, usklajevanje projektov s strateškimi poslovnimi cilji, vpeljavo procesno usmerjenih organizacijskih struktur in učinkovito izbiro, uvedbo in integracijo z IT. Metodologija ARIS je usmerjena v poslovne procese in se lahko uporabi kot ogrodje pri uvedbi rešitev ERP, kot npr. rešitvi mySAP ERP. Primerna je zato, ker poudarja pomembnost organizacijske neodvisnosti, ne glede na IS, ki ga bomo kasneje izbrali in podrobno preučuje soodvisnost med različnimi pogledi na IS (organizacijo, podatki in funkcijami) – to so parametri, ki določajo poslovni proces. Tako podpira opredelitev ključnih faz obvladovanja procesov, njihovega sosledja, opis aktivnosti, opredelitev zahtevanih rezultatov posameznih faz ter izbor kriterijev za njihovo oceno. Osnovni značilnosti metodologije ARIS sta: krčenje obsežnosti opisa poslovnih procesov in fazni pristop k prenovi poslovnih procesov. Poleg tega je močno integrirano orodje, ki omogoča prenos informacij iz enega pogleda v drugega. Pristop ARIS ogrodja je razdeljen na 5 faz, ki zaključijo življenjski cikel projekta. Vsaka faza ima svoj pomen in je pomembna za uspeh projekta. Vsak od korakov lahko ima drugačen vpliv ali težo skozi projekt, odvisno od obsega in ciljev. Faze so:
1. Vizija, kjer zberemo pomembne začetne informacije. Med to fazo pa mora biti definirana tudi vizija, poslanstvo in strategija projekta.
2. Mobilizacija, kjer je cilj priprava projekta in projektne organizacije. V tej fazi je potrebno tudi definirati orodja in tehnike, ki jih bomo uporabili za dokumentiranje procesov in načrtovanje sistema.
3. Diagnoza temelji na obstoječem načrtovanju. Obstoječi načrt procesa vsebuje pomembne informacije in jih ne smemo ignorirati v načrtovanju izboljšave procesov. V tej fazi moramo zajeti vse pomembne informacije obstoječih procesov in poslovnih ter IT struktur.
4. Ponovno načrtovanje, kjer izdelamo točen načrt toka procesov. Procesna dokumentacija je primerna osnova za definiranje zahtev rešitve ERP. Cilj te faze ni načrtovanje same rešitve, ampak priprava osnovnega koncepta in arhitekture bodoče rešitve. Predvsem informacije, kot so kateri del procesa bo podpiral kateri modul.
5. Prehod. Glede na zemljevid uvedbe se izvede prehod iz obstoječih procesov v bodoče procese.
Orodje, v katerem snujemo različne poglede se imenuje ARIS Toolset in njegovo delovno okolje vidimo na sliki 27. ARIS Toolset je po oceni Gartner Group vodilno orodje za modeliranje, analizo in optimizacijo poslovnih procesov. Orodje sloni na preizkušeni metodologiji, ki jo je razvil prof. Scheer. Procesni modeli v ARIS predstavljajo verigo aktivnosti v diagramih EPC 24 in so predstavljeni s pomočjo simbolov, ki jih vidimo na spodnji sliki. Modeli EPC se lahko nanašajo na vse ravni procesne hierarhije. Informacije z diagrama EPC se lahko direktno pretvorijo v diagram aktivnosti jezika UML25, ki je povezan z uporabo primerov. ARIS omogoča za načrtovanje procesov dva pristopa: od zgoraj navzdol in od spodaj navzgor. Skozi podrobno načrtovanje, je potrebno procesne modele razširiti z objektno-orientiranimi informacijami ali UML specifičnimi informacijami, kot so razredi, atributi, operacije ali stanja objektov. ARIS Toolset zagotavlja orodja za modeliranje in analizo na procesno- 24 Diagrami EPC (angl. event-driven process chains). 25 Jezik UML (angl. Unified Modeling Language).
54
inženirski ravni. Vsebuje pa tudi orodja za analizo stroškov, analizo učinkovitosti procesov in simulacijo virov itd. Pri uvedbi nove aplikacije, ARIS Toolset zagotavlja številne vmesnike tudi za orodja CASE tretjih proizvajalcev. SLIKA 27: Delovno okolje orodja ARIS Toolset
ARIS Toolset zagotavlja funkcionalnost za modeliranje in analizo procesov, medtem ko ARIS HOBE zagotavlja konceptualno ogrodje za opis poslovnih procesov. Ogrodje ARIS26 je postalo standard za opis, razvoj in planiranje poslovnih struktur. Vsebuje formalen opisni jezik za modeliranje managerskih struktur poslovanja. Opis ogrodja ARIS zagotavlja osnovo za celotni, organizacijski in IT management poslovnih procesov. Poudarja procesno arhitekturo ARIS, ki ureja vse vidike poslovnih procesov. Lastniki poslovnih procesov so tako usmerjeni le na njihov vidik načrtovanja in opisa poslovnega procesa. ARIS HOBE pa zagotavlja ogrodje za urejanje poslovnih procesov od organizacijskega načrtovanja do uvedbe IT ter vključuje tudi nenehno prilagajanje izboljšavam. Prav tako pa jim omogoča tudi planiranje in kontrolo obstoječih poslovnih procesov ter nenehen proces izboljšav le-teh. ARIS HOBE je sestavljen iz štirih ravni (slika 28): 1. raven: Načrtovanje procesa (angl. process design) vključuje modeliranje poslovnih
procesov v skladu s proizvodnim delovnim načrtom. ARIS koncept zagotavlja ogrodje, ki pokriva vse poslovne vidike. Na voljo so različne metode za optimiranje, vrednotenje in zagotavljanje kakovosti procesov.
2. raven: Planiranje procesov in kontroliranje (angl. process management) omogoča lastnikom poslovnih procesov, da planirajo in kontrolirajo obstoječe poslovne procese z metodami za načrtovanje časa in zmogljivost ter analizo stroškov. Nadziranje procesa omogoča procesnim managerjem, da sledijo stanjem različnih procesov.
3. raven: Diagrami poteka (angl. workflow) omogočajo obdelavo objektov, kot npr. naročilo kupca s pripadajočo dokumentacijo. Dokumentacijo lahko prenesemo iz enega delovnega prostora na drugega s pomočjo sistema diagramov.
4. raven: Procesiranje (angl. processing) omogoča, da podrobneje obdelamo dokumente, ki jih imamo v delovnemu prostoru. To pomeni, da razčlenimo in izdelamo posamezne funkcije poslovnega procesa z uporabo orodij CASE (od enostavnih urejevalnikov besedil do kompleksnih modulov programskih rešitev, kot so npr. rešitve ERP), poslovnih objektov in java zrn.
26 Ogrodje ARIS (angl. ARIS Framework).
55
Te štiri ravni ARIS HOBE so povezane z zaključenimi zankami. Kontrola procesa med njimi zagotavlja informacije o uspešnosti obstoječega procesa. Te informacije omogočajo nadalje prisvajanje in izboljšanje poslovnih procesov v skladnosti s konceptom nenehnih izboljšav. SLIKA 28: Koncept ARIS HOBE
Vir: prirejeno po IDS Scheer (2002) Izboljšanje poslovnih procesov in načrtovanje IS nista neodvisna, saj si danes ne moremo predstavljati poslovanja brez podpore programskih aplikacij. IS je namreč brez vrednosti, če v celoti ne izpolnjuje poslovnih namenov. Tako razvoj poslovnih procesov kot tudi razvoj programske opreme temelji na ogrodjih, metodologijah in orodjih za dosego zastavljenih ciljev.
4.3 Pristopi k izbiri celovite informacijske rešitve
Rešitve ERP, ki podpirajo celotno poslovanje v ozadju, spadajo med velike projekte v organizaciji, kar lahko ovrednotimo že z osnovnimi merili za razvrstitev projektov po velikosti (Hauc, 2002, 83): (1) kompleksnost, (2) trajanje, (3) vrednost projekta in (4) riziko projekta. Ker pa se z uvedbo rešitve ERP spremeni tudi tok poslovnih procesov in organizacijska struktura, lahko rečemo, da je odločitev o uvedbi rešitve ERP strateška odločitev v organizaciji ter eden izmed razvojnih projektov (Hauc, 2002, 108), zato je izredno pomembna odgovornost uprave organizacije v fazi izbire rešitve ERP. Projektni tim za izbiro rešitve ERP mora zbrati čim več informacij o potencialnih rešitvah ERP (Bernroider et al, 2000; Harwood, 2004, 72-87) na osnovi sestankov s ponudniki, predstavitvah rešitev ERP s strani ponudnikov, preučiti mora marketinški material, uporabiti
ARIS - Arhitektura poslovnih procesov preoblikovanje
procesov
upravljanje procesov
nadzor (Workflow)
aplikacija
Referenčni modeli Simulacija
QMHandbuc
Kontrola kakovosti
Kontrola kapacitete in časov izvedbe Spremljanje
Distribucija Tok dokumentov Vnos podatkov
Objektne knjižnice
CASE SW
Standardni software
Dokument
Dokument
A
B
C
D
MIS – Management Informacijski sistemi
Nadzor
Povratne informacije
Servisi
Izgradnja
56
znanje svetovalcev, pripraviti vprašalnik, se primerno izobraziti, analizirati prototipe rešitev ERP, analizirati obstoječe študije itd. Pri izbiri rešitve ERP pa mora biti projektni tim pozoren na osnovne značilnosti rešitve ERP, kot so (Shields, 2001, 68,):
• Prileganje organizaciji. Proces uvajanja pogosto zahteva, da organizacija spremeni tok procesov tako, da se bodo le-ti prilegali rešitvi ERP (Aduri, 2002);
• Funkcionalnost rešitve ERP se nanaša na vprašanje, ali rešitev ERP podpira osnovno tehnologijo (podatkovne baze, arhitektura, vzdrževanje, skalabilnost …), tehnologijo uvajanja (orodja za poslovno modeliranje, orodja za prilagajanje sistema, orodja za urejanje dokumentacije), on-line tehnologijo (možnost prenosa različnih datotek, GUI27 zasloni, uporabniku prijazen GUI, orodja OLAP, diagrame poteka, dodatna polja, zmožnost prilagajanja GUI vmesnikov …) in posvojitev (interaktivna gradiva na zgoščenkah, »on-line« pomoč, »on-line« iskalniki po bazi, enostavnost nadgradenj …) (Harwood, 2004, 79-80).
• Fleksibilnost rešitve omogoča podporo spremembam poslovnega okolja. Ker se poslovno okolje spreminja, mora rešitev ERP omogočati več različnih poti sprememb poslovnih procesov s pomočjo prilagajanja parametrov, kodnih tabel in poročil.
• Enostavna povezljivost z drugimi IS v organizaciji. Rešitev ERP se mora enostavno povezati z drugimi rešitvami v organizaciji, kot so rešitve BoB in s IS kupcev in dobaviteljev.
• Ponudniki programskih storitev28. Ti omogočajo, da lahko organizacija prenese del ali vse module rešitve ERP na stran ponudnika programskih storitev. V nekaterih primerih IS organizacije ne more zagotoviti razvojnega ali produkcijskega okolja v potrebnem času. Če želi organizacija izvesti uvedbo rešitve ERP v določenem roku, potem mora najeti rešitev ERP pri ponudniku programskih storitev.
• Pomoč pri uvajanju. Pri današnjih kompleksnih rešitvah ERP bo organizacija težko uvedla rešitev ERP brez pomoči. Na pomoč lahko priskočijo ponudniki rešitve ERP, ponudniki programskih storitev, partnerji ponudnika rešitev ERP in svetovalci.
• Rešitev ERP mora pokrivati vsa področja poslovanja, mora biti stabilna (brez napak) in imeti dobro podporo. Včasih vsa funkcionalnost, ki jo zahteva organizacija, še ni na voljo ali še ni primerna za komercialno uporabo, ker vsebuje preveč programskih napak. Zato moramo pri izbiri paziti, da izberemo zanesljivo rešitev ERP in s tem zmanjšamo možni odstotek napak, ki se bodo pojavile pri uvedbi.
• Na voljo morajo biti pospeševalci uvedbe kot so: učni material, uporabniške procedure, pomoč, procesni modeli, podroben plan dela itd.
Pri izbiri pa moramo poleg osnovnih karakteristik upoštevati tudi, da z izbiro ERP rešitve izberemo poslovnega partnerja, zato Harwood (2004, 77–97) predlaga, da preverimo tudi sledeče:
• pristop uvajanja ponudnika rešitve ERP in število uspešno uvedenih rešitev ERP; • stopnjo podpore med in po uvedbi rešitve ERP, kot npr. kje so najbližji svetovalci, ali
je podpora v obliki oglasnih desk, tehnične in uporabniške dokumentacije, predlog itd.; • pregled stroškov strojne opreme, operacijskih sistemov, licence za podatkovno bazo,
licence za osnovne module rešitve, licence za dodatne module rešitve, licence za dodatne module partnerjev, stroški integracije, prilagajanja modulov, pretvorba
27 Grafični uporabniški vmesnik oziroma s kratico GUI (angl. Graphical User Interface). 28 Ponudnike programskih storitev oz. s kratico kar ASP (angl. application service provider).
57
podatkov, projektni management, svetovanje, izobraževanje, potni stroški in dnevnice ter stroški za nadgradnje;
• kredibilnost organizacije, kjer preverimo profil ponudnika (velikost, lokacijo, kdaj je bilo ustanovljeno, finančno stabilnost ponudnika …) ter ali bo v poslu še čez pet let (strategijo razvoja rešitve ERP, kakovost rešitve ERP, ali ima ponudnik rešitve ERP namen v prihodnje razvijati nove module, uporabljati nove tehnologije, koliko nameni ponudnik rešitve ERP za raziskave in razvoj, periodiko novih verzij);
• izkušnje rešitve ERP na področju poslovanja organizacije (za katera poslovna področja je specializiran);
• ugled ponudnika rešitev ERP preverimo s pomočjo neodvisnih agencij, kot npr. AMR Research in Gatner Inc., v časopisih in člankih ter s pomočjo obiskov organizacij, kjer imajo uvedeno rešitev ERP.
Pozorni moramo biti tudi na odnos osebja ponudnika do naše organizacije, na fleksibilnost pogajanja s strani ponudnika, število presenečenj s stran ponudnika (zamolčani stroški v ponudbi) itd. (Shields, 2001, 71-73). Bernroider et al (2000) sta na osnovi raziskave opredelila štiri strukture timov, ki so izbrali rešitev ERP:
1. odločitev je padla s strani uprave in zunanjih svetovalcev, ključni uporabniki organizacije pa so bili vključeni minimalno;
2. močno vlogo pri izbiri rešitve ERP je imel oddelek organizacije in IT z minimalno vključitvijo drugih oddelkov in brez pomoči zunanjih svetovalcev;
3. odločitev je sprejelo več oddelkov v organizaciji, tudi tistih, pri katerih bo uvajanje rešitve ERP povzročilo večje spremembe ter
4. mešanica zgornjih pristopov. Organizacije se poslužujejo treh osnovnih pristopov pri izbiri rešitve ERP (Shields, 2001, 73; Harwood, 2004, 70). Ti pristopi so:
1. pristop podrobnih zahtev, 2. pristop ključnih zahtev in 3. pristop dokaz koncepta.
4.3.1 Pristop podrobnih zahtev
Pristop podrobnih zahtev (angl. detaild requirements approach) uporabimo pri izbiri paketov oz. modulov, kot so elektronsko poslovanje, SCM, CRM in drugih, ki so se pojavili na tržišču v zadnjem času. Postopek izbire je sledeč:
• projektni tim29 poišče vse mogoče primere paketov ERP oziroma njihovih modulov; • ponudnikom teh paketov pošljemo zahtevo po informacijah; • projektni tim pripravi podroben diagram obstoječih poslovnih procesov in seznam
funkcionalnih in tehničnih zahtev; • projektni tim pošlje ponudnikom, od katerih je dobi odgovor na zahtevo po
informacijah, zahtevo za ponudbo. Število prejetih odgovorov na zahtevo za ponudbo je ponavadi manjše;
• na zahtevo ponudnikov rešitev ERP lahko ima organizacija formalno ponudbeno konferenco, na kateri odgovarja na vprašanja ponudnikov rešitev ERP;
29 V tem poglavju bomo uporabljali za skupino ljudi, ki je izbrala rešitev ERP, izraz projektni tim. V praksi je projektni tim, ki je izbral rešitev ERP, tudi v projektnem timu, ki uvaja novo rešitev, ni pa njuno.
58
• v času, ki ga imajo ponudniki ERP, da pripravijo dokončno ponudbo, projektni tim pripravi odločitveni model za izbiro rešitve ERP;
• projektni tim razvrsti prispele ponudbe glede na kriterije vnaprej pripravljenega odločitvenega modela;
• ponudniki imajo čas, da pripravijo demonstracijo paketa. Za vsak paket je predvidena demonstracija od enega do treh dni;
• projektni tim ovrednoti ponudbe rešitev ERP v ožjem izboru, njihove demonstracije in informacije z liste referenc, ki jih posredujejo ponudniki rešitev ERP ter izbere najustreznejšega ponudnika rešitev ERP.
4.3.2 Pristop ključnih zahtev
Pristop ključnih zahtev (angl. key requirements approach) temelji na pristopu, da se v začetni fazi izbira med nekaj rešitvami oz. moduli, saj obstaja v vsaki panogi med 6 in 8 vodilnih ponudnikov rešitev ERP. Pristop ključnih zahtev se razlikuje od pristopa podrobnih zahtev v tem, da projektni tim ne preverja tradicionalnih modulov, pač pa je pozoren na razlike med rešitvami (moduli) in na to, kakšen vpliv imajo te razlike na ključne probleme in prednosti organizacije. V pristopu ključnih zahtev morajo sodelovati ljudje, ki že imajo izkušnje z uvedbo izbrane rešitve ERP, sicer si morajo člani projektnega tima pridobiti ustrezno znanje, kar pa podaljša postopek izbire. Postopek izbire je sledeč:
• S pomočjo svetovalcev in posebnega vprašalnika, ki vsebujejo vprašanja objektivnega tipa da/ne, mora projektni tim določiti, katera funkcionalnost rešitve ERP mora biti omogočena in katera je opcijska.
• Projektni tim pripravi poslovne scenarije in skripte, medtem pa ponudniki rešitev ERP pripravijo demonstracijo svoje rešitve.
• Ob demonstraciji mora biti projektni tim posebej pozoren na razlike med rešitvami ERP. Po demonstraciji vseh rešitev ERP projektni tim izbere dve do štiri rešitve ERP, ki jim posreduje poslovne scenarije in skripte, na osnovi katerih morajo ponudniki pripraviti demonstracijo. Projektnemu timu mora biti ves čas demonstracije jasno ali ponudnik rešitve ERP uporablja »vanilla« rešitev30 oziroma ali je pri izvedbi priprave na demonstracijo sodeloval tudi tretji ponudnik računalniških rešitev.
• Postopki izbire rešitve ERP so enaki, kot pri pristopu podrobnih zahtev. Ko projektni tim izbere ponudnika, naredi naključne poskuse v izbran paket, da se prepriča v primerno delovanje paketa.
Glavna prednosti pristopa ključnih zahtev je skrajšan čas izbire, saj je potrebno preveriti manj ponudnikov ter projektni tim ne preverja podrobnosti tradicionalnih modulov rešitve ERP, pač pa samo razlike med rešitvami.
4.3.3 Pristop dokaz koncepta
Pristop dokaz koncepta (angl. proof-of-concept approach) je pogosto najhitrejši pristop izbire rešitve ERP, kjer že vnaprej vemo, katero rešitev ERP bomo izbrali. Pristop dokaz koncepta je primerno uporabiti pri izbiri klasičnih modulov vodilnih ponudnikov ERP, saj je funkcionalnost vseh modulov zelo podobna (razvijajo jo 20 in več let). Postopek izbire je naslednji:
• Projektni tim mora pripraviti zahteve, katerim naj bi zadostila rešitev ERP. Do teh zahtev pridejo s pogovori managerjev in ključnimi uporabniki obstoječega sistema, z analizo procesnih diagramov, razpravami o obsegu rešitve ERP, izbiro kriterijev in
30 Rešitev ERP, ki ji ne prilagajamo izvorne kode, imenujemo »vanilla« rešitev.
59
prioritet v procesu uvajanja rešitve ERP, evalvacijo tehničnih zahtev in neformalnimi razpravami med člani projektnega tima.
• Projektni tim mora ugotoviti tudi praznine med zahtevami, do katerih pridejo z analiziranjem odgovorov. Tako projektni tim ugotovi, ali bodo morali nadomestiti manjkajočo funkcionalnost z rešitvami drugih ponudnikov.
Slabost tega pristopa je, da se ponudnik rešitve ERP zaveda, da je edini ponudnik in se zato organizacija težko pogaja glede cene in drugih ugodnosti. Prednost tega pristopa pa je, da projektni tim dobro spozna rešitev ERP, saj je bil v procesu izbire osredotočen samo na en produkt. Pristop dokaz koncepta poskuša doseči večino prednosti preostalih dveh konceptov kljub temu, da je osredotočen samo na eno rešitev. Rezultat tega pristopa je dobro razumevanje rešitve, zahtev, praznin med zahtevami in procesov, ki jih bomo uvedli. Pri izbiri rešitve ERP moramo opredeliti, katera izmed rešitev ERP v ožjem izboru je za nas najprimernejša. To lahko storimo s pomočjo vprašalnika, kjer posameznim vprašanjem določimo težo. Vprašalnik mora vključevati naslednja področja (Bernroider et al, 2000):
• boljši dostop do podatkov s strani zaposlenih, • preizkušen programski paket, • dobra podpora s strani ponudnika rešitev ERP, • izboljšanje organizacijske strukture, • uvedba rešitve ERP kot »modna muha«, • povečanje organizacijske fleksibilnosti, • povečanje zadovoljstva s strani kupcev, • večjezičnost, • podpora različnim valutam, • krajši čas uvajanja v primerjavi z lastnim razvojem, • modularna arhitektura rešitve ERP, • večja zanesljivost delovanja sistema, • dobro ime ponudnika rešitve ERP, • posodobitev poslovnih procesov s pomočjo rešitve ERP, • nezdružljivost obstoječih informacijskih sistemov, • neodvisnost od operacijskega sistema, • s strani ponudnika jasno opredeljene metode in pripomočki uvajanja, • razpoložljivost posebnih funkcionalnosti za posamezno panogo, • funkcionalnost poslovanja s poslovnimi partnerji preko e-poslovanja, • uvajanje internetnega poslovanja, • z nabavo rešitve ERP si organizacija kupi kontinuiran razvoj in • prilagodljivost in fleksibilnost rešitve ERP.
Pri izbiri rešitve ERP si lahko pomagamo tudi z vnaprej pripravljenim sistemom metrik za ocenjevanje kakovosti pri njeni uporabi. Ocenitev rešitve ERP s pomočjo sistema metrik je lahko eden izmed kriterijev, ki imajo pomembno vlogo v odločitvenem modelu izbiranja rešitve ERP.
4.4 Ocenitev celovitih informacijskih rešitev
Zaradi prodora in popularnosti rešitev ERP se je na trgu pojavilo ogromno ponudnikov. Velika konkurenca na trgu ponudnikov rešitev ERP je vzpodbudila le-te, da so začeli izboljševati svoj poslovni proces izdelave računalniških rešitev, pri čemer so si pomagali z modeli in standardi za zagotavljanje sistema kakovosti, standardi za opredelitev življenjskega
60
cikla razvoja in modeli za ocenjevanje zrelosti programskega procesa. Po drugi strani pa je vse več kupcev in poslovnih partnerjev zaradi slabih izkušenj z računalniškimi rešitvami v preteklosti zahtevalo skladnost računalniških rešitev z ustreznimi standardi. Večina rešitev ERP je danes opremljena z znakom, da so v skladu s sistemom kakovosti, s standardi, pravili in zakoni, kar pomeni, da je rešitev ERP skladna z določenimi, vnaprej znanimi zahtevami. V vsej množici standardov (standardi družine ISO 9000, ISO/IEC 12207, ISO/IEC 12598 in ISO/IEC 9126), ki se danes pojavljajo, pa nas zanima, kako rešitve ERP zadovoljujejo potrebe končnih uporabnikov. Organizacija, ki se odloča za nakup oziroma najem rešitve ERP, lahko le predpostavlja, da so rešitve ERP, ki imajo certifikat kakovosti, boljše od tistih, ki certifikata nimajo. Velik problem, ki se lahko pojavi v organizaciji po uvedbi rešitve ERP, je nezadovoljstvo s strani končnih uporabnikov. Organizacija se mora tega problema zavedati in ga poskusiti rešiti, saj je zadovoljstvo končnih uporabnikov z rešitvijo ERP eden izmed kritičnih dejavnikov uspeha uvedbe rešitev ERP (Sternad in Bobek, 2004). Zato morajo v projektu izbire rešitve ERP sodelovati tudi končni uporabniki, ki dobro poznajo potek posameznih delov poslovnih procesov v organizaciji. Standard ISO/IEC 9126: »Programsko inženirstvo – kakovost računalniške rešitve« lahko uporabimo tudi v procesu izbire rešitve ERP za ocenjevanje in vrednotenje kakovosti rešitev ERP. Organizacije, ki kupujejo oziroma najemajo rešitev ERP, lahko preverijo kakovost rešitve ERP pri njeni uporabi za izbrano rešitev ERP oziroma za tiste rešitve ERP, ki so v ožjem izboru. V nadaljevanju bomo predstavili standard ISO/IEC 9126 in razvili splošen primer sistema metrik za ocenjevanje kakovosti rešitve ERP pri njeni uporabi.
4.4.1 Standard 9126 – Ocenjevanje kakovosti v uporabi
Ocenjevanje in vrednotenje računalniške rešitve je eden izmed procesov v življenjskem ciklu razvoja računalniške rešitve. Kakovost računalniške rešitve lahko vrednotimo z merjenjem notranjih karakteristik (statične mere vmesnih faz projekta izdelave računalniške rešitve), z merjenjem zunanjih karakteristik (merjenje obnašanja delovanja programa) in z merjenjem karakteristik kakovosti pri njeni uporabi (ISO/IEC 9126-1, 2001). Prvi del modela kakovosti po standardu ISO/IEC 9126 določa šest karakteristik za ocenjevanje notranje kakovosti (angl. internal quality) in zunanje kakovosti (angl. external quality) računalniške rešitve. Drugi del modela določajo štiri karakteristike kakovosti pri njeni uporabi (angl. quality in use). Notranjo kakovost in zunanjo kakovost ocenjujemo s pomočjo šestih karakteristik, ki so (ISO/IEC 9126, 2003a, ISO/IEC 9126b in Pivka, 1996):
• funkcionalnost (angl. functionality) ocenjuje stopnjo funkcionalnosti v uporabi računalniške rešitve glede na pogoje delovanja;
• zanesljivost (angl. reliability) ocenjuje raven zmogljivosti računalniške rešitve pod določenimi pogoji delovanja;
• uporabnost (angl. usability) ocenjuje lastnosti računalniške rešitve, kot so: razumljivost, enostavnost za priučitev, enostavnost za uporabo ter atraktivnost do uporabnikov v določenih pogojih delovanja;
• učinkovitost (angl. efficiency) ocenjuje zagotavljanje primerne zmogljivosti v povezavi z vsemi porabljenimi viri v določenih pogojih delovanja;
• vzdrževanje (angl. maintainability) ocenjuje možnosti in stopnjo sprememb računalniške rešitve;
61
• prenosljivost (angl. portability) ocenjuje prenosljivost računalniških rešitev z enega okolja v drugo okolje.
Kljub temu, da merimo iste karakteristike in podkarakteristike za notranjo kakovost in zunanjo kakovost, imamo za merjenje vsakega sklopa svoje metrike. S pomočjo notranjih metrik ocenjujemo računalniške rešitve v statičnem okolju (merimo in vrednotimo izvorno kodo), medtem ko s pomočjo zunanjih metrik ocenjujemo delovanje računalniške rešitve v dinamičnem okolju. Tehnično poročilo, v katerem je primer metrik za merjenje in ocenjevanje notranje kakovosti, najdemo v tretjem delu standarda ISO/IEC 9126. Primer metrik za merjenje in ocenjevanje zunanje kakovosti pa najdemo v drugem delu istega standarda. Primera metrik sta splošna, zato jih moramo v primeru dejanske uporabe prilagoditi našim zahtevam glede kakovosti računalniške rešitve. Rešitve ERP spadajo med standardne računalniške rešitve, katerih glavna značilnost je, da so jih programerske hiše razvile za anonimni trg (Kirchmer, 1999). To pomeni, da organizacija, ki nastopa v vlogi kupca rešitve ERP, ne bo ocenjevala notranje in zunanje kakovosti izbrane rešitve ERP, pač pa kakovost v njeni uporabi, o čemer bomo govorili v naslednjem poglavju.
4.4.2 Metrike za ocenjevanje kakovosti v uporabi s strani končnega uporabnika
Kakovost pri njeni uporabi je uporabniški vidik na kakovost računalniške rešitve, kar pomeni, da združuje skupek programskih karakteristik kakovosti, ki zanimajo končnega uporabnika. S pomočjo kakovosti pri njeni uporabi ocenjujemo rezultate uporabe računalniške rešitve, ne pa njenih lastnosti. Kakovost računalniške rešitve pri njeni uporabi se nanaša na končne uporabnike, da dosežejo zastavljene cilje učinkovito, produktivno, varno in z zadovoljstvom v točno določenem kontekstu uporabe (ISO/IEC 9126, 2001). Nanaša se na ocenjevanje rezultatov uporabe računalniške rešitve v produkcijskem okolju. Kakovost računalniške rešitve pri njeni uporabi ocenjujemo s pomočjo naslednjih karakteristik oziroma sistema metrik (ISO/IEC 9126, 2001; ISO/IEC 9126-2, 2004):
• Učinkovitost (angl. effectiveness) ocenjuje zmožnost računalniške rešitve, da doseže specifične cilje točno in popolno.
• Produktivnost (angl. productivity) ocenjuje porabo virov v povezavi z doseženo uspešnostjo v določenih nalogah. Viri lahko vključujejo čas, ki je potreben za končanje naloge, uporabniški napor, material ali finančne vire.
• Varnost (angl. safety) ocenjuje tveganje poškodovanja ljudi, poslovanja, ostalih računalniških rešitev, lastnino ali okolje. Tveganje je ponavadi rezultat pomanjkanja ocenjevanja podkarakteristik funkcionalnosti, zanesljivosti, uporabnosti in vzdrževanja notranje in zunanje kakovosti računalniške rešitve.
• Zadovoljstvo (angl. satisfaciton) ocenjuje stopnjo zadovoljstvo uporabnika pri uporabi računalniške rešitve v specifičnih pogojih delovanja.
Vsaka vrsta računalniških rešitev, kamor spadajo tudi rešitve ERP, ima svoje značilnosti, ki jih moramo v sistemu metrik upoštevati. V nadaljevanju smo izdelali primer sistema metrik za ocenjevanje kakovosti rešitev ERP pri njeni uporabi. Vsak sistem metrik je sestavljen iz več podkarakteristik oziroma metrik. Vsako metriko smo poimenovali, opredelili namen metrike ter opisali metodo za izračun oziroma ocenitev metrike. Nato pa smo v tabeli predstavili:
1. meritev in formule, s pomočjo matematičnih funkcij za razmernostne, razmične in absolutne skale oziroma z zalogo vrednosti za nominalne in ordinalne skale;
2. interpretacijo meritev, kjer opisujemo definicijsko območje in najprimernejše vrednosti s tega območja;
62
3. tip metrične skale je lahko: nominalna, ordinalna, razmernostna, razmična in absolutna skala;
4. tip meritve opredeljuje tipe spremenljivk v formulah, kot so npr. štetje, čas itd.; 5. vložek meritve opisuje, na kakšen način dobimo vrednosti spremenljivk oziroma
zalogo vrednosti. Metrika učinkovitosti Metriko učinkovitosti sestavljajo naslednje metrike. Sintaktične napake ob vnosu, kjer lahko merimo:
1. ali rešitev ERP opozori uporabnika na vpis napačnega tipa podatka (rezultat X), kjer primerjamo število nepravilno vnesenih tipov podatkov s številom vseh vnosov,
2. ali rešitev ERP uporabniku z namigom svetuje izbiro tipa podatka (rezultat Y), kjer izberemo enega izmed odgovorov.
Meritev in formula Interpretacija meritev
Tip metrične skale Tip meritve Vložek meritve
X = A/B A = število nepravilno vnesenih tipov podatkov B = število vseh vnosov
0 <= X Bližje vrednosti 0, je bolje.
Razmernostna skala
A = štetje B = štetje X = štetje / štetje
Število zaznanih nepravilnih vnosov v ERP31 in število vseh vnosov v ERP.
Y = {0, 1} 1 – odgovor da 0 – odgovor ne
Y = 1 je priporočljivo.
Nominalna skala
Y = odgovor
Odgovor na vprašanje.
Semantične napake ob vnosu, kjer lahko merimo:
1. Število semantičnih napak v določenem obdobju v primeru, da rešitev ERP ne bi preverjala podatkov med vnosom. Rešitev X dobimo tako, da primerjamo število semantičnih napak, ki se zgodijo v določenem časovnem obdobju.
2. Način, kako rešitev ERP opozori uporabnika, če v vnosno polje vpiše semantično napačne vrednosti. Rešitev Y dobimo tako, da pri uporabniku ali v uporabniški dokumentaciji dobimo odgovor na vprašanje.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = A/T A – število semantičnih napak T – časovno obdobje
0 <= X Bližje vrednosti 0, je bolje.
Razmernostna skala
A = štetje T = čas X = štetje/ čas
ERP beleži število semantičnih napak v posebno datoteko.
Y = {0, 1, 2, 3} 0 – ne opozori 1 – omejitev v številu znakov, ne opozori uporabnika, dovoljuje nadaljnji vnos podatkov 2 – omejitev v številu znakov, ne opozori uporabnika, ne dovoljuje nadaljnji vnos podatkov 3 – omejitev v številu znakov, opozori uporabnika, ne dovoljuje nadaljnji vnos podatkov
Y = 3 ali Y = 2 je priporočljivo.
Ordinalna skala Y = odgovor
Opis ERP (uporabniški priročnik) in odgovor uporabnika na vprašanje.
31 V tabelah metrik bomo namesto rešitev ERP uporabljali ERP.
63
Privzete vrednosti, ki jih lahko merimo s: 1. Številom vnaprej napisanih privzetih vrednosti. Rezultat X dobimo z odgovorom
uporabnika na vprašanje. 2. Krajšim časovnim intervalom za vnos opravila, če ima uporabnik na voljo privzete
vrednosti. Rezultat Y dobimo tako, da merimo čas, ki ga uporabnik potrebuje za vnos. Meritev in formula Interpretacija
meritev Tip metrične
skale Tip meritve Vložek meritve
X = {0, 1, 2} 0 – ne omogoča privzetih vrednosti 1- privzete vrednosti se nanašajo na prejšnji vnos podatkov 2 – avtomatično nastavi privzete vrednosti na osnovi podatkov v podatkovni bazi
X = 2 je priporočljivo.
Ordinalna skala
X = odgovor
Opis ERP (uporabniški priročnik).
Y = A/(B*T) A - število privzetih vrednosti v vnosnem obrazcu B - število vseh vnosnih polj v obrazcu T – čas opravila
0 <= Y <= 1 Vrednost čim bližja 1, je boljša.
Absolutna skala
A = štetje B = štetje T = čas Y = štetje / (štetje* čas)
Čas za vnos lahko dobimo v ERP ali pa ga sami merimo. Ostale podatke dobimo z opisa ERP.
Funkcijske tipke merimo z možnostjo uporabe funkcijskih tipk. Rezultat X dobimo tako, da poiščemo odgovor v uporabniškem priročniku.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = {0, 1, 2, 3} 0 – niso omogočene funkcijske tipke 1 – so nastavljene posebej za ERP 2 - standardne funkcijske tipke, ki so nastavljene tudi v OS32 3 – standardne funkcijske tipke, vendar jih lahko uporabnik po potrebi spremeni
Vrednosti X = 3 oz. X = 2 sta priporočljivi.
Ordinalna skala X = odgovor
Opis ERP (uporabniški priročnik).
Razumevanje funkcij merimo s poznavanjem funkcionalnosti rešitve ERP s strani uporabnika. Rezultat X dobimo na podlagi uporabniškega testa in intervjuja uporabnika ali s pomočjo opazovanja uporabnika. Nato preštejemo vse funkcije, ki jih uporabnik razume in jih primerjamo z vsemi funkcijami rešitve ERP.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = A/B A – število funkcij (funkcionalnost), ki jih uporabnik razume B – število vseh funkcij, ki jih ERP omogoča.
0 <= X <= 1 Vrednost bližje k 1, je bolje.
Absolutna skala
A = štetje B = štetje X = štetje/ štetje
Opazovanje uporabnika pri delu ali in poročilo uporabniškega testa.
Učinkovitost demonstracije meri, kolikšen del funkcij lahko uspešno izvede uporabnik po opravljeni demonstraciji. Rezultat X dobimo z opazovanjem obnašanja uporabnika, ki želi videti demonstracijo.
32 V nadaljevanju bomo za operacijski sistem uporabljali kratico OS.
64
Meritev in formula Interpretacija
meritev Tip metrične
skale Tip meritve Vložek meritve
X = A/B A – število funkcij, ki jih je uspešno opravil po uporabi demonstracije B – število vseh demonstracij
0 <= X <= 1 Bližje 1, je bolje.
Absolutna skala
A = štetje B = štetje X = štetje/ štetje
Uporabniška dokumentacija in poročilo.
Metrika produktivnosti Vrste opravil meri število funkcij, ki jih mora uporabnik izvesti v rešitvi ERP za uspešno opravljeno opravilo v primerjavi s številom funkcij, ki jih je moral izvesti v prejšnjih rešitvah (lahko tudi drugih rešitvah ERP). Rešitev X dobimo tako, da primerjamo število funkcij v rešitvi ERP s številom funkcij v drugih računalniških rešitvah.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = A/B A – število funkcij, ki jih je potrebno opraviti v sistemu ERP za uspešno zaključeno opravilo B – število funkcij, ki jih je potrebno opraviti v drugih računalniških rešitvah za uspešno zaključeno opravilo
X < 1 je bolje. Razmernostna skala
A = štetje B = štetje X = štetje
Poročilo iz ERP (iz baze podatkov) in poročilo iz sistema ERP.
Potreben napor merimo tako, da primerjamo, ali uporabnik danes z istim naporom opravi več opravil. Rešitev X dobimo s primerjavo produktivnost uporabnika danes in v preteklosti.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X= A/B A – človeški napor izražen v času za zaključitev opravila danes B – človeški napor izražen v času za zaključitev opravila v preteklosti
X >= 0. Večja vrednost X-a je boljša.
Razmernostna Skala.
A = čas B = čas X = čas / čas
Poročilo iz ERP in poročilo (lahko pisno) iz druge računalniške rešitve.
Sodelovanje z nadrejenimi in podrejenimi merimo z načinom sodelovanja z nadrejenimi in podrejenimi. Rešitev dobimo tako, da štejemo število poskusov sodelovanja v določenem časovnem obdobju.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = A/T A – število poskusov sodelovanja T – časovno obdobje
X >= 0. Večja vrednost X-a je boljša.
Razmernostna skala
A = štetje B = čas X = štetje/ čas
Poročilo iz ERP.
Realno število opravljenih ur meri število efektivnih ur uporabnika. Primerjamo število ur dela v rešitvi ERP s številom ur prisotnih na delovnem mestu.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = A/B A – število ur dela v ERP B – število ur na delovnem mestu
X <= 1. Vrednost, ki limitira h 1, je boljša.
Absolutna skala.
A = čas B = čas X = čas/ čas
Evidenca ur na delovnem mestu. Poročilo o opravljenih urah v ERP.
65
Natančnost pri delu meri natančnosti uporabnika pri vnosu podatkov v sistem ERP. V rešitvi ERP preverimo število opravljenih vnosov in napak, ki so se pojavile zaradi napačnega vnosa.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = A/B A – število pravilnih vnosov v določenem obdobju B – število vseh vnosov v določenem obdobju
X <= 1 Vrednost ki limitira h 1, je boljša.
Absolutna skala
A = štetje B = štetje X = štetje/ štetje
Poročilo narejeno iz ERP.
Metrika varnosti Izguba podatkov meri, ali se v rešitvi ERP izgubljajo podatki. Izgubo podatkov lahko merimo na dva načina, in sicer:
1. na osnovi vprašanja dobimo odgovor (rezultat X) in/ali 2. preštejemo vse podatke in podatke, ki se izgubijo (rezultat Y).
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = {0, 1} 0 – da 1 – ne
X = 1 je sprejemljivo.
Nominalna skala
X = odgovor
Vprašalnik.
Y = A/B A – število izgubljenih podatkov B – število vseh podatkov
0 <= Y. Y bližje 0 je bolje.
Absolutna skala
A – štetje B – štetje Y – štetje / štetje
Poročila iz ERP.
Omejitev dostopa do informacij meri dostopnost uporabnikov do informacij. Na osnovi vprašanja dobimo odgovor.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = {0, 1,2 } 0 – ne 1 – delno 2 – v celoti
X = 0 je ni sprejemljivo.
Ordinalna skala
X = odgovor
Vprašalnik ali uporabniška dokumentacija.
Prijava nepravilnega delovanja ERP meri, ali mora uporabnik sam prijaviti nepravilno delovanje rešitve ERP. Rešitev dobimo na osnovi vprašanja oziroma poiščemo odgovor v specifikaciji rešitve ERP.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = {0, 1} 0 – ne, je avtomatizirano 1 – da, ni avtomatizirano
X = 0 je sprejemljivo.
Nominalna skala
X = odgovor
Vprašalnik ali specifikacija ERP.
Dostop do ERP meri, na kakšen način lahko uporabnik dostopa do rešitve ERP. Na osnovi vprašanja oziroma iz uporabniške dokumentacije ugotovimo način dostopa do ERP.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = {0, 1, 2} 0 – ni omejen dostop do ERP 1 – omejen na delovno mesto 2 – omejen z geslom
X = 2 je sprejemljivo.
Ordinalna skala
X = odgovor
Uporabniška dokumentacija oz. specifikacija ERP.
66
Uporaba gesel meri, kako se uporabnik prijavlja v sistem ERP. Podatke pridobimo na osnovi vprašanja oziroma v uporabniški dokumentaciji.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = {0, 1, 2, 3} 0 – ni omejen z geslom 1 – geslo, vendar ni kodirano 2 – geslo (kodirano) 3 – geslo in varnostna kartica (security card)
X = 3 in X = 2 je sprejemljivo.
Ordinalna skala
X = odgovor
Vprašalnik ali uporabniška dokumentacija.
Nameščanje popravkov meri, ali mora uporabnik sam skrbeti za nameščanje popravkov. Podatke poiščemo v uporabniški dokumentaciji.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = {0, 1, 2} 0 – ne, je avtomatizirano 1 – delno, ERP opozori, da je potrebno namestiti popravke, nato pa se uporabnik sam odloči 2- da, uporabnik mora sam nameščati popravke
X = 0 in X = 1 je sprejemljivo.
Ordinalna skala
X = odgovor
Uporabniška dokumentacija.
Sistem avtorizacije merimo z več vidikov:
1. ali lahko uporabnik zaobide avtorizacijski postopek (rezultat X); 2. ali rešitev ERP dopušča, da uporabnik izvaja transakcije, za katere ni avtoriziran
(rezultat Y); 3. ali se vsak uporabnik prijavlja v sistem ERP s svojim uporabniškim imenom in
geslom, na katerega so vezane uporabniške pravice (rezultat Z). Odgovore za vse tri rešitve poiščemo v uporabniški in varnostni dokumentaciji.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = {0, 1} 0 – ne 1 – da
X = 0 je sprejemljivo.
Ordinalna skala
X = odgovor
Uporabniška in varnostna dokumentacija
Y = {0, 1, 2} 0 – ne dopušča 1 – delno, uporabnik lahko spremeni transakcijo, vendar je administrator o tem obveščen 2 – dopušča
Y = 0 je sprejemljivo.
Ordinalna skala
Y = odgovor
Uporabniška in varnostna dokumentacija
Z = {0, 1, 2} 0 – skupina uporabnikov, ki izvaja ista opravila v ERP se prijavlja z istim uporabniškim imenom in geslom 1 - vsak uporabnik ima svoj uporabniško ime in geslo, vendar lahko pregleduje in vnaša podatke v vsa polja (optimistični pristop) 2 – vsak uporabnik ima svoje uporabniško ime in geslo, na katerega so vezana opravila (funkcije), ki jih lahko izvaja (pesimistični pristop)
Z = 2 je sprejemljivo.
Ordinalna skala
Z = odgovor
Uporabniška in varnostna dokumentacija
67
Metrika zadovoljstva Uporabniški vmesnik meri, kako se uporabnik znajde v uporabniškem vmesniku. Podatke za merjenje lahko pridobimo z opazovanjem uporabnika ob delu oziroma z vprašalnikom. Meritev in formula Interpretacija
meritev Tip metrične skale Tip meritve Vložek meritve
X = {1,2,3} 1 – povsem znajde 2 – delno znajde 3- ne znajde
X = 1 in X = 2 sta sprejemljiva odgovora.
Ordinalna skala
X = ocena Opazovanje uporabnika pri delu oz. vprašalnik.
Možnost demonstracije z vidika zadovoljstva meri:
1. Kolikšen del demonstracij je uporabniku dostopnih (rezultat X). Rezultat pridobimo tako, da izvedemo uporabniški test oziroma opazujemo obnašanje uporabnika.
2. Kolikšen del demonstracij je uporabniku na voljo, kadar potrebuje pomoč med delom (rezultat Y). V tem primeru preštejemo demonstracije, ki so primerno predstavljene in jih primerjamo z vsemi funkcijami, ki bi potrebovale demonstracijo. Potem pa opazujemo obnašanje uporabnika, ki želi videti demonstracijo.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = A/B A - število demonstracij, do katerih je uporabnik uspešno dostopa B – število demonstracij, ki so uporabniku na voljo
0 <= X <= 1 Vrednost bližja 1, je bolje.
Absolutna skala
A = štetje B = štetje X = štetje/ štetje
Uporabniška dokumentacija in poročilo testa.
Y = C/D C – število primerov, v katerih je uporabnik uspešno dostopil do demonstracije D – število primerkov, v katerih je uporabnik imel namen dostopiti do demonstracije
0 <= Y <= 1 Vrednost bližja 1, je bolje.
Absolutna skala
C = štetje D = štetje Y = štetje/ štetje
Uporabniška dokumentacija in poročilo testa.
Ergonomija zaslona meri:
1. Ali si lahko uporabnik prilagodi uporabniški vmesnik (rezultat X). Podatke pridobimo z uporabniškim testom in opazovanjem obnašanja uporabnika ob delu.
2. Koliko časa uporabnik porabi za prilagoditev uporabniškega vmesnika svojim potrebam (rezultat Y). Podatke pridobimo s štetjem prilagoditev v uporabniškem vmesniku v določenem časovnem intervalu.
3. Trud, ki ga mora uporabnik vložiti v prilagajanje uporabniškega vmesnika (rezultat Z). Opazovanje uporabnika na delu ter ocenitev njegovega truda (napora).
Meritev in formula Interpretacija
meritev Tip metrične skale
Tip meritve Vložek meritve
X = {1, 2, 3} 1 - Ne 2 – Delno (samo barvo ozadja, barvo črk itd.) 3 – V celoti (postavitev polj, lastnosti polj itd.)
X = 2 in X = 3 sta sprejemljiva odgovora.
Ordinalna skala
X = odgovor
Anketiranje uporabnika in poročilo testa.
68
Y = A/T A - število prilagoditev na uporabniškem vmesniku T – potreben čas
0 <= Y Večji kot je Y, bolje je.
Razmična skala
A = štetje T = čas za prilagoditve Y = štetje/ čas
Uporabniška dokumentacija in opazovanje uporabnika pri delu.
Z = {1, 2, 3} 1 – malo napora, prilagajanje je enostavno 2 – nekaj napora 3 – veliko napora, prilagajanje je zahtevno
Z = 1 in Z = 2 je sprejemljivo.
Ordinalna skala
Z = ocena Uporabniška dokumentacija in opazovanje uporabnika pri delu.
Učenje meri:
1. Koliko časa traja, da se uporabnik nauči uporabljati določeno funkcijo (rezultat X). Podatke pridobimo tako, da izvedemo uporabniški test in opazujemo vedenje uporabnika (lahko s pomočjo kamere).
2. Razumljivosti uporabniške dokumentacije (rezultat Y). Odgovor uporabnika na vprašanje.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = T T – čas, ki je potreben, da se uporabnik nauči uporabljati dodatno funkcijo.
0 < T Krajši čas je boljši.
Razmernostna skala
T – čas
Poročilo testa. Pregled kamere.
Y = {1, 2, 3} 1 – ne 2 – delno 3 - da
Y=1 in Y=2 je sprejemljivo.
Ordinalna skala
Y = odgovor
Odgovor na vprašanje.
Pomoč meri:
1. Kakšen sistem pomoči je na voljo uporabniku (rezultat X). Na osnovi vprašanja oziroma uporabniške dokumentacije dobimo odgovor.
2. Kako pogosto uporabnik dostopa do pomoči, da opravi določeno opravilo (rezultat Y). Izvedemo uporabniški test in opazujemo vedenje uporabnika.
3. Koliko časa potrebuje uporabnik, da najde želeno vsebino pomoči (rezultat Z). Merimo čas, ki ga uporabnik potrebuje, da najde želeno vsebino.
Meritev in formula Interpretacija meritev
Tip metrične skale
Tip meritve Vložek meritve
X = {0, 1, 2,3} 0 – ni vgrajene pomoči 1 – vgrajena pomoč – vsebina razdeljena po poglavjih 2 – vgrajena pomoč – interaktivna pomoč v ERP 3 – vgrajena pomoč – interaktivna pomoč v ERP in tudi dodatna pomoč na spletni strani proizvajalca
X = 0 ni sprejemljivo.
Ordinalna skala
X = odgovor
Uporabniška dokumentacija in odgovor na vprašanje.
Y = A A – število dostopov do pomoči med opravljanjem določenega opravila
0 <= Y Y bližje 0, je bolje.
Razmična skala
A = štejte Y= štetje
Poročilo testa.
Z = T T – čas, ki je potreben, da uporabnik najde želeno vsebino
0 < T Krajši čas je boljši.
Razmernostna skala
T = čas Poročilo testa oz. izmerjen čas.
69
Vsaka organizacija ima posebne zahteve, zato mora zgoraj predstavljen sistem metrik prilagoditi svojemu okolju in določiti težo posameznih metrik preden izvede ocenitev s pomočjo sistema metrik. Na primer v organizacijah, kjer je varnost podatkov izrednega pomena, bodo dali večjo težo metriki varnosti. Medtem ko bodo imele metrike učinkovitosti, produktivnosti in zadovoljstva manjšo težo v končnem seštevku. Ocenitev s pomočjo metrik za ocenjevanje kakovosti v uporabi pa ne upošteva ekonomskih kriterijev ocenitve rešitve ERP, kar bomo razložili v naslednjem poglavju.
4.5 Ocena investicije
Organizacija mora oceniti, katera izmed rešitev ERP bo najbolj povečala dolgoročni dobiček organizacije in prispevala tudi k uresničevanju drugih ciljev organizacije. Proces odločanja o investiciji zajema naslednje faze (Rebernik, 1999, 363):
1. določitev potreb po investiranju, 2. določitev investicijskih projektov, 3. vrednotenje posameznih projektov po vnaprej določenih kriterijih in metodah in 4. izbira projekta, ki najbolje zadovoljuje investicijsko potrebo in prispeva k
uresničevanju ciljev organizacije. Da lahko sprejmemo investicijsko odločitev, potrebujemo dva elementa:
1. podatkovno podlago za odločanje in 2. odločitveni model.
Podatkovno podlago lahko predstavlja denarni tok, ki ga moramo ugotoviti za vsak projekt, odločitveni model pa predstavljajo metode vrednotenja investicijskih projektov. Vrednotenje projekta mora temeljiti na strateških, tehničnih in ekonomskih kriterijih (Cotterell in Hughes, 1995, 37). Strateško vrednotenje temelji na strateškem planu, kjer so določeni cilji informacijskega projekta, lahko pa tudi vloge in plan izvedbe informacijskega projekta. Tehnična ocenitev novega sistema sestavlja vrednotenje zahtevane funkcionalnosti nasproti zmožnostim strojne in programske opreme. Ekonomsko vrednotenje informacijskih projektov pa temelji na analizi stroškov in koristi (angl. cost-benefit analysis) uvedene rešitve ERP. Ekonomsko vrednotenje primerja pričakovane stroške in prednosti uvedenih rešitev ERP. Standardna pot vrednotenja po ekonomskih kriterijih vsakega informacijskega projekta vključuje sledeče:
1. določiti in oceniti vse stroške in koristi (prednosti), ki se bodo pojavile v življenjskem ciklu rešitve ERP, in
2. izraziti te stroške in koristi v primernih enotah. Vrednotimo donos, ki je razlika med celotnimi prednostmi in celotnimi stroški.
Pred začetkom projekta uvedbe rešitve ERP morajo biti ocenjeni stroški strojne opreme, operacijski sistem, licenčnina za podatkovno bazo, licenčnina za rešitev ERP, licenčnina za dodatne module, integracije z drugimi IS, prilagajanja programske opreme, pretvorbe podatkov, projektnega managementa, svetovanja, izobraževanja, potovanja in nadgradenj (Harwood, 2004, 54). Omenjeni stroški so lahko enkratni (npr. stroški za nakup strojne opreme) oziroma ponavljajoči (npr. stroški vzdrževanja). Večino teh podatkov nam zagotovi ponudnik rešitve ERP. Poleg tega pa moramo upoštevati tudi indirektne stroške, ki vključujejo:
70
• čas in stroške zaposlenih na projektu, • stroške, povezane z nadomestno delovno silo projektnega tima za običajna opravila, • stroške, povezane s potovanjem in izobraževanjem ter • stroške, povezane z notranjimi viri (npr. oddelek IT).
Celotne stroške rešitve ERP vidimo razdeljene v tabeli 8. TABELA 8: Celotni stroški rešitve ERP v odstotkih
Enkratni Ponavljajoči Direktni stroški: Strojna oprema Programska oprema Vzdrževanje ponudnika ERP Programiranje Izobraževanje Svetovanje
5 – 10 % 25 – 30 %
5 %
10 % 15 – 20 %
20 – 30 %
Indirektni stroški: Zaposleni
10 %
5 %
Vir: prirejeno po Harwood (2004, 56) Večino stroškov rešitve ERP lahko enostavno določimo in ovrednotimo v denarju, medtem ko prednosti (koristi) rešitve ERP težje denarno ovrednotimo. Vseeno pa jih lahko razdelimo na tri kategorije (Cotterell in Hughes, 1995, 41; tabela 8):
• direktne prednosti rešitve ERP (npr. zmanjšanje papirnih računov), • indirektne prednosti (npr. povečanje točnosti, prijaznejši uporabniški vmesniki) ter • neotipljive prednosti, ki so ponavadi dolgoročne prednosti projekta in jih je težko
denarno ovrednotiti. Za vrednotenje po ekonomskih kriterijih s pomočjo analize stroškov in koristi lahko uporabimo statične ali dinamične metode vrednotenja. Statične metode v nasprotju z dinamičnimi metodami ne upoštevajo časovne vrednosti denarja, različne dinamike vlaganj in drugačne dinamike donosov. Med statičnimi metodami se najpogosteje uporabljata koeficient rentabilnosti in metoda vračilnega obdobja. Med dinamičnimi metodami pa metoda neto sedanje vrednosti (Rebernik, 1999, 363). Koeficient rentabilnosti Koeficient rentabilnosti (s kratico ROI, angl. return on investment tudi ARR – accounting rate of return) omogoča primerjavo neto dobička proti investiciji. Obstaja več variacij te formule, vendar se najpogosteje uporablja spodnja formula.
100ainvesticijcelotna
dobicekletnipovprcniROI ×=
Prednosti metode so: prepoznamo profit ali izgubo investicije, je konsistentna in je povezana z računovodskimi podatki, enostavno izračunavanje. Slabosti: ne moremo prepoznati časovne vrednosti denarja, predvideva, da prednosti investicije trajajo amortizacijsko dobo, ne meri vsote oz. časa denarnega toka.
71
Metoda vračilnega obdobja Metoda vračilnega obdobja (angl. payback period) računa čas, ki je potreben, da se povrne začetna investicija. Anderegg et al (2000, 408) opisujejo življenjsko dobo rešitve ERP med 3 in 15 leti, s povprečjem med 5 in 7 leti.
jaamortizacizaslužekletniainvesticijnetoeinvesticijObdobje
+=
Prednosti metode so: enostavno izračunavanje in razumevanje formule, dovolj dober pokazatelj investiranja, meri povračilo denarja, uporaba časovnih območij lahko pomaga določiti riziko investicije, poudarek je na začetnem denarnem toku. Slabosti metode so: ne prepozna časovne vrednosti denarja, ne upošteva prihodkov rešitve ERP po odplačilu investicije. Metoda neto sedanje vrednosti Neto sedanja vrednost (angl. net present value) ocenjene donose v prihodnjih letih diskontira (prevede) na sedanjo vrednost.
tr1tletuvvrednostvrednostsedanja
)( += , kjer je r – obrestna mera, t- število let
ainvesticijr1
donosvrednostsedanjaneton
1ttt −
+=∑
= )(
Prednosti metode: primerno ovrednoti časovno vrednost denarja, daje težo času in vrednosti denarnega toka, omogoča rangiranje in primerjavo investicijskih projektov Slabosti metode: težje izračunljiva, ne sovpada najbolje z računovodskimi principi dobička in izgube, predvideva, da je denar lahko reinvestiran z isto obrestno mero, kot je odbitek projekta. Če ima več projektov pozitivno neto sedanjo vrednost, potem izberemo tistega, pri katerem je le ta največja. Metoda cost-benefit Metoda cost-benefit oz. metoda stroškov–koristi nam omogoča izračun, ali nam investicija prinaša več koristi kot stroškov oziroma obratno. To storimo tako, da od vseh koristi investicije odštejemo vse stroške investicije. Formulo cost-benefit lahko uporabimo tudi tako, da ugotovimo sedanjo vrednost neto koristi s pomočjo sedanje vrednosti bodočih stroškov in sedanje vrednosti bodočih koristi (formula spodaj).
∑= +
−=
n
1tttt
r1SKkoristinetovrednostsedanja)(
, kjer je K– korist, S- strošek, t – leto in r – diskontna stopnja
Prednosti metode so: razumljiva in enostavno izračunljiva, dovolj dober pokazatelj investiranja, meri povračilo denarja. Slabosti: ne meri primerno časovne vrednosti denarja, omejena je možnost primerjav in rangiranja projektov rešitev ERP ter ne vzame v obzir variacij v prihodnjih izboljšavah.
72
Kot navaja Rebernik (1999, 368), se metoda stroški-koristi najpogosteje uporablja pri velikih investicijsko-razvojnih projektih, kamor spada tudi uvajanje rešitev ERP.
4.6 Management nakupa celovitih informacijskih rešitev
Izbira rešitve ERP mora biti načrtovana kot projekt s formalnimi cilji in določenim urnikom in ne »ad-hoc«. Če se osredotočimo na izbiro, lahko pridemo do izbrane rešitve v enem oz. dveh mesecih (Shields, 2001, 88). Projekt izbire rešitve ERP se zaključi s podpisom pogodbe med organizacijo in izbranim ponudnikom rešitev ERP. Zaradi pogajanj ob podpisu pa lahko podpisovanje pogodbe traja dlje kot smo pričakovali. Na osnovi ovrednotenja rešitev ERP v ožjem izboru s pomočjo odločitvenega modela in ocen investicij, se ključni ljudje v organizaciji na osnovi vnaprej definiranih kriterijev odločijo, katero izmed rešitev ERP v ožjem izboru bomo uvedli. Po odločitvi pa je potrebno zaključiti proces izbiranja rešitev ERP s pogodbo. Pogajanja z izbranim ponudnikom rešitve ERP se začne s standardno pogodbo ponudnika rešitev ERP. V organizaciji moramo biti na to pripravljeni in moramo vedeti (Harwood, 2004, 89): (1) kako se pogaja in (2) vsebino pogajanja. Da se lahko uspešno pogajamo, se moramo na pogajanja temeljito pripraviti. S tem zmanjšamo verjetnost, da bomo spregledali kakšen pomemben predmet pogajanj. Poleg tega se moramo dobro podučiti o ponudniku rešitve ERP, s katerim bomo sklenili pogodbo. Pred podpisom pogodbe pa moramo dobro tudi vedeti, kako je delati z izbranim ponudnikom rešitve ERP in kakšne slabosti ima le-ta. Struktura začetne pogodbe se pri ponudnikih razlikuje, vendar mora vsaka izmed njih vsebovati sledeča poglavja (Harwood, 2004, 89):
• definicije, • ceno, • kdaj bo nameščena, • izobraževanje, • lastništvo, • programske licence, • programsko opremo partnerjev oz. tretjih ponudnikov, • operacijski sistem, • strojno opremo, • poroštvo, • garancijo, • programske napake, • podporo rešitvi ERP, nove nadgradnje in • preklic licenc.
V fazi podpisa pogodbe moramo veliko pozornost nameniti pogodbi in besedam v njej. Tako moramo biti pozorni na:
• način plačevanja; • ali licenčnina temelji na imenih uporabnikov ali na številu uporabnikov; • kaj se zgodi, če programske napake preprečujejo uvedbo določene funkcionalnosti in
jih je mogoče odpraviti samo z novimi nadgradnjami, ki bodo na voljo v prihodnosti; • kakšen je proces kontroliranja programskih prilagoditev in njihovega testiranja ter
obdobje garancije prilagojenih modulov;
73
• kdo je lastnik programskih prilagoditev in s tem v povezavi intelektualne pravice prilagoditev modulov;
• omejitev, kdo in kje se lahko uporablja rešitev ERP; • opredelitev bistvenih dodatnih storitev; • proces reševanja problemov v zvezi s rešitvijo ERP, • garancijsko listino, v primeru, da gre ponudnik v prisilno upravo, itd.
Zavedati se moramo, da s podpisom pogodbe s ponudnikom rešitve ERP sklepamo dolgoročno partnerstvo. Edini način, da se izognemo slabemu sodelovanju v prihodnosti je, da pred podpisom pogodbe dobro preverimo izbranega ponudnika rešitve ERP. Kljub temu pa še vedno ni zanesljive garancije, da bo sodelovanje z njim dobro.
74
5 METODE UVAJANJA CELOVITIH INFORMACIJSKIH
REŠITEV
Metodologija opredeljuje običajen pristop izvedbe določenega poslovnega procesa oziroma procedure (Shields, 2001, 202). Metodologija uvedbe rešitve ERP vključuje:
1. metodo strukturiranja projekta, imenovano struktura WBS (angl. work breakdown structure),
2. opis opravil (angl. task description) in 3. primere delovanja (angl. deliverable examples).
Poleg tega pa so danes ponavadi metodologije na voljo »online«, kar omogoča lažje delo projektni skupini. Metodologija pa mora vključevati tudi glavne mejnike v uvedbi rešitve ERP in njihove rezultate. Rezultati morajo biti odobreni, preden se lahko prestavimo na naslednjo fazo uvedbe rešitve ERP. V konceptualnem modelu hitre uvedbe (poglavje 3.2.1) imamo tri stopnje, ki so: predprojektne aktivnosti, projektne aktivnosti in aktivnosti po zaključku projekta. Vsaka izmed stopenj je razdrobljena na več aktivnosti, le te pa so razdeljene na več opravil. Vse aktivnosti in posamezna opravila so določene v strukturi WBS in služijo projektnemu timu kot zemljevid pri opravljanju posameznega opravila ter omogočajo projektnemu timu pogled na povezave med posameznimi opravili. Splošna struktura WBS rešitve ERP se za posamezno organizacijo prilagodi posebnostim projekta in je ponavadi dokumentirana v projektnem planu. Za posamezno stopnjo, aktivnost in opravilo je v metodologiji opis, kaj je potrebno storiti, da se prestavimo na naslednje opravilo, aktivnost oz. stopnjo. Najpodrobnejše informacije so na voljo za raven opravil, kjer metodologija zagotavlja informacije o ciljih opravil, ključne inpute in outpute opravil, privzet postopek izvedbe opravila in namige pomoči, s pomočjo katerih se izognemo pastem pri uvedbi. Na ravni opravil vsebuje metodologija primere delovanja. Vsako opravilo, opredeljeno v metodologiji, nam vrne nek rezultat, ki je dokumentiran. Ti primeri pomagajo voditi projektni tim pri delu in pri pripravi dokumentacije. Člani vnaprej pripravljene primere prilagodijo svojim potrebam uvedbe rešitve ERP. Tako metodologija uvedbe rešitve ERP zagotavlja več prednosti, kot so (Shields, 2001, 204):
• boljša konsistentnost med člani projektnega tima, saj vsi člani, ki opravljajo isto delo, delajo po istem postopku, zato lahko pričakujemo tudi enake rezultate;
• raven podrobnih zahtev je lažje določiti ter • kakovost opravljenega dela in status opravil je enostavneje verificirati.
Po zagonskemu sestanku (angl. kick off meeting) mora projektni tim spoznati in se naučiti uporabljati metodologijo uvedbe izbrane rešitve ERP. Vsak član tima mora razumeti pristop uvajanja rešitve ERP in kako se bo njegova/njena vloga vključevala v celotni projekt. Zaradi posebnosti posameznih rešitev ERP danes večina ponudnikov rešitev ERP in svetovalne hiše ponujajo lastne metodologije uvajanja rešitev ERP, kot npr. metodologija ASAP rešitve MySAP ERP. Poleg tega pa večina ponudnikov v okviru svoje metodologije oziroma poleg nje ponuja tudi druge pospeševalce, kot so:
1. procesni modeli prilagojeni za izbrano rešitev ERP; 2. vnaprej prilagojena verzija rešitve ERP panogi organizacije, t. i. »vanilla« verzija; 3. izobraževanje projektnega tima v trenutku, ko ti le-to potrebujejo;
75
4. dodatne aplikacije in module ponudnika rešitev ERP oz. njegovih partnerjev, ki segajo preko osnovne funkcionalnosti rešitev ERP, kot npr. modul e-poslovanja;
5. priročniki uporabniških postopkov oziroma procedur; 6. »online« pomoč ponudnika rešitve ERP; 7. priročniki za izobraževanje končnih uporabnikov; 8. podporo prilagajanju s pomočjo vnaprej prilagojenih verzij in načrtovalskih knjig
(angl. design book), ki opisujejo vse nastavitve parametrov in njihov vpliv na delovanje rešitve ERP in druge parametre;
9. avtomatizirani vmesniki za pretvorbo podatkov in vnaprej pripravljeni vmesniki s pomočjo t. i. API-jev (angl. application programming interfaces).
V nadaljevanju poglavja bomo opisali različne pristope uvajanja rešitev ERP, metodologiji ASAP in On Target ter naredili osnovno primerjavo med njima.
5.1 Pristopi k uvajanju celovitih informacijskih rešitev
Uvedba rešitve ERP je proces namestitve sistema ERP. V začetnem obdobju uporabe rešitev ERP so organizacije uporabljala tradicionalni pristop uvedbe, ki je bil sestavljen iz petih zaporednih faz (Shields, 2001,33):
1. obseg in planiranje, 2. vizija, 3. razvoj, 4. gradnja in 5. uvedba.
Slabost tega pristopa je bila zaporednost faz, saj je projektni tim lahko začel z naslednjo fazo uvedbe takrat, ko je bila prejšnja faza zaključena in preverjena. Tako je uvajanje rešitev ERP trajalo več let, rezultati rešitve ERP pa so bili vidni šele ob koncu uvedbe. Zaradi slabosti tradicionalnega pristopa se pri uvedbi rešitev ERP danes uporabljajo naslednji pristopi (Anderegg et al, 2000, 115-128, Robson, 1994, 371-372; O'Leary, 2000, 151 - 162):
1. pristop velikega poka (angl. big bang), 2. fazni pristop (angl. phased approach), 3. vzporedni pristop (angl. parallel approach), 4. procesno orientiran pristop (angl. proces line strategy) in 5. hibridni pristop (angl. hybrid strategy).
5.1.1 Pristop velikega poka
Metoda velikega poka predvideva, da na točno določen dan zaključimo delo v obstoječem IS in začnemo opravljati opravila v uvedeni rešitvi ERP (slika 29). Če želimo, da bo ta pristop uspešen moramo skrbno planirati uvajanja rešitve ERP in dobro testirati uvedeno rešitev ERP, pred dnevom zagona v živo. Glavna prednost metode velikega poka je, da ni potrebno pripraviti vmesnikov med obstoječimi IS in uvedeno rešitvijo ERP (Anderegg et al, 2000, 116). Druge prednosti tega pristopa pa so (O'Leary, 2000, 152):
• nižji stroški uvedbe kot pri ostalih pristopih, • manjše tveganje, saj se celotna projektna skupina posveti projektu in je zato delo bolj
usmerjeno in koordinirano v izvedbo projekta ter • krajši čas uvedbe.
76
Pomanjkljivosti tega pristopa pa so: čas in stroški priprav, pomanjkanje kritičnih virov in pomanjkanje profesionalnih izkušenj pri uvedbi rešitve ERP (Anderegg et al, 2000, 116). O'Leary (2000, 156) pa dodaja, da je ob neuspešni uvedbi rešitve ERP nemogoče preiti nazaj na stare IS. Tveganje zaradi pomanjkanja kritičnih virov lahko zmanjšamo z metodo malega velikega poka (angl. mini big bang), kjer proces uvedbe rešitve ERP razdelimo na dva ali več delov. Vsak del je sestavljen iz več povezanih modulov, kot npr. iz finance, distribucije in proizvodnje, ki se uvedejo na enak način kot z metodo velikega poka (slika 29). SLIKA 29: Pristop velikega poka in malega velikega poka
Finance
Nabava
Skladiščenje
Prodaja
MRP
Delovni nalogi
Kadrovskisistem
ZagonOBSTOJEČI SISTEM NOVI ERP SISTEM
Finance
Nabava
Skladiščenje
Prodaja
MRP
Delovni nalogi
Kadrovskisistem
ZagonOBSTOJEČI
SISTEMNOVI ERPSISTEM
Zagon
Vir: prirejeno po Anderegg et al (2000, 114 in 117) in Kežmah (2003, 59) Poleg pristopa malega velikega poka obstaja tudi pristop mega veliki pok (angl. mega big bang) in multi veliki pok (angl. multi big bang). Mega veliki pok se uporabi takrat, kadar ima organizacija več sedežev in na vseh sedežih istočasno zažene uvedeno rešitev ERP v živo. Multi veliki pok (angl. multi big bang) uporablja zaporedno strategijo velikega poka na različnih geografskih območjih. Korporacija z eno projektno organizacijo najprej uvede rešitev ERP na enem mestu s pomočjo pristopa velikega poka, nato se prestavi na drugo mesto in uvede rešitev ERP po istem pristopu itd.
5.1.2 Fazni pristop
Fazni pristop omogoča zaporedno uvajanje modulov rešitve ERP, tako da najprej uvedemo en modul, in ko je le-ta uveden, uvedemo naslednji modul. Postopek ponavljamo, dokler ne uvedemo vseh izbranih modulov rešitve ERP. Ponavadi najprej uvedemo finančne module in se šele nato lotimo uvajanja modulov materialnega toka. Ker uvajamo en funkcijski modul naenkrat, potrebujemo manjšo projektno organizacijo, ki se lahko bolje posveti uvedbi posameznega modula. Poleg tega pa potrebujemo tudi manj ostalih kritičnih virov v posamezni fazi uvedbe. Kot navaja O'Leary (2000, 154-155), so prednosti tega pristopa tudi manjši riziko, saj sočasno vpeljujemo samo en modul, projektni tim pa si iz uvedbe modula v modul pridobiva več znanja in izkušenj z uvajanjem le-teh. Glavna slabost tega pristopa je, da zaradi postopnega uvajanja modulov ne uvedemo vseh potrebnih modulov hkrati in je zato potrebno pripraviti vmesnike med starimi IS in uvedenimi moduli rešitve ERP, kar povečuje stroške in čas uvedbe. Poleg tega moramo v času uvedbe rešitve ERP vzdrževati dva sistema (obstoječe IS in rešitev ERP) ter podaljša se čas uvedbe.
77
5.1.3 Vzporedni pristop
Vzporedni pristop uporabljajo podjetja, kjer je nemoteno poslovanje izredno pomembno (npr. banke in farmacevtska podjetja). Za ta pristop je značilno, da oba sistema: obstoječi IS in uvedena rešitev ERP, delujeta sočasno nekaj mesecev. Prednost takšnega pristopa je možnost hitre obnovitve obstoječih IS ob izpadu rešitve ERP. Poleg tega lahko sproti preverjamo točnost podatkov med starim in novim sistemom. Vendar zaradi tega potrebujemo več virov, tako strojne opreme, programske opreme, ljudi itd. Poleg tega se podatki podvajajo, saj morajo zaposleni dvakrat vnašati podatke - tako v stari sistem kot tudi v novi sistem, kar povzroča dodatne stroške. Dodatnih stroškov dvojnih delujočih sistemov se lahko izognemo z izvedenko vzporednega pristopa imenovano papirno vzporedni pristop (angl. paper parallel approach), kjer namesto dveh delujočih sistemov (starega in novega) zapisujemo vse transakcije starih IS na papir.
5.1.4 Procesni pristop
Procesno orientiran pristop je podoben pristopu malega velikega poka (opisan zgoraj). V procesu priprave uvedbe rešitve ERP razdelimo poslovanje organizacije na vzporedne diagrame poslovnih procesov oziroma proizvodnih linij. Nato najprej uvedemo rešitev ERP za enostavnejši poslovni proces. Ko zaključimo uvedbo le tega, pričnemo z uvedbo naslednjega, zahtevnejšega poslovnega procesa itd. Zaradi manjšega tveganja in večje možnosti uspeha, ponavadi najprej uvedemo enostavnejšo procesno linijo (oz. poslovni proces) in nato glede na težavnost še ostale procesne linije.
5.1.5 Hibridni pristop
Hibridni pristop je kombinacija procesnega, faznega in vzporednega pristopa. Slabost tega pristopa je, da je na začetku redkokdaj dobro planiran. Prednost tega pristopa pa je, da ni nujno fiksen, pač pa se lahko prilagaja med uvajanjem rešitve ERP, npr. na začetku uporabi projektni tim fazni pristop in ko s pomočjo le-tega spozna več o uvajanju modulov, lahko preklopi na drug pristop.
5.2 Metodologija ASAP
5.2.1 Uvod
Podjetja SAP AG33 uporablja pri prodaji svojih rešitev metodologijo, ki jo imenuje SAP Customer Engagement Lifecycle oz. s kratico model CEL (slika 30). Model CEL je razdeljen na več nivojev, kjer jedro modela predstavlja vrednost kupca. Za zagotovitev vrednosti kupca, pa ga obdajajo štiri faze, ki so (SAP, CEL…):
1. odkritje (angl. discovery), 2. vrednotenje (angl. evaluation), 3. uvedba (angl. implementation) in 4. delovanje (angl. operations).
33 Matično podjetje SAP AG je v nemškem Walldorfu in je bilo ustanovljeno leta 1972. Danes je SAP prepoznan kot vodilni proizvajalec rešitev ERP in kot tretji največji proizvajalec programske opreme na svetu z 12 milijoni uporabnikov, 64.500 namestitev, 1500 parnterji in 23 industrijskimi rešitvami. V podjetju SAP je zaposlenih preko 28.900 ljudi iz več kot 50 držav (Vir: http://www.sap.com/company/). V Sloveniji je podružnica podjetja SAP, v kateri je zaposlenih 20 ljudi. V Sloveniji je trenutno 65 podjetij, ki uporabljajo ali uvajajo Sapove rešitve. (Vir: http://www.sap.com/slovenia/company/ ).
78
Te faze so nadalje razdeljene na podfaze. Faze in podfaze vodijo podjetje SAP in stranke pri določanju, nameščanju, delovanju in urejanju rešitev SAP tako, da se rešitev kar najbolje prilega potrebam strank. Prodajno metodologijo CEL zaključuje t. i. »Account management«, s pomočjo katerega zaposleni SAP-a, v sodelovanju s strankami izvedejo faze in podfaze čim učinkoviteje. Vloga Account managementa je zagotoviti vse aktivnosti povezane s strankami, kot so npr. možnost razvoja, projekti uvedbe, interakcija s partnerji, nepretrgane poslovne izboljšave. V Account management je za vsako vrsto posla razvito več managerskih in delovnih procesov, vsak proces pa je nato določen z naslednjimi karakteristikami: povzetkom procesa (kaj), namenom in cilji procesa (zakaj), časom izvedbe procesa (kdaj), sodelujočimi v procesu (kdo), koraki procesa (kako), pregledom izvedenega procesa na osnovi v naprej določenih mejnikov, rezultatov procesa (output), katere vsebine, orodja, predloge in metodologije so uporabljene v procesu, kateri inputi vstopajo v proces in kateri outputi izstopajo iz procesa itd. SLIKA 30: Metodologija CEL
Vir: prirejeno po SAP AG (2002)
Prva faza modela CEL se imenuje »Odkritje«. V tej fazi organizacije iščejo primerne rešitve na trgu, medtem ko marketinški oddelki SAP-a iščejo potenciale kupce na trgu ter jim ponujajo pomoč pri izvedbi njihovih poslovnih ciljev. Ta faza je razdrobljena na tri podfaze. V podfazi »Poslovno planiranje« (angl. business planning) organizacija pripravi poslovne plane, kjer so razvidne ključne prednosti in slabosti poslovanja ter področja, na katera morajo biti pozorni, če želijo ostati konkurenčni. V tem času SAP skuša razumeti prioritetna ključna področja organizacije in povezane zahteve na trgu. V podfazi »Poslovne iniciative« (angl. business initiatives) organizacija opredeli posebne potrebe v poslovnem planiranju ter pripravi razpored potrebnih virov. SAP v tej podfazi aktivno spremlja izvajanje aktivnosti, ki so
79
usmerjene k zajemu priložnosti. V podfazi »Ocenitev« priložnosti (angl. opportunity assessment) se opredelijo in ocenijo poslovne iniciative. Na osnovi teh podrobnih zahtev, začne organizacija iskati primerno rešitev. SAP pa vzporedno raziskuje, kako bi njihova rešitev lahko reševala poslovne izzive, s katerimi je soočena organizacija. Faza »Vrednotenje« se nanaša na podrobno ocenitev poslovnih rešitev s strani organizacije. SAP priskoči na pomoč tako, da oblikuje mešani funkcijski tim, ki dobro razume poslovanje organizacije, njene poslovne izzive in priložnosti in pripravi načrt rešitve. Ta načrt rešitve ni povzetek obstoječega stanja, pač pa vključuje tudi opredeljene priložnosti s prejšnje faze. Faza vrednotenja je sestavljena iz petih podfaz in se začne s podfazo »Razumevanje« (angl. understanding). Organizacija v prejšnji fazi določi ključne priložnosti, SAP in organizacija pa v tej fazi poskušata podrobneje razumeti potrebe in cilje organizacije in poiščeta potencialno rešitev, ki bi se kar najbolje prilegala organizacijskim poslovnim ciljem. Podfaza »Rešitev« (angl. solution) se nanaša na razumevanje posebnih poslovnih potreb organizacije. SAP pomaga organizaciji razviti predlog rešitve, ki se najbolje prilega njenim potrebam. Podfaza »Dokaz« (angl. proof) temelji na vzpostavitvi zaupanja v organizaciji, da bo predlagana rešitev zadovoljila poslovne potrebe organizacije. V podfazi »Upravičenje« (angl. justification) je potrebno preveriti, ali predlagana rešitev zadovoljuje potrebe poslovnih vodij s pomočjo predlogov v obliki poslovnih primerov za določene ravni. Faza se zaključi s podfazo »Dogovor« (angl. agreement). Če se organizacija odloči za uvedbo rešitve podjetja SAP, se v tej fazi uskladijo pogoji nakupa in predviden čas uvedbe rešitve SAP. V fazi »Uvedba« (angl. implementation) SAP pripravi in uvede skupaj z organizacijo prilagojeno rešitev SAP-a. Faza uvedbe rešitve mySAP ERP je podrobneje opisana v nadaljevanju poglavja. V fazi »Delovanja« (angl. operations) SAP sodeluje z organizacijo tako, da pomaga organizaciji ustaliti svoje delo, ki s tem doseže realizacijo pričakovanih poslovnih prednosti. Med fazo delovanja SAP vzdržuje sodelovanje z organizacijo preko izboljšav, sprememb oziroma razširitev rešitve ter tako pripomore k novemu dodajanju vrednosti kupcu. Ta faza je razdeljena na tri podfaze. V podfazi »Ustalitev« (angl. stabilize) se ocenijo rezultati in preveri delovanje rešitve, kot je bilo določeno v podfazi »Dogovor«. V podfazi »Optimiranje« (angl. optimize) SAP z nenehnimi izboljšavami poslovne rešitve zagotavlja, da se uvedena rešitev prilagaja spremembam poslovnih potreb in okolju. V podfazi »Nastajanje« (angl. evolve) se na strani organizacije pojavljajo nove razvojne vizije in strategije, ki silijo organizacijo v nadaljnji razvoj. To pa predstavlja priložnost za SAP za uvedbo dodatnih modulov rešitve SAP ter s tem še na bolj poglobljen odnos med SAP in organizacijo.
5.2.2 Metodologija ASAP
MySAP ERP iz družine rešitev mySAP Business Suite podjetja SAP AG je danes najbolj pogosto uporabljena rešitev ERP za prenovo poslovnih procesov v velikih in srednje velikih organizacijah. Družina rešitev mySAP Business Suite podjetja SAP je sestavljena iz naslednjih rešitev34:
• MySAP ERP je temelj rešitve mySAP Business Suite35. Ponuja zaključeno funkcionalnost za analitiko, finance, upravljanje kadrov, operativo in storitve. Poleg tega vključuje tudi funkcionalnost administracije, upravljanje podatkov, prilagajanje in
34 Vir: http://www.sap.com/slovenia/solutions/business-suite/index.aspx (1.8.05) 35 Vir: http://www.sap.com/slovenia/solutions/business-suite/erp/index.aspx (1.8.05)
80
upravljanje spletnih storitev. Vse je podprto s tehnološko platformo SAP NetWeaver. MySAP ERP je razvit tudi za panožno specifične rešitve in temelji na najboljših praksah več kot 30-letnih izkušenj SAP. Poleg tega mySAP ERP ponuja celovito rešitev za podporo poslovanja med državami.
• MySAP Customer Relationship Management (mySAP CRM) omogoča popolno integrirano rešitev CRM, ki pospešuje storitve z vseh vidikov kupca.
• MySAP Product Lifecycle Management (mySAP PLM) omogoča načrtovalcem, inženirjem in dobaviteljem, da dosežejo novo raven inoviranja.
• MySAP Supplier Relationship Management (mySAP SRM) pokriva dobavni krog organizacije ter s tem, ko vključuje dobavitelje v ta krog, znižuje stroške dobave ter pohitri proces dobave.
• MySAP Supply Chain Management (mySAP SCM) je rešitev SCM, ki omogoča da izboljšamo planiranje, odzivnost in izvedbo dobave.
Celotna družina rešitev je grajena na platformi SAP NetWeaver, ki je odprta integracijska in aplikacijska platforma SAP. Organizacija, ki se odloči, da bo uvedla rešitev mySAP ERP, lahko za to uporabi metodologiji podjetja SAP ali pa metodologije drugih svetovalnih podjetij. Po raziskavi podjetja Input (Input, 1999; povzeto po Estaves et al, 2002, 4) so organizacije bolj zadovoljne z metodologijama podjetja SAP in z njihovimi orodji. Zaradi zahtevnosti uvedbe SAP rešitev sta danes znani dve metodologiji (Khan, 2002, 48):
1. standardna, znana tudi kot SAP postopkovni model (angl. SAP Procedure Model) in 2. metodologija pospešenega SAP-a36.
Organizacije so v preteklosti za uvajanje rešitev SAP uporabljale standardno metodologijo, danes pa uporabljajo predvsem metodologijo ASAP. Kljub temu se standardna metodologija še vedno uporablja kot prednostna metodologija pri uvajanju v zelo velikih organizacijah, predvsem v tistih, kjer prihodek presega milijardo dolarjev. Standardna metodologija SAP je sestavljena iz štirih faz (Bancroft et al, 2001, 43):
1. organizacijski in konceptualni dizajn, 2. podroben dizajn in uvajanje, 3. priprava na proizvodnjo in 4. proizvodne operacije.
Standardna metodologija zahteva zelo podrobno analizo obstoječih sistemov, funkcionalnost in postopnost poslovnih procesov. Veliko časa porabi projektni tim za usklajevanje obstoječega sistema in uvedene rešitve SAP, saj rešitev prikrojimo obstoječim procesom. Odločanje je zelo počasno in temelji na soglašanju, za katerega je potreben čas. Slaba stran te metodologije je, da podjetja poskušajo uvesti zrcalno sliko obstoječih procesov. Poleg tega pa to metodologijo ponavadi spremlja prekoračitev predvidenega časa in stroškov uvajanja. Zato je podjetje SAP razvilo metodologijo, ki jo je poimenovalo pospešena SAP-metodologija oz. s kratico metodologija ASAP. Medtem ko je uvedba rešitve SAP s standardno metodologijo lahko trajala tudi več let, so ASAP-projekti ponavadi vpeljani v manj kot enem letu. Primerjavo standardne in metodologije ASAP lahko vidimo v tabeli 9. Kljub boljšim rezultatom metodologije ASAP se podjetja, v katerih je potrebna obširna prenova poslovnih procesov, raje odločijo za standardno metodo implementacije.
36 V nadaljevanju bomo za »pospešeno metodologijo SAP« uporabljali kratico ASAP - metodologija (angl. Accelerated SAP methodology).
81
TABELA 9: Primerjava ASAP in standardne metodologije
ASAP-metodologija Standardna metodologija Časovni okvir Hitra uvedba Počasna uvedba Pristop Hiter, brez podrobnih analiz Temelji na podrobnih analizah in
soglašanju Prenova poslovnih procesov
Zaradi osvojitve novih poslovnih procesov je večja
Manjša zaradi težnje po zrcalni sliki obstoječih procesov
Funkcionalnost »Vanilla« pristop37 Običajen pristop Uvedba rešitve ERP Osredotočena in omejena Obširna Konfiguracija Večino opravijo svetovalci Veliko sodelovanje zaposlenih Nadgradnje Zahtevajo manj testiranja, saj se izvorna
koda minimalno spremeni Več testiranja, zaradi večjih sprememb v
izvorni kodi Stroški Nizki Visoki Dokumentacija Minimalna Obširna Stopnja programiranja
Minimalna Zaradi prekomernih zahtev organizacije je obširna
Število svetovalcev Relativno malo Velik tim strokovnjakov Preobrat zaposlenih Zaradi manj znanja, ki ga pridobijo med
uvajanjem, je manjši Zaradi obsežnega znanja, ki lahko vpliva
na boljše delo, je večji Prenos znanja na zaposlene
Zaradi hitrosti izvedbe projekta uvedbe in pomanjkanja časa svetovalcev je majhen
Zaradi postopnega konfiguriranja s sodelovanjem zaposlenih je velik
Vir: prirejeno po Khan (2002, 50) Za hitro in uspešno uvedbo rešitve mySAP ERP so leta 1996 v podjetju SAP AG razvili metodologijo, ki so jo poimenovali pospešeni SAP. S pomočjo te metodologije lahko uvedemo novo rešitev ERP (mySAP ERP) v nekaj mesecih (Miller, 1998, 2). Cilj metodologije ASAP je učinkovita izraba časa, povečanje kakovosti in učinkovita izraba virov (Larocca, 2002, 94). Kot navaja Khan (2002, 22), so glavne značilnosti metodologije ASAP naslednje:
• optimira čas, kakovost in vire, • zagotavlja najboljšo poslovno prakso, • zagotavlja procesno usmerjen projektni zemljevid (ASAP-zemljevid), • določa stroške uvajanja in načrt dela, • vsebuje poslovne procese, orodja, izobraževanje in podporo, • zagotavlja podrobno pomoč med uvajalnimi fazami, • 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.
Kljub temu, da nobena med uvedenimi rešitvami mySAP ERP ni povsem enaka, je organizacija Aberdeen Group objavila študijo stroškov, ki temelji na treh namestitvah rešitve SAP z uporabo metodologije ASAP. V tej študiji so skupni stroški uvajanja sestavljeni iz: honorarja svetovalcem (36 %), honorarja zaposlenih (21 %), licenčne programske opreme (20 %), stroškov izobraževanja (6 %) in stroškov strojne opreme (17 %) (Khan, 2002, 53). Kot navaja Miller (1998, 11), sestavlja metodologijo ASAP: zemljevid ASAP, orodja ASAP in izobraževanje Sapovih svetovalcev.
37 Projektni tim s konfiguriranjem paketa prikroji sistem tako, da bo ustrezal potrebam podjetja brez spreminjanja njegove izvorne kode.
82
ASAP-zemljevid je podroben projektni načrt uvajanja modulov mySAP ERP z opisom ciljev, aktivnosti, rezultatov in orodij (za vsako opravilo) ter ljudi (Bruges, 2002; Brand, 1999, 4). Zemljevid je razdeljen na pet zaporednih faz (Larocca, 1999, 94; tudi po Khan, 2002, 59):
1. faza: Priprava projekta (angl. project preparation), 2. faza: Poslovni načrt (angl. business blueprint), 3. faza: Realizacija (angl. realization), 4. faza: Končne priprave (angl. final preparation), 5. faza: Zagon v živo in podpora (angl. go-live and support).
Čas uvajanja mySAP ERP z metodologijo ASAP je običajno med 6 in 18 meseci. Podrobnejšo razdelitev mesecev po fazah vidimo v tabeli 10. Zaradi velike časovne omejenosti pri uvajanju rešitve mySAP ERP in zaradi pomanjkanja znanja v organizaciji je priporočljivo, da v projektnem timu sodelujejo svetovalci oz. ASAP-partnerji. TABELA 10: Časovna razporeditev faz metodologije ASAP
Srednje veliko podjetje, kjer traja čas uvajanja 1 leto
Podjetje z letnim prihodkom 2 milijardi dolarjev, kjer je čas uvajanja dolg 18
mesecev Priprava projekta 1 mesec 1 mesec Poslovni načrt 2 meseca 5 mesecev
Realizacija 6 mesecev (2 meseca za simulacijo in 4 mesece za ovrednotenje)
9 mesecev (4 mesece za simulacijo in 5 mesecev za ovrednotenje)
Končne priprave 3 mesece 3 mesece Skupaj 12 mesecev 18 mesecev Vir: prirejeno po Khan (2002, 59) Podjetje SAP poleg svoje metodologije imenuje enako tudi kompleksen program, v katerem najdemo pomoč, orodja in preizkušene tehnike hitrega uvajanja ter nadaljevanje optimizacije rešitve SAP (Miller, 1998, 222). Med njimi so: • ASAP-komponente, ki jih lahko uporabimo v vseh tipih SAP-projektov ter vsebujejo
obrazce, vprašalnike in vodiče. • Referenčni model (angl. reference model) je v celoti grafična, podrobna predstavitev vseh
pogledov vodenja podjetja, vključno z npr. pretokom informacij, podatkovnimi in organizacijskimi strukturami, časovnim zaporedjem izvajanja nalog in kako so vse te sestavine uvedene v mySAP ERP (Bancroft et al, 1998, 302).
• Orodjarna (angl. mySAP ERP toolkid), kamor spadajo: • »Business Engineer« je skupek konfiguracijskih in uvajalskih orodij za modeliranje,
konfiguriranje, uvedbo, nadaljnje izboljšave in dokumentacijo SAP rešitev. Pri svojem delu ga uporabljajo poslovni strokovnjaki, oddelki IT, svetovalci in partnerji vseh vrst podjetij (majhnih, srednjih in velikih). V tem orodju najdemo že pripravljene specifične poslovne procese za pospešeno uvajanje. Poleg tega vsebujejo tudi več kot 1000 pripravljenih poslovnih procesov, več kot 100 posebnih poslovnih scenarijev za industrije in predloge, iz katerih dobimo začetno konfiguracijo sistema. Izdelani so po principu najboljše prakse, omogočajo enostavno konfiguracijo sistema, pomagajo pri prekonfiguriranju, omogočajo interaktivno pregledovanje diagramov poteka (hierarhične strukture poslovnih procesov, organizacijskih enot in funkcij), navigiranju in konfiguraciji itd. (Khan, 2002, 55; Miller, 1998, 221-222).
• »Project Estimator« omogoča točno določanje potrebnih virov, stroškov in časa, ki so potrebni za uvajanje sistema (Miller, 1998, 223). Sestavljen je iz množice vnaprej pripravljenih intervjujev (vprašanj), ki se postavijo upravi podjetja, poslovnim in tehničnim managerjem in tudi članom projektnega tima. Vprašalniki so sestavljeni tako, da lahko iz njih sklepamo: pričakovanja, stopnjo strokovnega znanja v podjetju,
83
stopnjo zahtevnosti poslovnih procesov, obseg projekta, željen čas izvedbe, strokovno znanje Sapovega tima in dejavnike tveganja. S pomočjo zbranih informacij izdela orodje Project Estimator oceno, ki jo uporabijo v dokumentu obsega in projektnem načrtu (Khan, 2002, 56-57).
• »Implementation Assistant« služi kot navigacijsko orodje in vsebuje ASAP-zemljevid, projektni načrt (proračun, vire in delovne načrte) in skladišče raznih informacij (npr. kontrolne sezname ob koncu posameznih faz, tehnična orodja, čarovnike za prilagajanje sistema itd.) (Miller, 1998, 223; Khan, 2002, 57).
• Baza vprašanj in odgovorov itd. SAP ponuja več kot samo enostavno svetovanje in izobraževanje. Vsebuje orodja za podporo in pomoč. Za zagotavljanje popolne podpore in pomoči pri rešitvah SAP ponuja podjetje SAP tudi orodja, kot je EarlyWatch (preventivni servis). Omogoča, da Sapovi strokovnjaki analizirajo sistem, preden gre v fazo zagona v živo, in posredujejo podjetju predloge za optimizacijo sistema in njegove zmogljivosti. Tako se lahko izognemo morebitnim proizvodnim problemom po zagonu v živo. Poleg tega orodja SAP ponuja tudi: on-line podporni sistem, nadzor koncepta in kontrolo pred zagonom v živo. Uvedba celovite informacijske rešitve mySAP ERP s pomočjo metodologije ASAP poteka v petih fazah, ki zajemajo predprojektne aktivnosti (pripravo projekta), projektne aktivnosti (poslovni načrt, realizacijo, končne priprave) ter poprojektne aktivnosti (zagon v živo in podporo)38. Zgradba vsake faze metodologije ASAP je sledeča (Estaves et al, 2002, 4):
• 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. Za uspešno uvedbo rešitve je treba biti pozoren na nekaj ključnih dejavnikov, ki pripomorejo k uspehu. To so: stroški, čas, dolžina uvajanja, orodja pri uvedbi in potrebni viri (Miller, 1998, 23). Faze metodologije ASAP smo priredili po Millerju (1998, 23- 32), Bancroftu (1998, 151-211) in Khanu (2002, 62- 105). Povzemamo jih v nadaljevanju.
5.2.3 Priprava projekta
Preden začnemo s projektom, moramo preveriti organizacijsko pripravljenost in soglasje ključnih članov uprave s prenovo poslovnih procesov v organizaciji. Če se vsi ključni člani uprave ne strinjajo s prenovo, je projekt uvajanja obsojen na propad. Po odobritvi projekta člani uprave izberejo nadzorni odbor, katerega član (ni pa nujno) postane manager projekta (sponzor projekta). Nadzorni odbor in manager projekta izbereta projektnega managerja in projektni tim. V fazi priprave projekta je potrebno določiti zelo jasne projektne cilje. Naloga projektnega managerja je, da začne pripravljati podroben projektni načrt. Poleg tega morajo v organizaciji, v tem obdobju, pripraviti vodilna načela, ki jim bodo pomagala pri lažjih odločitvah v času samega uvajanja. Tako s temeljnimi cilji in vodilnimi načeli pospešimo proces odločanja o projektu. 38 Pri poljubni rešitvi ERP imamo pedprojektne, projektne in poprojektne aktivnosti, ki jih je Shields (2001, 35) strnil v 12 korakov, medtem ko jih imamo pri ASAP-metodologiji pet. Vendar najdemo v teh petih korakih tudi ostale korake poljubne rešitve ERP.
84
Zaradi hitre uvedbe projektni tim na začetku ne pozna zmogljivosti rešitve mySAP ERP. Časa, da bi se v organizaciji sami naučili in vpeljali rešitev, pa tudi ni. Zaradi tega pri vseh uvajanjih sodeluje tim Sapovih svetovalcev ali pooblaščeno svetovalno podjetje, ki ovrednoti potrebe in zahteve. Za lažje vrednotenje obsega uvedbe rešitve ERP ponuja podjetje SAP orodje, ki se imenuje ASAP Project Estimator. To orodje vodi projektni tim skozi vnaprej določena vprašanja. Vsebuje vprašalnike za člane uprave in sistem vplivnih dejavnikov v organizaciji o njihovih pričakovanjih in hitrosti uvajanja. Tim Sapovih svetovalcev nato oceni vsakega od intervjujev in določi obseg projekta ter potrebne vire (čas, stroške in osebje). Ko imamo določen obseg projekta, potrebne vire in izbran projektni tim, lahko začnemo z uvedbo (projektnimi aktivnostmi). Najprej izvedemo začetno izobraževanje za notranje člane projektne skupine o rešitvi mySAP ERP, kjer spoznajo njeno arhitekturo, glavne mejnike uvajanja in osvojijo terminologijo SAP. S pomočjo pridobljenega znanja lahko tim pripraviti podroben načrt dela, ki obsega realistične poslovne procesne diagrame, scenarije in modele poslovnih opravil.
5.2.4 Poslovni načrt
V drugi fazi se na osnovi analiziranja poslovanja, intervjujev in principov najboljše prakse določijo točni cilji in obseg dela. Do konca druge faze projektni tim pripravi v obliki dokumenta podroben načrt. To je zelo obširen dokument z vizualno predstavitvijo modela organizacije. Poleg tega podroben načrt vsebuje tudi: obstoječo funkcionalnost poslovnih procesov in bodočo funkcionalnost, obseg uvedbe, organizacijsko strukturo, odloženo funkcionalnost, praznine in morebitno tveganje ter drugo. V drugi fazi gredo člani projektnega tima in ključni uporabniki na drugo raven izobraževanja, kjer spoznajo poslovne procese oz. module rešitve mySAP ERP, ki jih bodo vpeljali v organizaciji. Po izobraževanju bodo člani tima lahko oblikovali in vzdrževali uvedeno rešitev. Za lažje in hitrejše delo v tej fazi lahko uporabimo orodje »Business Engineer«. V tej drugi fazi tim Sapovih strokovnjakov prilagodi rešitev mySAP ERP tako, da je primeren za naše specifične poslovne procese. Če uporabimo vprašalnike in modele orodja Business Engineer, potem lahko projektni tim določi poslovne procese in s tem predvidi prihodnost poslovanja. Končni rezultat te faze bo celoten poslovni načrt poslovanja. Poslovni načrt ASAP pogosto pomaga določiti ključna področja poslovanja. Poslovni načrt lahko vzpostavimo tudi tako, da določimo konfiguriranje na dveh ravneh. V času, ko so projektni tim in ključni uporabniki na izobraževanju, tim Sapovih strokovnjakov prilagodi standardni sistem do 80 % njegove funkcionalnosti. Ko projektni tim zaključi izobraževanje, prilagodi (prekonfigurira) sistem tako, da bo ustrezal našemu poslovanju in zahtevam naših procesov (preostalih 20 % funkcionalnosti). V teh 20 % projektni tim prilagaja izjemne transakcije. Pri tem mora biti pozoren na prilagajanje sistemskih izjem v rešitvi mySAP ERP. Smiselno je, da tim preveri te izjeme z orodjem Implementation Assistant, ki vsebuje podrobne vodiče testiranja. Projektni tim mora v tej fazi tudi opredeliti podatkovne in sistemske vmesnike, določiti programsko in strojno opremo ter namestiti razvojno instanco.
5.2.5 Izvedba
V tretji fazi se poslovni načrt uresniči. Namesto razvojne instance potrebujemo v tretji fazi testno instanco, ki jo moramo prilagoditi. Obsega: konfiguriranje, testiranje ter analiziranje. Te tri korake v testni instanci ponovimo tolikokrat, kolikokrat je potrebno.
85
Proces poteka v več korakih. V prvem koraku, ki ga imenujemo simulacija, svetovalci prilagodijo osnovni poslovni model, kar pomeni, da so v podjetju izoblikovani standardni postopki. Organizacijska struktura je 100-odstotno pokrita, poslovni procesi pa 60-80 %. Ob koncu konfiguracije osnovnega poslovnega modela je na vrsti prvi integracijski test. Pri njem sodelujejo tudi ključni managerji in uporabniki. V drugem koraku, ki ga imenujemo vrednotenje je potrebno dokončati prilagajanje celotnega poslovnega modela (preostalih 20-40 % funkcionalnosti poslovnih procesov). Dokončna konfiguracija se zgodi ponavadi v več zaporednih ciklih, kjer najprej prilagodimo izjeme in nepokrite zahteve, jih testiramo in nato analiziramo, ali ustrezajo našim zahtevam. Če tem ne ustrezajo, postopek ponovimo. Tako z nekaj interakcijami dobimo ustrezno rešitev. Ko zaključimo z drugim korakom, pride na vrsto testiranje enot in celote. V prvi fazi moramo testirati enote, pri katerih je poudarek na individualnih transakcijah. Za vsako transakcijo je treba napisati skripto ali proceduro poslovnega procesa, ki bo vključena v dokumentacijo o izobraževanju. Ko stestiramo vse enote, jih združimo v celoto. Celoto testiramo s pomočjo poslovnih scenarijev in v testiranje vključimo tudi končne uporabnike. Testiranje mora potekati od začetka do konca procesa, kar opravimo s testom zagotovitve kakovosti (angl. quality assurance). Poleg doslej omenjenih testov mora vsak funkcionalni tim testirati svoje funkcijsko področje. V fazi realizacije je treba pretvoriti podatke iz obstoječega sistema v skupno podatkovno bazo novega sistema. V tej fazi se prenesejo statični podatki, kot so podatki o kupcih, dobaviteljih itd. Pripraviti in testirati moramo tudi vmesnike, programe za pretvorbo in poročila. Izvedemo tudi tretjo raven izobraževanja, tako imenovano napredno izobraževanje, ki obsega dodatno šolanje projektnih skupin in posameznih uporabnikov (npr. administratorja podatkovne baze novega sistema). Tretja raven izobraževanja obsega računalniške delavnice. V fazi izvedbe lahko za lažje delo uporabimo Priročnik uvajanja (angl. implementation guide oz. s kratico priročnik IMG).
5.2.6 Končne priprave
V fazi končnih priprav je treba opraviti vse naloge, da bo prehod na zagon v živo čim lažji. Potrebno je nadaljevati s testiranjem vseh delov, katerih funkcionalnost smo spremenili ali dodali. Poleg tega moramo pripraviti načrt zagona v živo (angl. cutover plan), ki vsebuje glavne aktivnosti in opravila, mejnike, zaporedja nalaganja podatkov, zadolžitev posameznih oseb ter relacije med podatki. Poleg tega je treba pred zagonom v živo izobraziti končne uporabnike, da bodo znali delati z novim sistemom. V velikih in srednjih organizacijah je izobraževanje končnih uporabnikov problem, saj vseh ne moremo izobraževati hkrati. Če pa začnemo z izobraževanjem posameznih skupin prezgodaj, potem le-ti lahko pozabijo, kako ravnati z novim sistemom. Zaradi tega podjetje SAP priporoča metodo izobraževanja, pri kateri so izobraževanja najprej deležni ključni uporabniki v organizaciji (angl. power users oz. key users). Ti v fazi končnih priprav naučijo ostale uporabnike uporabljati rešitev ERP. Izobraževanje zaposlenih na vsakemu delovnemu mestu je pomembno, saj le tako vsak zaposleni točno ve, kako naj uporabi rešitev mySAP ERP pri vsakodnevnih opravilih.
86
V projektih SAP mora biti komunikacija na vseh stopnjah projekta, tudi s končnimi uporabniki. Po navadi končni uporabniki ne vedo dovolj o njihovem obsegu in vplivu. Večina jih vidi rešitev SAP kot nov informacijski sistem, ki se ga bodo hitro naučili. Če se dojemanje tega ne bo spremenilo, bodo imeli končni uporabniki velike težave ob zagonu v živo. Ugotovili bodo namreč, da niso sposobni opravljati dela. Zato moramo končne uporabnike izobraziti o vplivu sprememb, predvsem o tistih, ki spreminjajo poslovne procese, njihove vloge in odgovornosti. Kot smo že omenili, mora potekati komunikacija skozi vse faze, posebno skrb pa je potrebno nameniti tudi obveščenosti končnih uporabnikov. Treba jih je obveščati o naslednjih temah: zakaj bomo uvedli rešitev SAP, kako bo ta programska oprema spremenila organizacijo, vpliv reorganizacije, status projekta. Vzpostaviti moramo zavest o spremembi služb in njihovih vlog, preveriti uporabniška pričakovanja, potlačiti govorice in negativna mnenja, preveriti potrebe in seznam za nova izobraževanja ter zaposlene seznaniti z neizbežnim potekom projekta uvedbe. Ker člani projektnega tima in ključni uporabniki pred in med uvedbo nimajo dovolj znanja s področja rešitve mySAP ERP, so glavni akterji pri uvajanju svetovalci, ki po koncu uvedbe odidejo. Z odhodom svetovalcev je podjetje tudi ob enega izmed pomembnih virov znanja. Zaradi te predpostavke mora organizacija zahtevati od svetovalcev, da pripravijo vmesno (sprotno) in končno dokumentacijo opravil. Poleg tega je pomembno, da svetovalci prenesejo svoje znanje na zaposlene. Če imamo v projektnem timu dovolj članov, potem je smiselno vsakemu svetovalcu določiti enega člana, ki ga med uvajanjem ves čas spremlja in si tako pridobiva potrebno znanje. V končni pripravi mora organizacija izvesti stresni in integracijski test ter na osnovi tega dokončno nastaviti sistem oz. izdelati načrt neobhodnih prilagoditev z vmesniki ter selitev preostalih podatkov. Ko projektni tim pripravi strategijo za zagon v živo, mora pred dnevom zagona dobiti potrditev vodstvenega tima projekta. V tej fazi si lahko projektni tim pomaga z orodjem »GoingLive Check«, ki omogoča, da se Sapovi strokovnjaki preko omrežja prijavijo na našo rešitev SAP in analizirajo konfiguracijo.
5.2.7 Zagon v živo
Pred dnevom, ko preklopimo na uvedeno rešitev ERP, moramo še zadnjič pregledati zadolžitve. Pregled zadolžitev zajema: 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. Potrebno je zagotoviti operativno pomoč ali podporo, ki mora biti na dan zagona v živo dobro organizirana. Tipična podpora zajema probleme in hrošče, ki se pojavijo ob preklopu na novo rešitev. Največje število klicev se zgodi takoj po zagonu v živo in se nanašajo na avtorizacijo. Oddelek operativne pomoči potrebuje za pomoč učinkovito orodje, ki loči tri področja: probleme, prilagoditve in poročila. Kakršno koli naknadno prilagajanje poslovnih procesov urejamo s kontrolo sprememb, ki zagotavlja, da so spremembe v kontroliranem okolju uvedene sistematično. Poleg tega konfiguracija zagotavlja, da spremembe ovrednotimo. Z dokumentiranimi kontrolami sprememb imamo zagotovilo, da je vsak problem hitro izsleden in popravljen. Rešitev mySAP ERP omogoča, da imajo uporabniki dostop do informacij, ki so bile v obstoječem sistemu na voljo samo majhnemu številu zaposlenih. V rešitvi SAP lahko kreiramo uporabniška imena z določenimi pravicami za dostop (t. i. avtorizacijskimi profili). Avtorizacijski profil omogoča oz. dovoljuje uporabniku, da ima dostop samo do tistih akcij
87
(ukazov), za katere je pooblaščen. Nastavitev različnih avtorizacijskih profilov je pomembno opravilo in zahteva skrbno načrtovanje. SAP ponuja za lažje delo v tej fazi orodji Online Service System (OSS) in EarlyWatch. OSS omogoča, da lahko preko oddaljenega dostopa kupci rešitve SAP poizvedujejo v bazi podjetja SAP. Baza vsebuje probleme in rešitve, s katerimi so se srečale druge stranke rešitve mySAP ERP. Vsebuje tudi zadnje novice o verzijah, SAP-novice, informacije o namestitvi in nadgradnjah, izobraževanju itd. Če stranka v bazi OSS ne najde odgovora za svoj problem, ga lahko vpiše v bazo. Medtem ko ga Sapovi strokovnjaki rešujejo, lahko stranka spremlja njihov napredek. Ko je problem rešen, rešitev postane dostopna vsem Sapovim strankam, ki imajo dostop do baze39. Orodje EarlyWatch je storitev, ki omogoča strokovnjakom SAP, da diagnosticirajo sistem in tako zaznajo morebitne probleme še pred zagonom v živo, ko bi postali resnični. Ko v peti fazi opravimo zadnji pregled in dobimo dokončno potrditev zaključka projekta s strani projektnega vodstvenega tima, ga lahko poženemo v živo. Po zagonu v živo je treba načrtovati izboljšave rešitve, ki zajemajo prilagoditve, periodične izdaje in popravke programske rešitve SAP. Eden večjih izzivov, s katerim se danes sooča organizacija po uvedbi rešitve SAP je, kako obdržati projektni tim v organizaciji. Osebe z znanjem uvajanja SAP-rešitev so danes zelo iskan kader. Ni nenavadno, da približno 30 % projektnega tima po končanem uvajanju zamenja službo. Zato potrebuje organizacija dober program, da obdrži te ljudi in s tem prepreči izgubo strokovnjakov ob koncu SAP-projekta. Danes obstaja za to več metod: večja odgovornost, vključitev v druge projekte, višji dohodek itd., s katerimi lahko zadržijo člane projektnega tima.
5.3 Metodologija On Target
5.3.1 Uvod
Podjetje Microsoft je leta 2002 kupilo rešitev Navision od podjetja Navision. Poslovna rešitev Microsoft Business Solutions - Navision je rešitev ERP, ki je namenjena vodenju poslovanja v majhnih in srednjih velikih organizacijah (v svetovnem merilu) in jo po svetu uporablja več kot 55.000 podjetij, v Sloveniji pa več kot 260 podjetij (Pronet, 2005). Sestavljena je iz naslednjih modulov (Kosi, 2004):
• Finančno poslovanje (angl. Financal) z glavno knjigo, osnovnimi sredstvi, obveznostmi, terjatvami in kadrovsko evidenco.
• Proizvodnja in distribucija (angl. Supply Chain Management), ki je sestavljena iz dveh delov: (1) proizvodnje s projekti, osnovami proizvodnje, načrtovanjem materialnih potreb in načrtovanje kapacitet in (2) distribucije z zamenjavo artiklov, navskrižnim sklicevanjem, medskladiščnimi izdelki, več lokacij, skladiščnim poslovanjem, materialnim poslovanjem in skladiščnimi sistemi (logistiko).
• Upravljanje odnosov (angl. Customer Relationship Management) je prav tako sestavljeno iz dveh delov, in sicer: (1) prodaje s stiki, srečanji, zadolžitvami, dnevnikom interakcij in dokumentov ter integracijo z MS Outlookom in (2) servisa s servisnimi artikli, kosovnicami, servisnimi nalogi, servisnimi pogodbami, servisnimi conami, serviserji in njihovim znanjem ter načrtovanje in razporejanje opravil in virov.
39 Do baze OSS lahko dostopamo tudi preko omrežja internet, kjer je to orodje imenovano SAPNet.
88
• E-poslovanje (angl. e-business) sestavljajo Commerce Gateway, Commerce Portal in User Portal.
• Vertikalne rešitve (angl. AddOn) s splošnimi ali specializiranimi rešitvami partnerjev. Osnovni modul brez katerega ne moremo uvesti rešitve Navision, je modul finančno poslovanje. Prepletenost vseh modulov pa vidimo na sliki 31 (Kosi, 2004). SLIKA 31: Prepletenost modulov v rešitvi Navision
Microsoft Business Solution - Navision (v nadaljevanju MS Navision) uvajajo partnerska podjetja Microsofta. Zato je podjetje Microsoft pripravilo celovito metodologijo poslovanja (angl. Business Methodology) in metodologijo uvajanja (angl. Implementation Methodology) rešitve Navision, ki se imenuje Microsoft Business Solutions Partner Methodology (v nadaljevanju MBS metodologija). MBS metodologija je sestavljena iz treh ključnih področij (Microsoft, 2004d):
1. strateškega planiranja (angl. Strategic planning), 2. letnega planiranja (angl. Yearly planning) in 3. izvedbe (angl. Execution), ki jo sestavljajo:
a. marketinška metodologija (angl. Marketing methodology), b. prodajna metodologija (angl. Sales methodology) in c. implementacijska metodologija (angl. Implementation methodology).
Izvedba MSB metodologije temelji na modelu tehnološkega investicijskega cikla (angl. Technology Investment Cycle), ki ga je na osnovi raziskave razvilo podjetja Deloitte & Touche (ibid.). Tehnološki investicijski cikel je razdeljen na štiri faze (slika 32), ki jih bomo na kratko opisali v nadaljevanju. Prva faza »Nezadovoljstvo« (angl. Dissatisfaction) traja ponavadi šest mesecev in se začne, ko organizacija ugotovi, da ni zadovoljna z obstoječimi informacijskimi sistemi. Konča pa se s kreiranjem nove vizije. V tej fazi Microsoft predlaga svojim partnerjem marketinško metodologijo, s pomočjo katere naredijo partnerska podjetja vtis na ciljni segment in s pomočjo katere iščejo primerne stranke. Partnerji morajo v marketinški stroj (angl Marketing machine) vključevati različne tipe direktnega marketinga, kot npr. direktno klasično pošto, fakse, e-pošto, tele-marketing, dogodke, srečanja itd. SLIKA 32: Tehnološki investicijski cikel
89
Vir: Microsoft (2004d) V drugi fazi »Raziskava« (angl. Research) organizacija pripravi zahtevek za ponudbo, analizira obstoječe stanje in pripravi vizijo, kar traja od enega do treh mesecev. V tej fazi Microsoft predlaga svojim partnerjem uporabo prodajne metodologije, s pomočjo katere navežejo stranke - organizacije nase. Prodajna metodologija je sestavljena iz petih korakov, ti so (Kosi, 2004; slika 33):
• Kvalifikacija (angl. Qualification), • Pozicioniranje (angl. Positioning), • Diagnostika (angl. Diagnostic), • Ponudba (angl. Proposal) in • Obveza (angl. Commitment).
Marketinški stroj v prvi fazi tehnološkega investicijskega cikla išče na trgu organizacije, ki so nezadovoljne z obstoječimi informacijskimi sistemi in jih grobo oceni. V primeru, da je ocena marketinškega stroja pozitivna, se začne prva faza prodajne metodologije. V fazi »Kvalifikacije« partner oceni primernost potencialne organizacije s pomočjo vnaprej pripravljenih parametrov. Če se izkaže, da je potencialna organizacija neprimerna, potem partner vrne organizacijo v marketinški stroj. V nasprotnem primeru se prestavimo na fazo »Pozicioniranje«, kjer se partner ponudi v vlogi poslovnega svetovalca organizaciji ter doseže dogovor in ceno izvedbe faze »Diagnostika«. V fazi »Diagnostika« mora partner razumeti in določiti riziko in stopnjo kompleksnosti projekta ter določiti osnovne module, ki jih je potrebno uvesti v prvi fazi projekta. Tako mora partner ovrednotiti, kako se rešitev Navision prilega poslovnim procesom organizacije, obseg in zapletenost rešitve ter na osnovi zbranih informacij določi t. i. »ubijalske aplikacije«. To so aplikacije, zaradi katerih se organizacije ponavadi odločijo za menjavo obstoječega sistema. Partner posreduje organizaciji poročilo diagnostike. Po odobreni diagnostiki s strani organizacije preidemo v fazo »Ponudbe«. V fazi »Ponudbe« partner izdela in predstavi ponudbo izvedljivosti projekta, časovni okvir in ocenjene stroške organizaciji. Če se organizacija strinja s ponudbo, potem preidemo v zadnjo fazo prodajne metodologije, ki se imenuje »Obveza«. V tej fazi se določijo cilji projekta in izvedljivost projekta. Zaključi se s podpisom pogodbe o nakupu rešitve Navision.
ZADOVOLJSTVO NEZADOVOLJSTVO
UČENJE RAZISKAVA
V povprečju organizacije menjajo sistem vsakih 7 let
Novo učenje
Kompetence
Oddih
Odločitev
Spoznati neskladnosti
Ponovno učenje
Kreiranje nove vizije
Nezadovoljstvo
Omejenost funkcionalnosti
Analiziranje
Določitev možnosti
Tension
90
SLIKA 33: Prodajna metodologija
Vir: Kosi (2004) V fazi »Učenja« (angl. Learning) se organizacija odloči za nakup rešitve ERP in uvedbo rešitve ERP. V tej fazi Microsoft predlaga svojim partnerjem uporabo implementacijske metodologije, ki jih bomo razložili v nadaljevanju poglavja. V zadnji fazi tehnološkega investicijskega cikla v t. i. fazi »Zadovoljstva« organizacija uporablja uvedeno rešitev ERP, partner pa nudi podporo in vzdrževanje rešitve Navision organizaciji in pripravlja načrte za nove projekte s prodajnim oddelkom.
5.3.2 Implementacijska metodologija – On Target
Pred nakupom rešitve Navision s strani podjetja Microsoft se je implementacijska metodologija imenovala »On Target«, kar še danes pogosto zasledimo v pogovoru namesto metodologija uvedbe (v nadaljevanju bomo uporabljali izraz On Target). Metodologija On Target je sestavljena iz petih korakov: (Microsoft, 2004a; slika 34):
1. Analiza (angl. Analysis), 2. Oblikovanje (angl. Desing), 3. Razvoj in testiranje (angl. Development & Testing), 4. Namestitev (angl. Deployment) in 5. Aktivnosti po zagonu (angl. On-going Operations).
OBVEZA 90 - 100%
PONUDBA 80 - 90%
DIAGNOSTIKA 30 - 80%
POZICIONIRANJE 20 - 30%
novi projekt
P R O D A J N A S T R A T E G I J Ak
implementaciji
KVALIFIKACIJA 0 - 20%
da
Marketinški
stroj ne
91
SLIKA 34: Koraki metodologije On Target
5.3.3 Analiza
Faza »Analiza« vsebuje aktivnosti, ki so potrebne za podrobno določitev poslovnih procesov nove rešitve in potrebne prilagoditve, vmesnike ter prenos podatkov. V fazi »Analiza« poskuša partner razumeti zahteve organizacije, se izogniti špekulacijam o prileganju rešitve Navision, pripraviti organizacijo na zahteve o izobraževanju in sistemskih nastavitvah, izboljšati poslovne procese in izdelati dokument funkcionalnih zahtev (angl. Functional Requirements Document), ki bo osnova za nadaljnje faze uvajanja rešitve Navision. Najpomembnejši del te faze je izboljšanje poslovnih procesov. V tej fazi morajo analitiki preveriti vsa področje poslovanja organizacije in ne samo tistih, ki veljajo za ključna poslovna področja ali t. i. »ubijalske aplikacije«, kot v prodajni metodologiji v fazi »Diagnostika«. Na osnovi analiziranih poslovnih procesov analitiki določijo riziko ter prednosti, ki so povezane z uvedbo rešitve Navision v okolje organizacije. Poleg tega morajo analitiki izdelati dva dokumenta: (1) organizacijski oblikovni dokument (angl. Enterprise Design Document) in (2) programski oblikovni dokument (angl. Software Design Document) ter zagotoviti dovolj podatkov, da lahko projektni in prodajni tim pripravita projektni plan in okvirni terminski plan. Dokument funkcijskih zahtev je izboljšana verzija diagnostičnega poročila ali dokumenta praznin/prileganja, ki je bil izdelan v fazi »Diagnostike«. Večina korakov te faze so poglobljene aktivnosti faze »Diagnostike«, kjer si pomagamo z orodji za modeliranje (Navision Modeler tool ali MS Visio), kar prikazuje tudi slika 35. Dokument funkcionalnih zahtev je temeljni dokument za nadaljnje analize ter aktivnosti faze »Oblikovanje«. S pomočjo predloge tega dokumenta lahko partner dokaj hitro izdela dokument funkcijskih zahtev, ki opisuje želje organizacije in vključuje:
• povzetek o organizaciji, ki obsega opis organizacijske strukture, obstoječe tehnične arhitekture, ciljev projekta itd.
• vizija, • obseg uvajanja, • opis trenutnih poslovnih procesov, • opis novih izboljšanih poslovnih procesov ter
Prodaja Novi projekt
Koordinacija in vodenje sprememb
Planiranje in vodenje projekta
Šolanje in podpora uporabnikom
RAZVOJ INTESTIRANJE
OBLIKOVANJE ANALIZA NAMESTITEV AKTIVNOSTI PO ZAGONU
92
• opis informacij in podatkov, ki jih mora zagotavljati uvedena rešitev Navision. SLIKA 35: Povezava med metodologijama
Vir: Microsoft (2004b) Če nismo v fazi »Diagnostike« naredili podrobnejše analize procesov, potem moramo to storiti v fazi »Analize«. Prav tako moramo dopolniti že narejeno analizo praznin/prileganja (angl. Gap/Fif Analysis) in določiti stopnjo potrebnega prilagajanja rešitve Navision, tako da bo zadoščeno strankini viziji in obsegu projekta. Izboljšanje poslovnega procesa se nanaša na izboljšave oziroma vpeljavo novih poslovnih procesov v organizaciji, tako da bo poslovanje učinkovitejše, rentabilno in za končne uporabnike prijaznejše. Nato sledi priprava in predstavitev faze »Analiza«. Podobno kot v fazi »Diagnostike« so ob koncu faze »Analiza« v dokumentu funkcijskih zahtev določeni in dokumentirani trenutni poslovni procesi, opis bodočih poslovnih procesov in opisi vseh prilagoditev, ki so potrebne v novem sistemu.
5.3.4 Oblikovanje
V fazi »Oblikovanje« morajo analitiki točno določiti, kako bo delovalo posamezno poročilo, obrazec, polje in funkcija. Za dele funkcionalnosti sistema Navision, ki jih želimo prilagoditi, moramo določiti specifikacije. Specifikacije določijo analitiki skupaj s ključnimi uporabniki in sponzorjem projekta. Aktivnosti v tej projektni fazi vodjo v točnejšo oceno stroškov sistemskih prilagoditev, kot 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 opredeljeni 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 MS Navision, kot so določeni v dokumentu praznin/prileganja ter
• podroben opis podatkov, ki jih je potrebno prenesti v rešitev MS Navision, kot je določeno v dokumentu praznin/prileganja.
Rezultat faze »Oblikovanje« je odgovor na vprašanje, »kako« bo nova rešitev zagotavljala zahtevano funkcionalnost. Rezultat je zapisan v dveh dokumentih:
1. Organizacijski oblikovni dokument (angl. Enterprise Design Document) je namenjen končnim uporabnikom. Končni uporabniki lahko s pomočjo tega dokumenta preverijo
PPrrooddaajjnnaa mmeettooddoollooggiijjaa
5. faza 4. faza 3. faza 2. faza 1. faza
IImmpplleemmeennttaacciijjsskkaa mmeettooddoollooggiijjaa
3. faza 2. faza 1. faza 4. faza 5. faza
MMBBSS oorrooddjjee zzaa mmooddeelliirraannjjee
93
delovanje novega sistema (bodoče poslovne procese) in na osnovi tega odobrijo delovanje le-tega. Ta dokument je tudi osnova za izobraževanje končnih uporabnikov in je pisan na tak način, da se izogne tehničnim podrobnostim. Vsebuje: povzetek, reference, arhitekturo rešitve Navision, podrobnejši diagram aplikacij v rešitvi Navision, definicije procesov, nove procedure, prenos podatkov in dokument praznin/prileganja.
2. Programski oblikovni dokument (angl. Software Design Document) je namenjen razvojnemu timu in je pisan na tak način, da zagotavlja dovolj tehničnih podrobnosti za kodiranje, testiranje in namestitev modulov in/ali zrn (procedur) v rešitvi MS Navision. Na osnovi programskega oblikovnega dokumenta bo razvojni tim pripravil plan razvoja zahtevanih prilagoditev novega sistema. Programski oblikovni dokument opisuje vsa polja, funkcije in obrazce za vsak del novega sistema. S pomočjo tega dokumenta bo programer napisal manjkajočo funkcionalnost (programiral), projektni manager bo določil mejnike, pripravile se bodo testne procedure, napisana bo uporabniška dokumentacija itd.
Oba dokumenta se bosta uporabila za pripravo izobraževalnega gradiva, pomoč, tehnično dokumentacijo, uporabniške priročnike itd.
5.3.5 Razvoj in testiranje
V fazi »Razvoj in testiranje« mora razvojni manager razdeliti delo med razvijalce (programerje) in ga opredeliti v razvojnem planu (angl. Build Plan) ter pripraviti razvojno okolje. Po prilagoditvi rešitve MS Navision oziroma kodiranju zrn, mora partner najprej testirati aplikacijo, preden jo namesti pri stranki. Pripraviti moramo tudi testno in produkcijsko okolje ter zbrati podatke. V razvojnem planu je struktura izvedbe prilagoditev (modulov in zrn) z mejniki, ki jih mora potrditi organizacija. Razvojni plan vsebuje:
• strategijo, v kateri je: projektni plan, začetni sestanek, nastavitev uporabniškega okolja, izobraževanje ključnih uporabnikov in razvijalcev,
• plan, ki vsebuje: podatkovno strukturo, bistveno funkcionalnost, potrebne vmesnike, opis drugih procesov ter razna poročila/dokumente ter
• razvoj testne strategije. Pri pripravi razvojnega plana moramo biti pozorni, da najprej razvijemo ključne poslovne procese pred obrobnimi, dnevne procese pred periodičnimi, dnevno poročanje pred periodičnim, razdelimo izdelavo modulov na dele (zrna), ter da načrtujemo izjeme. Po razvoju modulov oziroma zrn metodologije On Target določa štiri vrste testov (slika 36; Microsoft, 2004c):
• Test enote (angl. Unit test) je neformalni test, ki ga opravi vsak razvijalec med razvijanjem kode, ko testira logične napake v kodi in hrošče (angl. bugs) ter po razvoju zrna.
• Razvojni testi (angl. Build test) izvedejo razvojni manager in ključni uporabniki, ki testirajo odobreno verzijo programa. Odobrena verzija programa je ponavadi sestavljena iz več komponent (zrn), ki jih je razvilo več razvijalcev.
• Sistemski test (angl. Final system test) predpiše poslovni analitik, izvedejo pa ga ključni uporabniki in uvajalci, ki testirajo na novem sistemu uporabniške primere, ključno funkcionalnost sistema, zmogljivost in prileganje celotnega sistema, uporabniške vmesnike, združljivosti z ostalimi sistemi, varnost, dokumentacijo, proces obnovitve v primeru nesreče (angl. recovery) itd.
94
• Končni test (angl. Acceptance walk-through) je izveden v fazi »Namestitve« in je bolj sprehod skozi sistem kot pa test sistema. V njem se preveri, ali nov sistem vsebuje vse, da se lahko izvede zagon v živo.
SLIKA 36: Povezava med posameznimi testi
Vir: Microsoft (2004c)
Pri testiranju si pomagamo z dvema dokumentoma:
1. sistemski testni plan (angl. System test plan) in 2. testni primeri (angl. Test cases).
Sistemski testni plan je živ dokument, ki vključuje: primere, ki jih je potrebno testirati, integracijski test, test uporabnosti, test zmogljivosti, izbrano funkcionalnost, procese in poročila. Vključuje pa tudi ključna področja, na katera morajo biti razvijalci pri testu pozorni in vpliv na poslovanje, orodja, tehnike in potrebne vire, testno okolje in uporabo testnih primerov. SLIKA 37: Koraki testiranja
Vir: Microsoft (2004c) Testni primeri so primeri testov, s pomočjo katerih preverjamo več delov hkrati, kot npr. pri testiranju tipov podatkov, kjer preverjamo uporabniške primere, funkcionalnost in zmogljivost sistema. V njih je zapisano tudi, v katerem izmed zgoraj naštetih testov naj uporabimo kateri testni primer, na katero področje aplikacije se nanaša, katere cilje preverjamo z njim, pričakovane rezultate, možne variacije pričakovanega rezultata. Z njimi pa
Analiza Konceptualno oblikovanje
1. verzija: Razvoj, testiranje in odobritev
n. verzija: Razvoj, testiranje in odobritev
Namestitev
Podrobnejše oblikovanje
KONČNI TEST
SISTEMSKI TEST
TESTI ENOT
RAZVOJNI TEST (partner)
RAZVOJNI TEST (organizacija)
95
preverjamo tudi spremenljivke, podatke in zaporedne korake izvajanja novega sistema. Kot vidimo na sliki 37, lahko testiramo isti modul, proceduro ali zrno večkrat, tolikokrat, da so rezultati testiranja enaki rezultatom zapisanim v testnih primerih.
5.3.6 Namestitev
Faza »Namestitev« označuje konec procesa uvedbe sistema Navision. Poslovne procese organizacije in rešitev MS Navision smo skozi faze metodologije On Target analizirali, oblikovali, razvili manjkajočo funkcionalnost in testirali. Obseg projekta uvedbe rešitve Navision se je lahko od začetka uvedbe delno spremenil, napake so bile odkrite in odpravljene ter vse težave rešene. Ob fazah uvajanja rešitve Navision pa je bila pripravljeni tudi različna dokumentacija. V fazi »Namestitev« je potrebno izvesti končni test, potrditi končni test, namestiti produkcijski sistem in zagnati rešitev MS Navision v živo. S pomočjo kontrolnega seznama se izvede končni test, kjer preverimo in potrdimo spremembe v prvotni funkcionalnosti rešitve MS Navision in vmesnike, ki jih potrebujemo za prenos podatkov iz drugih IS, izdelamo varnostne kopije obstoječega sistema, zaključimo računovodsko obdobje, prenesemo produkcijske podatke v novo rešitev, preverimo stanje odprtih transakcij in namestimo v prejšnjih fazah sprejeto podatkovno strukturo. V končnem testu tudi preverimo rokovanje končnih uporabnikov z rešitvijo MS Navision na produkcijskih podatkih ter dosežemo potrditev, da nov sistem zagotavlja na začetku projekta zastavljene poslovne cilje in zahteve. Namestitev produkcijskega sistem zahteva namestitev produkcijskih podatkov, preverjanje končnega in začetnega stanja (skladnost stanja v starem in v novem sistemu) in pripravo na odobritev zagona v živo. V tej fazi je potrebno tudi naučiti končne uporabnike dela z novim sistemom. Izobraževanje končnih uporabnikov lahko tako obsega:
• znanje o računalnikih in operacijskem sistemu MS Windows, • izobraževanje v razredu, • izobraževanje posameznikov, • učenje korakov poslovnih procesov, ki je enako pomembno kot učenje uporabe sistema
ter • izobraževanje drugih orodij, ki jih bodo končni uporabniki potrebovali pri svojem delu.
Pred zagonom rešitve MS Navision v živo, morajo biti rešene tudi vse težave z strani varnosti sistema in zaključena celotna dokumentacija. Partner pripravi sestanek za upravo, na kateri izvedejo končni test in preverijo, ali so vsi cilji projekta uvajanja rešitve Navision izpolnjeni. Če je uprava zadovoljna z rezultati, potem potrdi projekt in rešitev MS Navision je pripravljena na zagon. Obstajajo pa tudi primeri, ko zaženemo rešitev Navision, kljub temu da vsi cilji projekta uvajanja niso v celoti končani. To se zgodi takrat, kadar zunanje okoliščine vplivajo na projekt uvedbe, kot npr. novo finančno leto, ki se mora začeti na začetku koledarskega leta.
5.3.7 Aktivnosti po zagonu v živo
Zadnja faza metodologije On Target vsebuje končne aktivnost, preden se prestavimo v marketinško in prodajno metodologijo. Aktivnosti se nanašajo na vzdrževanje in podporo novemu sistemu ter nadziranje bodočih potreb v organizaciji ob rasti in razvoju poslovanja. Tako mora partner podjetja Microsoft nuditi pomoč in dodatno izobraževanje uporabnikom, rešiti zahteve po spremembah in priskočiti na pomoč v primeru nesreč, nadzirati zmogljivosti
96
sistema, vrednotiti uporabo sistema, vrednotiti uporabniško zadovoljstvo, vrednotiti poslovne rezultate v primerjavi s cilji itd. Zgoraj omenjene aktivnosti so vključene v podpis vzdrževalne pogodbe za tehnično vzdrževanje sistema, nadgradnje, podporo in izobraževanje, nadziranje napak itd. Poleg tega je dobro, da nekaj mesecev po zagonu rešitve MS Navision v živo, partner pripravi sestanek z organizacijo, v kateri je uvedel rešitev Navision, kjer skupaj preverijo delovanje sistema ter se lahko začnejo pogovarjati o začetku novega projekta z določitvijo vizije in obsega novega projekta uvajanja.
5.4 Primerjalna analiza metodologij ASAP in On Target
Rešitvi mySAP ERP podjetja SAP kot tudi Microsoft Business Solutions – Navision ponujata pri uvedbi svoji metodologiji. Rešitev mySAP ERP se najpogosteje uvaja v velikih in srednjevelikih organizacijah, medtem ko se rešitev Navision uvaja v srednjevelike in male organizacije (do 500 uporabnikov) v svetovnem merilu. V tabeli 11 so predstavljene glavne značilnosti obeh rešitev. TABELA 11: Primerjava osnovnih značilnosti rešitev mySAP ERP in MBS Navision
mySAP ERP Microsoft Business Solutions - Navision
Velikost organizacije* Velike Srednjevelike
Srednjevelike (do 500 uporabnikov) male
Celovitost rešitve Vključuje vsa poslovna področja v standardni rešitvi
Vključuje vsa poslovna področja v standardni rešitvi
Modularnost rešitve Da Da Moduli Proizvodnja in distribucija (SD)
Materialno poslovanje (MM) Planiranje proizvodnje (PP) Obvladovanje kakovosti (QM) Vzdrževanje (PM) Kadrovski sistemi (HR) Finančno knjigovodstvo (FA) Kontroling (CO) Upravljanje osnovnih sredstev (AM) Projektni sistem (PS) Potek dela (WF) Industrijske rešitve (IS) Supply Chain Management (SCM) Customer Relationship Management (CRM) Business intelegence (BI)
Finančno poslovanje Proizvodnja in distribucija (SCM) Upravljanje s kupci (SCM) E-poslovanje Vertikalne rešitve Skladiščno poslovanje
Ali mora biti kateri izmed modulov nujno uveden
Ne Da Finančno poslovanje
Odprtost rešitve Večina OS MS Windows Skalabilnost Odjemalec/strežnik Odjemalec/strežnik 3 nivojska arhitektura - predstavitveni nivo - aplikacijski nivo - nivo podatkovne baze
Da Windows XX, OS/2, JAVA, OSF/Motif UNIX, Windows XX, Mainframe, IBM OS/400 DB2, Informix-Online, Oracle, My SQL Server
Da Windows XX Windows Server My SQL Server
Programski jezik ABAP C/AL (Client Application Language)
Prenos podatkov med IS XML XML Knjige s področja rešitve Veliko Malo
97
Tako splošne, kot za posamezne module Samo za posamezne module Prodajna metodologija SAP Customer Engagement Lifecycle (4
faze) Microsoft Business Solutions Partner Methodology
Metodologija uvajanja ASAP (pospešena metodologija) SAPov postopkovni model (standardna metodologija)
On Target (pospešena metodologija)
Rešitev uvaja SAP in partnerji SAPa Partnerji Microsofta Orodje za prenovo poslovnih procesov
ARIS Navision Modeler tool ali MS Visio
Dodatna pomoč Svetovanje in izobraževanje Orodje Early Watch On-line podporni sistem
Svetovanje in izobraževanje
* V svetovnem merilu Rešitev mySAP ERP ponavadi uvajamo po metodologiji ASAP podjetja SAP AG, medtem ko rešitev MS Navision uvajamo po metodologiji MBS Implementation Methodology oziroma pogovorno metodologiji On Target. Obe metodologiji vsebujeta zemljevid uvedbe, ki vsebuje opis namena, akcije, rezultate, orodja in naloge udeležencev. V tabeli 12 so predstavljene glavne značilnosti obeh metodologij, ki sta bili opisani v tem poglavju. TABELA 12: Primerjava pomembnejših značilnosti metodologij uvajanja ASAP in On Target
Metodologija ASAP Metodologija On Target Pristop uvajanja Fazno
Big bang Postopno
Število faz uvajanja 5 5 1. faza Priprava projekta
Izbira projektne skupine Začetno izobraževanje projektne skupine Orodje: ASAP Project Estimator
Analiza Podrobna določitev poslovnih procesov Priprava projektnega in terminskega plana Orodje: Navision Modeler tool ali MS Visio
2. faza Poslovni načrt Podroben projektni plan z določenimi cilji in obsegom dela Druga raven izobraževanja projektne skupine Orodje Implementation Assistant
Oblikovanje Podroben opis delovanja posameznih funkcij, poročil in procesov
3. faza Izvedba Prilagajanje in testiranje rešitve Prenos statičnih podatkov v novo rešitev Napredno izobraževanje projektne skupine Orodje: Priročnik uvajanja
Razvoj in testiranje Programiranje manjkajoče funkcionalnosti in testiranje teh zrn. Dokument: sistemski testni plan in testni primeri
4. faza Končne priprave Testiranje Priprava načrta za zagon v živo Izobraževanje končnih uporabnikov Stresni in interakcijski test Orodje: GoingLive Check
Namestitev Izvedba in potrditev končnega testa Namestitev produkcijskega sistema Zagon v živo Izobraževanje končnih uporabnikov
5. faza Zagon v živo Pregled zadolžitev in zagotovitev podpore ob zagonu Nastavitev avtorizacijskih profilov Zadnji pregled in zagon v živo Načrtovanje izboljšav rešitve Orodja: On-line Sevice System in EarlyWatch
Aktivnosti po zagonu Vzdrževanje in podpora uvedeni rešitvi Načrtovanje izboljšav rešitve
Potrebna vključitev svetovalcev
Da Da
Čas trajanja uvedbe 6 do 18 mesecev Do 6 mesecev
98
6 KRITIČNI DEJAVNIKI USPEHA PRI UVAJANJU CELOVITIH INFORMACIJSKIH REŠITEV
6.1 Analiza kritičnih dejavnikov uspeha uvajanja celovitih informacijskih rešitev
Uvedba rešitve ERP v organizacijo so veliki in zahtevni projekt, v katerem sodeluje veliko ljudi in drugih virov, ki delajo skupaj pod časovnim pritiskom in se soočajo z nepredvidljivimi situacijami. Zato ni čudno, da je veliko uvedb rešitev ERP manj uspešnih od načrtovanih (Davenport, 1998 povzeto po Akkermans, 2002). Izredno pomembno je, da smo med uvajanjem rešitve ERP pozorni na kritične dejavnike uspeha uvajanja rešitve ERP40. KDU so dejavniki, ki usodno vplivajo na projekt uvedbe rešitve ERP. V zadnjih nekaj letih je bilo objavljenih več člankov na temo KDU uvajanja rešitev ERP, ki smo jih poiskali v računalniških bazah in knjigah. Našli smo devetnajst člankov, ki se nanašajo na KDU uvajanja rešitev ERP. V primeru, da je en avtor objavil več člankov na enako temo, smo izbrali najnovejši članek. V tabeli 13 je zajetih štirinajst KDU, ki so bili omenjen več kot petkrat. Število v oklepaju predstavlja število avtorjev, ki so omenili KDU. Ti dejavniki so po pomembnosti sledeči (1 – najpomembnejši, 15 – najmanj pomemben):
1. vključitev in podpora »top managementa« (16), 2. jasni cilji, strategija in obseg uvajanja rešitve (14), 3. organizacija projektnega tima in njegove kompetence (13), 4. izobraževanje uporabnikov rešitve ERP (13), 5. prenova poslovnih procesov (11), 6. management sprememb (10), 7. komunikacija znotraj projektnega tima in med projektnim timom ter ostalimi v
organizaciji (9), 8. vključitev in sodelovanje uporabnikov pri uvedbi ERP (9), 9. prenos podatkov iz starih rešitev ERP (9), 10. vključevanje zunanjih svetovalcev (8), 11. uporaba principov projektnega managementa (8), 12. aktivna vloga sponzorja projekta (7), 13. izbira tehnološke arhitekture (7) in 14. minimalno prilagajanje rešitve ERP posebnostim organizacije (7).
Poleg teh KDU avtorji omenjajo tudi dejavnike, ki pa so bili omenjeni manj kot petkrat. Ti dejavniki so: 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, izbira rešitve ERP, organizacijska kultura, partnerski odnos s ponudnikom rešitve ERP in dodatna orodja za uvajanje, sistemska integracija in testiranje, prenos znanja na uporabnike … V nadaljevanju poglavja bomo opisali KDU, ki so bili omenjeni več kot petkrat.
40 V nadaljevanju poglavja bomo namesto kritični dejavniki uspeha uporabljali kratico KDU (angl. critical success factors oz. s kratico CSF).
99
TABELA 13: V zadnjih petih letih objavljeni članki na temo KDU uvajanja rešitev ERP
KDU 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Vključitev in podpora uprave X X X X X X X X X X X X X X X X
Jasni cilji, strategija in obseg uvajanja rešitve ERP X X X X X X X X X X X X X X
Organizacija projektnega tima in njegove kompetence X X X X X X X X X X X X X
Izobraževanje uporabnikov rešitve ERP X X X X X X X X X X X X X
Prenova poslovnih procesov X X X X X X X X X X X
Management sprememb X X X X X X X X X X
Komunikacija znotraj projektnega tima in med projektnim timom ter ostalimi v organizaciji
X X X X X X X X X
Vključitev in sodelovanje uporabnikov pri uvedbi ERP X X X X X X X X X
Prenos podatkov iz starih rešitev ERP X X X X X X X X X
Vključevanje zunanjih svetovalcev X X X X X X X X
Uporaba principov projektnega managementa X X X X X X X X
Aktivna vloga sponzorja projekta X X X X X X X
Izbira tehnološke arhitekture X X X X X X X
Minimalno prilagajanje rešitve ERP posebnostim organizacije X X X X X X X
[1] Aduri, Lin in Ma (2002) [2] Akkermans in Helden (2002) [3] Al-Mashari, Al-Mudimigh in Zairi
(2003) [4] Al-Sehali (2000) [5] Bancroft, Seip in Sprengel (2001) [6] Bradford in Florin (2003)
[7] Estaves, Pastor in Casanovas (2002) [8] Gattiker in CFPIM (2002) [9] Holland in Light (1999) [10] Jarrar, Al-Mudimigh in Zairi (2000) [11] Khan (2002) [12] Mabert et al (2003) [13] Parr in Shanks (2000)
[14] Reif (2001) [15] Skok in Legge (2002) [16] Somers in Nelson (2004) [17] Umble, Haft in Umble (2002) [18] Welti (1999) [19] Zhang et al (2002)
100
6.1.1 Vključitev in podpora uprave
Največkrat omenjen KDU s strani avtorjev je vključitev in podpora uprave, ki je bila omenjena 16-krat. Kot navajajo avtorji (Somers in Nelson, 2004; Nah, Lau in Kuang, 2001; Umble et al., 2002; Aduri, Lin in Ma, 2002; Gattiker in CFPIM, 2002) v svojih prispevkih je kot najpomembnejši KDU omenjena močna podpora uprave. Al-Mashari et al (2003) ter Parr in Shanks (2000) pravijo, da so naloge uprave v projektu uvedbe rešitve ERP sledeče:
• sprejemati hitre in učinkovite odločitve , • reševati konfliktne situacije, ki se pojavijo v projektu uvajanja, ter • obveščati zaposlene, katere so prednosti uvedbe rešitve ERP za njih, tako da bodo
zaposleni sprejeli projekt uvajanja rešitve ERP za svoj projekt. Uprava mora tudi ves čas nadzirati napredek projekta in korigirati smer uvajanja rešitve ERP ter določiti jasne prioritete projekta (Mabert, Soni and Venkataramanan 2003). Vključitev in podpora uprave je najpomembnejši KDU zato, ker danes še vedno veliko uprav organizacij vidi uvedbo rešitve ERP kot tehnološki izziv, kar pomeni, da prepusti uvedbo rešitve ERP oddelku IT (Jarrar, Al-Mudimigh in Zairi, 2000). Bradford in Florin (2003), Al-Sehali (2000), Estaves, Pastor in Casanovas (2000), in Welti (1999) dodajajo, da je stopnja podpore uprave pri uvedbi rešitve ERP v pozitivni povezavi s stopnjo uspeha uvedbe rešitve ERP. Po drugi strani pa prevelika vključitev uprave v proces uvedbe rešitve ERP tudi ni priporočljiva (Akkermans in Helden, 2002). Zato Skok in Legge (2002) predlagata, da uprava izbere enega člana izmed članov uprave (managerja poslovne funkcije, kjer se uvaja rešitev ERP), da bo t. i. sponzor projekta. Sponzor projekta ima pooblastila, da lahko sprejema odločitve v zvezi z uvedbo rešitve ERP. Poleg tega zaposleni vidijo, da je projekt uvedbe rešitve ERP pretežno poslovni projekt in ne samo tehnološki projekt. Avtorji postavljajo vključitev in podporo uprave v različne kategorije. Tako Holland in Light (1999) pravita, da je vključitev in podpora uprave strateški KDU, Zhang et al (2002) ga uvrščajo med organizacijske KDU, medtem ko ga Estaves s sodelavci (2000) uvršča v obe zgoraj omenjeni skupini.
6.1.2 Jasni cilji, strategija in obseg uvajanja rešitve
Aduri et al (2002) je opredelil poslovne in strateške cilje kot najpomembnejši KDU. Al-Mashari et al (2003), Khan (2002), Umble et al (2002) ter Parr in Shanks (2000) dodajajo, da jasno opredeljena vizija in prava politika/strategije lahko služijo kot zemljevid za uspeh uvedbe rešitve ERP v organizacijo. Cilji morajo biti jasni, kar pomeni, da morajo biti kar se da nadrobni in operativni ter morajo kazati smer projekta uvajanja (Somers in Nelson, 2004). Akkermans in Helden (2002) opisujeta, da je določitev jasnega cilja zahtevna naloga, saj je na začetku projekta uvajanja rešitve ERP zelo težko točno določiti jasne cilje projekta. Prav tako je potrebno pred uvajanjem rešitve ERP doseči soglasje med udeleženimi managerji glede obsega ciljev ter kako
101
bodo te cilje nadzirali in merili (Bradford in Florin, 2003). Dobro opredeljeni cilji pomagajo usmerjati projekt uvajanja rešitve ERP ter so zelo pomembni za analiziranje in merjene uspeha projekta uvajanja. Cilji morajo biti točno določni, merljivi in kontrolirani ter za vsak cilj mora biti določen kolikšen bo prihranek (Welti, 1999). Obseg projekta je povezan s cilji projekta in skladnostjo z organizacijsko vizijo in strateškimi cilji (Estaves et al, 2000). Reif (2001) omenja, da je obseg projekta določen z ustreznim obsegom rezultatov in deležev organizacije, ki bo imela uvedeno rešitev ERP. Za tem je potrebno obširno planiranje in razumevanje konceptov rešitve ERP, kar bo vodilo v prihranek časa pri uvedbi rešitve ERP (Al-Sehali, 2000). O planu uvedbe in napredkih morajo biti redno obveščeni zaposleni, dobavitelji in kupci (Mabert, 2003).
6.1.3 Organizacija projektnega tima in njegove kompetence
Avtorji, ki omenjajo projektni tim za uvajanje rešitev ERP kot KDU, govorijo o kompetencah, znanju in organizaciji projektnega tima. V naši raziskavi smo vključili vse tri vidike v en KDU. Somers in Nelson (2004) pravita, da so odločilen element pri uspehu oziroma neuspehu uvedbe rešitve ERP poslovne in tehnološke kompetence projektnega tima. Akkermans (2002) in Aduri et al (2002) v svojih člankih poudarjata, da so dobro opredeljene kompetence projektnega tima vidne pri uspešnih uvedbah rešitev ERP. Mabert et al (2003) omenja, da projektni tim, ki uvaja rešitev ERP, porabi veliko časa, da podrobno opredeli potek uvajanje rešitve. Opredelitev poteka vsebuje opredelitev procesa uvajanja modulov in prenovo poslovnih procesov ter opredelitev vključevanja prioritet s strani uprave. Izbira »pravih« oseb, ki sodelujejo v procesu uvajanja rešitve ERP in njihova motivacija, je kritična za uspeh uvajanja rešitve ERP (Khan, 2002; Jarrar et al, 2000). Umble in Umble (2002) pravita, da mora biti projektni tim, ki uvaja rešitev ERP, sestavljen iz posameznikov z vseh poslovnih področij. Le-ti morajo biti v organizaciji spoštovani in morajo imeti pooblastila uprave, da lahko sprejemajo kritične odločitve v procesu uvajanja. Projektni tim mora biti sestavljen iz skupka poslovnih analitikov, tehničnih strokovnjakov in ključnih uporabnikov organizacije ter iz zunanjih svetovalcev (Parr in Shanks, 2000; Bancroft et al, 1998; Skok in Legge, 2002). Člani projektnega tima morajo biti izbrani po njihovi strokovnosti, dosežkih iz preteklosti, ugledu in fleksibilnosti (Umble et al, 2002) in morajo imeti naslednje karakteristike (Khan, 2002):
• morajo biti motivirani in ambiciozni, • morajo biti strokovnjaki na svojem poslovnem področju, • imeti sposobnost hitrega odločanja, • biti pripravljeni delati nadure in • igrati kot timski igralci.
Welti (1999) dodaja, da morajo zaradi zahtevnosti in kompleksnosti projekta uvajanja rešitev ERP biti člani projektnega tima ljudje z višjim potencialom za učenje. Poleg tega morajo biti
102
ključni člani projektnega tima zaposleni na projektu uvajanja za polni delovni čas, saj se lahko le tako zagotovi stalnost in napredek projekta. Projektni tim je zadolžen za izdelavo začetnega, podrobnega projektnega plana, mora določiti odgovornosti (zadolžitve) za posamezne aktivnosti in določiti časovne mejnike projekta uvajanja (Umble et al, 2002). Prav tako morajo imeti člani projektnega tima točno opredeljene vloge (Bancroft et al, 1998). Estaves et al (2002) je v svoji matriki določil, da je projektni tim pri uvedbi rešitve ERP z organizacijskega vidika strateški faktor. Organizacija projektnega tima naj ima matrični tip strukture (Khan, 2002), ki je sploščena organizacijska projektna struktura in kjer so kratke poti komunikacije in odločitev (Welti, 1999).
6.1.4 Izobraževanje uporabnikov rešitve ERP
Pomanjkanje izobraževanja uporabnikov in nerazumevanje delovanja rešitev ERP se kaže kot razlog za veliko problemov v procesu uvajanja rešitev ERP (Somers in Nelson, 2004). Nekateri avtorji (Al-Mashari et al, 2003; Umble et al, 2002; Aduri et al, 2002; Bradford and Florin, 2003; Bancroft et al, 2001; Estaves et al, 2002; Akkermans and Helden, 2002) dodajajo, da je nezadostno izobraževanje eden izmed pomembnejših razlogov, zakaj je bilo veliko rešitev ERP uvedenih neuspešno. Če zaposleni ne razumejo, kako rešitev ERP deluje, potem bodo poskušali najti poti, ki niso vedno primerne, da opravijo svoje delo (Umble et al, 2002). Tako celotne koristi rešitve ERP ni moč doseči, dokler končni uporabniki nove rešitve ne uporabljajo primerno. Glavni razlog izobraževanja je povečanje stopnje strokovnosti in znanja zaposlenih v organizaciji. Prav zato mora biti strategija izobraževanja in učenja v naprej pripravljena in se stalno posodabljati v času uvajanja (Mabert et al, 2003). Da je izobraževanje končnih uporabnikov uspešno, se mora začeti zgodaj, po možnosti že pred začetkom uvajanja (Umbe et al, 2002). Zhang et al (2002) zagovarja, da imamo tri vidike, na katere moramo biti pozorni pri izobraževanju in sicer:
1. logika in koncepti rešitve ERP, 2. značilnosti rešitve ERP in 3. učenje ob računalniku.
Izobraževanje dobi pomembnejšo vlogo v zadnjih korakih uvajanja, kjer se uporabniki spoznajo s poslovnimi zahtevami in se poveča spretnost zaposlenih (Somers in Nelson, 2004). Kot pravi Al-Sehali (2000), je za zamenjavo strojne in programske opreme potrebno par dni, za višjo stopnjo učne krivulje pa so potrebni tedni oziroma meseci. Poseben izziv pri uvajanju rešitve ERP je izbira primernega plana za izobraževanje in učenje končnih uporabnikov (Al-Mashari et al, 2003). Uprava (tudi projektni tim) pogosto podcenjuje raven izobraževanja zaradi povečanja stroškov projekta uvedbe (Umble et al, 2002). Dodaja, da naj bi organizacija v proces izobraževanja rešitve ERP namenila 10 do 15 % vsega proračuna za uvedbo rešitve ERP ter tako povečala uspeh uvajanja rešitve ERP za 80 %. Ker pa se pred ali med uvajanjem rešitve ERP vrši tudi prenova poslovnih procesov, Jarrar et al, (2000) poudarja, da je potrebno vse uporabnike rešitve ERP izobraziti, ponovno razporediti naloge in zavreči ustaljene procedure izvajanja nalog ter zgraditi nove iz temeljev.
103
6.1.5 Prenova poslovnih procesov
Ker so rešitve ERP narejene po principih najboljše prakse (angl. best practice) v posameznih panogah (O’Leary, 2000), so postale tudi inštrument za izboljšanje poslovnih procesov (Al-Mashari et al, 2002). Ni nujno, da se poslovni procesi izbrane rešitve ERP najbolje prilegajo poslovnim procesom organizacije, saj se uvajanje rešitve ERP ne nanaša samo na menjavo programa (IS), pač pa se nanaša na spreminjanje repozitorija podjetja in preoblikovanje poslovnih praks (Jarrar et al, 2000). Tako lahko organizacija prilagodi rešitev ERP, da se le-ta bolje prilega potrebam organizacije ali pa spremeni svoje poslovne procese, da se le-ti bolje prilegajo rešitvi ERP (Bradford in Florin; 2003). Če izbere prilagajanje rešitve ERP, potem se občutno povečajo stroški uvajanja in podaljša čas uvajanja rešitve ERP (Davenport, 1998). Ker pa so rešitve ERP narejene po principu najboljših poslovnih praks, je prenova obstoječih poslovnih procesov namenjena doseganju najboljših poslovnih standardov. To je mogoče, če je opravljena podrobna analiza obstoječih poslovnih procesov, kjer se določijo potencialne spremembe poslovnih procesov. Organizacija pa mora biti pripravljena na temeljne spremembe v odnosu do poslovnih procesov, da zagotovi uspeh prenove poslovnih procesov (Zhang et al, 2002). Vsi avtorji, ki omenjajo prenovo poslovnih procesov kot KDU se strinjajo, da je prenova poslovnih procesov ključ za uspešno uvedbo, vendar niso enotnega mnenja, kdaj naj organizacija prenovi svoje poslovne procese. Bancroft et al (1998) ter Somers in Nelson (2004) poudarjajo, da je potrebno poslovne procese spremeniti pred začetkom uvajanja rešitve ERP, ker zagovarjajo tezo, da je prenova poslovnih procesov pomembna v fazi izbire rešitve ERP in postane manj pomembna takrat, ko postane tehnologija rutina. Welti (1999) pa predlaga, da je potrebno prenovo poslovnih procesov izvesti po uvedbi rešitve ERP in ne pred, saj funkcionalnost in resničen potencial rešitve ERP nista dobro poznana na začetku uvajanja rešitve ERP, pač pa šele, ko je rešitev ERP uvedena.
6.1.6 Management sprememb
Obstoječa organizacijska struktura in procesi v večini organizacij niso kompatibilni s strukturo, orodji in obliko informacij, ki jih zagotavlja rešitev ERP (Umble et al, 2002). Vsaka rešitev ERP ima svojo logiko organizacijske strategije, organizacije in organizacijske kulture, ki lahko pomembno vpliva na organizacijsko strukturo, politiko organizacije, procese in zaposlene ter lahko povzroči odpor, zmedenost, presežek zaposlenih itd., če le-te spremembe niso vodene pravilno. Kot navajajo Somers in Nelson (2004) ter Al-Mashari et al (2003), veliko uvajanj rešitev ERP propade, ker organizacije podcenjujejo napore, ki so potrebni pri urejanju sprememb. Zaradi tega je pomembno, da organizacije planirajo proces preobrazbe organizacije, ki mora temeljiti na primerni strategiji in dobro definirani metodologiji uvajanja (Bancroft et al, 1998). Organizacije morajo vedeti, da se spremembe ne bodo zgodile čez noč in da je potreben čas, da bodo zaposleni spremenili ustaljeni način dela. Nekatere organizacije naredijo dolgoročni plan, s pomočjo katerega začnejo spreminjati organizacijsko kulturo precej prej, preden začnejo z uvedbo rešitve ERP (Skok in Legge, 2002).
104
Somers in Nelson (2004) pravita, da so aktivnosti urejanja sprememb pomembne v začetnih fazah projekta in se nadaljujejo skozi fazo posvojitve in fazo sprejetja. Če zaposleni niso primerno pripravljeni na spremembe, potem so predvidene posledice zanikanje, odpor in kaos. Umble et al (2002) dodaja, da morajo vsi zaposleni razumeti, kako bodo od uvedene rešitve ERP imeli korist oboji: tako organizacija kot tudi oni, saj bo njihovo delo poenostavljeno.
6.1.7 Komunikacija znotraj projektnega tima ter med projektnim timom in ostalimi v organizaciji
Pomembnost komunikacije med oddelki v organizaciji je dobro znana v literaturi uvajanja IT, saj ima komunikacija velik vpliv na zaposlene od začetne faze do sprejeta IS in pomaga zmanjšati možni uporabniški odpor. Komunikacija mora pokrivati področja obsega uvajanja rešitve ERP ter cilje in opravila projekta uvajanja rešitev ERP (Al-Mashari et al, 2003). Organizacija potrebuje učinkovito komunikacijo znotraj projektnega tima kot tudi v organizaciji. Khan (2002) poudarja, da je dobra komunikacija v projektnem timu zagotovljena:
• s tedenskimi sestanki tima, kjer se preveri in dopolni status projekta, • z objavljanjem informacij in statusom projekta v intranetu organizacije, • s formalnimi in neformalnimi srečanji …
Khan (2002) zaradi tega predlaga, da naj bo projektni tim lociran na eni lokaciji (v skupnem nadstropju). Tako se bodo člani projektnega tima lahko med sabo ves čas dogovarjali in hitro sprejemali odločitve itd. Al-Sehali (2002) pravi, da mora biti napredek projekta uvedbe rešitve ERP opazen takoj vsem zaposlenim v organizaciji. Napredek projekta mora biti posredovan vsem v organizaciji preko intraneta organizacije, okrožnic, elektronske pošte itd. in mora vključevati status projekta, spremembe, obvestila o izobraževanju itd. Nekateri avtorji, kot npr. Al-Mashari et al (2003) ter Somers in Nelson (2004) predlagajo, da naj ima organizacija komunikacijski plan. Komunikacijski plan naj bo razdeljen na več področij, ki vključujejo uvajanje rešitve ERP, podrobnosti urejanja sprememb poslovnih procesov, demonstracije uvedenih programskih modulov, navodila za izvedbo sprememb glede strategij in taktik ter določitev stičnih točk (Bancroft et al, 1998).
6.1.8 Vključitev in sodelovanje uporabnikov pri uvedbi rešitve ERP
Vključitev in sodelovanje vseh zaposlenih v organizaciji je ključnega pomena za uspešno uvedbo rešitve ERP, saj rešitve ERP podirajo meje med poslovnimi funkcijami in oddelki (Somers in Nelson, 2004). Gattiker in CFPIM (2002) poudarjata, da uvedena rešitev ERP predstavlja pretnjo za uporabnike, saj bodo nadrejeni imeli več kontrole nad njihovim delom. Poleg tega pa imajo uporabniki na voljo le kratko časovno obdobje, v katerem se morajo seznaniti s spremembami v njihovem delovnem procesu. Vključitev uporabnikov v fazi definiranja potreb IS v organizaciji lahko zmanjša odpor do potencialne rešitve ERP, saj imajo uporabniki občutek, da so oni tisti ljudje, ki izbirajo in sprejemajo odločitve. Predstavniki uporabniških skupin sodelujejo na dveh področjih (Zhang et al, 2002):
105
1. pri izbiri rešitve ERP in 2. v procesu uvedbe rešitve ERP.
Welti (1999) dodaja, da je odprta komunikacija zelo pomembna pri preprečevanju kroženja neutemeljenih govoric in pri zagotavljanju informacij končnim uporabnikom. Uporabniki potrebujejo zanesljive informacije, saj se jih projekt uvedbe direktno tiče. Poleg tega pa lahko rešitev ERP predstavlja za nekatere uporabnike nevarnost prenehanja zaposlitve. Z vključitvijo uporabnikov v projekt uvedbe rešitve ERP in z informiranjem uporabnikov se le-ti seznanijo z na novo nastalo situacijo, povečajo zaupanje v projekt uvedbe in njihove člane ter sprejmejo projekt uvedbe za svoj projekt.
6.1.9 Prenos podatkov iz starih rešitev ERP
Kakovost podatkov v obstoječih IS je opredeljena kot pomemben KDU pri uvedbi rešitve ERP (Gattiker in CFPIM, 2002). Če problemi s podatki niso odpravljeni v obstoječem IS, potem se bodo le-ti pojavili tudi v uvedeni rešitvi ERP (Al-Sehali, 2000). Ker so moduli rešitve ERP med sabo zelo povezani, lahko ima netočen vnos podatka v enem izmed modulov napačen učinek na funkcionalnost ostalih modulov (Zhang et al (2002); Umble et al (2002)). Iz obstoječega IS moramo prenesti v rešitev ERP glavne podatke (t. i. master podatke) in transakcijske podatke (Khan, 2002). Prenos podatkov pa pogosto vključuje tudi predelavo in spajanje podatkov, da le-ti ustrezajo podatkovnemu modelu rešitve ERP (Reif, 2001). Zato morajo biti vmesniki in pretvorba podatkov pripravljeni toliko časa vnaprej, da se opravi prenos podatkov v rešitev ERP in verificiranje podatkov (Welti, 1999). Khan (2002) pravi, da obstajata dve možni mesti, kjer se izvede verifikacija podatkov, in sicer v obstoječem IS pred selitvijo podatkov ali po selitvi podatkov na strani rešitve ERP. Testiranje rešitve je določeno kot niz opravil, s pomočjo katerih se zagotovi, da rešitev ERP deluje kot je bilo želeno. Testiranje mora vključiti prenesene podatke in vse možne situacije, ki se lahko zgodijo. Rezultati testa morajo sovpadati s tistimi, ki so bili predvideni v poslovnih scenarijih. Khan (2002) imenuje takšen test »Integracijski test« in ga je potrebno izvesti s pomočjo poslovnih scenarijev. Dobljene podatke integracijskega testa nato preveri projektni tim in ključni uporabniki, preden se podatki začnejo uporabljati v produkcijskem okolju (Welti, 1999). Somers in Nelson (2004) pravita, da je pretvorba podatkov KDU od začetka do posvojitve rešitve ERP pomemben dejavnik in postane manj pomemben dejavnik v času uporabe rešitve ERP.
6.1.10 Vključevanje zunanjih svetovalcev
Zaradi kompleksnosti rešitev ERP je znanje, kako uvesti rešitev ERP zelo pomembno. To znanje imajo zunanji svetovalci in zato je uspeh projekta uvedbe rešitve ERP močno odvisen od zmožnosti in znanja svetovalcev (Welti, 1999; Al-Sehali, 2000). Ker imajo zunanji svetovalci
106
poglobljeno znanje s področja uvedbe rešitve ERP, hitro odkrijejo praznine v izbrani rešitvi ERP glede na potrebe organizacije, zagotovijo strokovno znanje in razmišljajo izven okvirov organizacije, saj imajo izkušnje s predhodnim uvajanjem rešitev ERP (Khan, 2002). Ker so specializirani za posamezna področja, opravijo delo hitreje in učinkoviteje. Somers in Nelson (2004) pravita, da organizacija potrebuje zunanjo pomoč pri planiranju, namestitvi in prilagoditvi rešitve ERP organizaciji. Skok in Legge (2002) opozarjata, da je uporaba svetovalcev zelo pomembna, da pa mora organizacija vseeno paziti, da ne izgubi lastništva nad projektom uvedbe. Zato mora organizacija vzpostaviti prenos znanja v organizaciji tako, da določi vloge svetovalcev, njihova znanja in spretnosti, ter da se znanje v času uvedbe rešitve ERP prenese na zaposlene v organizaciji (Al-Mashari et al, 2003). Sicer lahko postaneta znanje in sposobnosti svetovalcev velik strošek za poslovanje (Skok in Legge, 2002). Pomembno je tudi, da ima organizacija strategijo, kako bo nadzirala svetovalce. Estaves et al (2002) poudarja, da so svetovalci pomemben organizacijski in taktični dejavnik, ter da je pomembna primerna vključitev svetovalcev v projekt uvedbe rešitve ERP.
6.1.11 Uporaba principov projektnega managementa
Projekt uvedbe rešitve ERP je velik, kompleksen in rizičen projekt zaradi kombinacije strojne in programske opreme ter organizacijskih, človeških in političnih virov, pri čemer igra zelo pomembno vlogo projektni management od začetka do konca projekta (Somers in Nelson, 2004; Akkermans in Helden, 2002). Projektni management je sestavljen iz naslednjih petih sestavin (Zhang et al, 2002):
1. formalen plan uvedbe, 2. realen časovni okvir, 3. periodični sestanki o statusu projekta, 4. dober projektni vodja in 5. člani projektnega tima, ki se spoznajo na posamezna področja poslovanja.
Al-Mashari et al (2003) poudarja, da približno 90 % projektov uvedb rešitev ERP presega časovni okvir ali predviden proračun zaradi slabe ocenitve projekta oziroma zaradi spreminjanja obsega funkcionalnosti v času projekta. Ker je uvedba rešitve ERP sestavljena iz množice kompleksnih aktivnosti, ki vključujejo vse poslovne funkcije in zahtevajo angažiranje organizacije za daljše obdobje, mora imeti organizacija učinkovito strategijo poslovnega managementa za nadziranje postopkov uvedbe (plan uvedbe) ter se s tem izogniti povečanju predvidenega proračuna ter zagotoviti uspešno uvedbo v vnaprej določenem časovnem okviru (Zhang et al, 2002). Da je lahko to opravilo narejeno učinkovito in uspešno, mora obstajati nekdo, ki ima vpliv na vse dele projekta (Welti, 1999). Ta oseba je projektni vodja, ki mora urejati in nadzirati projekt uvedbe rešitve ERP (Reif, 2001). Projektni vodja je oseba, ki je odgovorna za pripravo dnevnih opravil v zvezi s projektom uvedbe rešitve ERP in ki koordinira uporabo vseh organizacijskih virov s pogodbenimi partnerji in svetovalci, ponudnikom rešitev ERP in drugimi, ki so vključeni v projekt uvedbe (Al-Sehali, 2000). Učinkovitost te osebe se meri v zmožnosti za motiviranje članov projektnega tima, da hitro in kakovostno opravijo
107
predvideno delo na projektu. Akkermans and Helden (2002) dodajata, da mora biti ena izmed lastnosti projektnega vodja tudi zmožnost določene stopnje improvizacije. Umble et al (2002) poudarja, da mora biti projekt uvedbe rešitve ERP pripravljen tako, da je agresiven, pa kljub temu dosegljiv. Urnik izvajanja aktivnosti mora biti pripravljen tako, da vceplja in ohranja status nujnosti.
6.1.12 Aktivna vloga sponzorja projekta
Sponzor projekta je oseba, ki dobro pozna poslovanje organizacije in ima močan vpliv v organizaciji (Skok in Legge, 2002). Ta oseba je ponavadi nekdo iz uprave in ima pooblastila uprave, da lahko sprejema odločitve o bistvenih organizacijskih spremembah (Akkermans in Helden; 2002). Skok in Legge (2002) dodajata, da je priporočeno, da ima sponzor projekta predhodne izkušnje s projekti uvajanja IS, ki jih bo potreboval pri uspešnem reševanju konfliktov pred in med uvedbo rešitve ERP. Tako mora biti sponzor projekta oseba, ki omogoča »da projekt teče« in zagotavlja (Khan, 2002):
• da je delež managementa projekta viden na vseh ravneh, • da uprava podpira projekt uvedbe ERP od začetka do konca projekta, • da so zagotovljeni potrebni viri v kritičnih trenutkih, • rešuje konflikte med sprtimi stranmi v organizaciji ter • pohitri proces odločitev in kompromisov.
Sponzorja projekta lahko smatramo kot KDU, ki igra kritično vlogo v fazi sprejetja tehnologije (Somers in Nelson, 2004).
6.1.13 Izbira primerne rešitve ERP
Vse rešitve ERP imajo omejeno funkcionalnost. Nekatere rešitve so primernejše za velike organizacije, druge za manjše organizacije. Nekatere rešitve so »de facto« standard za posamezno industrijo, druge so močno vezane na določeno geografsko območje (Akkermans in Helden, 2002). Ker uvedba rešitev ERP pogosto stane več milijonov dolarjev, je smiselno, da organizacije namenijo majhen del te vsote za raziskavo in analizo rešitev ERP, ki so na voljo na trgu (Al-Sehali, 2000). Da povečajo stopnjo za uspeh uvedbe rešitve ERP, morajo organizacije izbrati tisto rešitev ERP, ki se najbolje prilega njihovim potrebam, kamor spada strojna oprema, podatkovna baza in operacijski sistem (Zhang et al, 2002). Jarrar et al (2000) tako pravi, da je delovanje rešitve ERP močno odvisno od informacijske infrastrukture. Zato moramo upoštevati pri izbiri informacijske infrastrukture dva vidika (Zhang et al, 2002):
1. kompatibilnost programske ter strojne opreme s potrebami organizacije in 2. enostavnost prilagajanja programske opreme.
Ko smo izbrali rešitev ERP, se moramo nadalje odločiti, katere module bomo uvedli in katera verzija modulov (rešitve ERP) je za nas najprimernejša. Če izberemo napačno rešitev ERP, se
108
bomo soočili s neprileganjem organizacijskih potreb s funkcionalnostjo rešitve ERP, kar bo vodilo v prilagajanje rešitve ERP organizacijskim potrebam (Akkermans in Helden, 2002). To pa podaljšuje projekt uvedbe ter povečuje stroške in riziko projekta (Akkermans in Helden, 2002). Somers in Nelson (2004) pravita, da izbira primerne rešitve ERP v fazi izbire rešitve ERP vključuje tudi druge pomembne odločitve, kot so: proračun uvedbe, časovni okvir uvedbe ter predvidene cilje in rezultate projekta. Dodajata, da večji kot je napor, ki ga vključimo v proces izbire rešitve ERP, večjo imamo možnost za uspešno izveden projekt uvedbe rešitve ERP.
6.1.14 Minimalno prilagajanje rešitve ERP posebnostim organizacije
Večina organizacij podcenjuje napore, ki so potrebni pri prilagajanju rešitve ERP. Spreminjanje načrta rešitve ERP poveča kompleksnost prilagajanja izvorne kode (Mabet et al, 2003). Zato Al-Sehali (2000) predlaga, da ne spreminjamo izvorne kode rešitve ERP. Dodaja, da je potrebno uporabiti pripravljeno izvorno kodo rešitve ERP v največji možni meri, tudi če s tem žrtvujemo del funkcionalnosti. Če bomo spremenili izvorno kodo, potem bomo imeli težave pri nadgradnjah rešitve ERP, saj bomo morali vedno znova testirati in verificirati nove verzije rešitve ERP preden jih bomo namestili. Na tej predpostavki, Parr in Shanks (2000) predlagata, da naj organizacija uporabi t. i. »vanilla« rešitev ERP, kar pomeni minimalno prilagajanje in nobeno spreminjanje izvorne kode. Somers in Nelson (2004) dodajata, da je uspešnost uvedbe rešitve ERP pogosto rezultat minimalnega prilagajanja, saj se s prilagajanjem povezuje povečanje stroškov projekta uvedbe, podaljšanjem časa uvedbe in nezmožnostjo uporabe prednosti vzdrževanja in nadgradenj s strani ponudnika rešitev ERP. Khan (2002) se ne strinja z zgoraj omenjenim, saj pravi, da če niso narejene prilagoditve uvedene rešitve ERP, bo rešitev sicer dobro delovala, ne bo pa podpirala poslovanja organizacije. Zato meni, da če so prilagoditve potrebne, jih je potrebno najprej oceniti in odobriti in šele nato izvesti oziroma zavrniti po preučitvi vseh možnosti.
6.2 Analiza kritičnih dejavnikov uspeha informacijskih projektov
V prejšnjem poglavju smo opisali 14 v literaturi najpomembnejših KDU, ki usodno vplivajo na uspešno uvedbo rešitve ERP. Zanimalo nas je, ali se isti KDU pojavljajo tudi pri informacijskih projektih na splošno in v kolikšni meri se pojavljajo v teh projektih. Poiskali smo članke na temo KDU informacijskih projektov v revijah in »on-line« podatkovnih bazah. Našli smo 16 člankov na to temo. Dobljene KDU informacijskih projektov na splošno smo primerjali s KDU rešitev ERP in na osnovi primerjave ugotovili, kateri dejavniki so pomembni v obeh tipih projektov, kateri KDU se pojavljajo kot pomembnejši dejavniki pri projektih uvedbe rešitev ERP in kateri KDU se pojavljajo kot pomembnejši dejavniki pri informacijskih projektih na splošno. Pri iskanju člankov o KDU informacijskih projektov smo med zadetki dobili tudi članke s področja KDU rešitev ERP, ki pa jih nismo vključili v spodnjo tabelo. Tabela 14 prikazuje 16 dejavnikov, ki so omenjeni v literaturi več kot 5-krat. Dejavnik, ki se najpogosteje pojavlja v obravnavani literaturi, je projektno planiranje, ki ga omenja 12 avtorjev. Sledijo mu naslednji dejavniki (številka v oklepaju pomeni število člankov, kjer je bil omenjen faktor):
109
1. management sprememb in sprejemanje s strani uporabnikov (9), 2. sposobnosti in znanja razvijalcev (9), 3. kompetence in organizacija projektnega tima (9), 4. tehnološka arhitektura (9), 5. komunikacija (9), 6. projektni management (9), 7. nadziranje in kontrola kakovosti (9), 8. pomanjkanje virov (8), 9. podpora uprave (8), 10. zmogljivost, zanesljivost in vzdrževanje sistema (7), 11. razvojno okolje (6), 12. orodja in metode (6), 13. podpora ponudnika sistema (5), 14. uporabniško izobraževanje (5).
Manj kot pet-krat pa so omenjeni še naslednjih dejavniki: sproti posodobljena projektna dokumentacija, izbira programske opreme, sistemska integracija in vmesniki, testiranje, nerealistična pričakovanja zaradi pomanjkanja znanja itd. Primerjali smo KDU informacijskih projektov na splošno in KDU rešitev ERP in smo ugotovili sledeče, da se nekateri dejavniki pojavljajo v obeh raziskavah. Na osnovi tega dejstva smo razdelili dejavnike v tri skupine (slika 38):
1. KDU, ki so pomembni za informacijske projekte na splošno, 2. KDU, ki so pomembni za uvedbo rešitev ERP in 3. KDU, ki so pomembni pri obeh projektih.
SLIKA 38: KDU rešitev ERP in informacijskih projektov na splošno
• Vključitev in podpora uprave • Kompetence in organizacija
projektnega tima • Projektni management
• Komunikacija • Izobraževanje končnih uporabnikov
• Management sprememb • Aktivna vloga končnih uporabnkov
• Sponzor projekta …
• Jasni cilji, strategija in obseg
• Analiza in pretvorba podatkov
• Prenova poslovnih procesov
• Izbira rešitve ERP • Svetovalci • Minimalno
prilagajanje …
ERP IS
• Projektno planiranje • Razvoj sistema • SW projektni
management • SW management
kakovosti • Vmesniki • Planiranje sistemskega
testiranja • Prototipiranje …
110
TABELA 14: Objavljeni članki o KDU uvedb IS na splošno
9 7 8 1 3 15 12 16 14 10 2 4 13 6 5 11 Projektno planiranje X X X X X X X X X X X X Management sprememb X X X X X X X X X Sposobnosti in znanje razvijalcev X X X X X X X X X
Kompetence in organizacija projektnega tima X X X X X X X X X
Tehnološka arhitektura X X X X X X X X X Komunikacija X X X X X X X X X Projektni management X X X X X X X X X Nadziranje in kontrola kakovosti X X X X X X X X X
Pomanjkanje virov (ljudi, HW, SW…) X X X X X X X X
Podpora uprave X X X X X X X X Zmogljivost, zanesljivost in vzdrževanje sistema X X X X X X X
Razvojno okolje X X X X X X Orodja in metode X X X X X X Management ponudnika podpora in pogodba) X X X X X
Izobraževanje končnih uporabnikov X X X X X
[1] Al-Mashari in Zairi (1999) [2] Beckley in Gaines (1991) [3] Bender et al (2000) [4] Cadle in Yeates (2001) [5] Cotterell in Hughes (1995) [6] Hartman in Ashrafi (2002)
[7] Havelka (2003) [8] Jennex in Adelakun (2003) [9] Kanter in Walsh (2004) [10] Kendra in Taplin (2004) [11] Lientz in Rea (1998) [12] O’Brien (2003)
[13] Schmidt, Lytinen, Keil in Cule (2001)
[14] Shrednick, Shutt in Weiss (1992) [15] Taylor (2004) [16] Walsh in Kanter (1988)
111
Zgornja slika potrjuje naša predvidevanja o povezavi med KDU rešitev ERP in KDU informacijskih projektov na splošno. Tako obstaja nekaj takih KDU, ki so pomembni tako za projekte uvedbe rešitev ERP kot za projekte IS na splošno. Menimo, da so KDU, ki se pojavljajo v obeh skupinah projektov, pomembnejši, saj veljajo za vse projekte IS. Ti dejavniki so:
• podpora uprave, • kompetence in organizacija projektnega tima, • projektni management, • komunikacija znotraj projektnega tima in med projektnim timom in organizacijo, • uporabniško izobraževanje, • management sprememb in • vključite končnih uporabnikov v informacijske projekte.
Iz primerjave KDU obeh skupin smo opazili, da se dejavnik »Vključitev končnih uporabnikov« v člankih KDU rešitev ERP pojavi devetkrat, medtem ko se v člankih o projektih IS pojavi manj kot petkrat. Menimo, da je vključitev končnih uporabnikov, kljub temu zelo pomembna v vseh projektih IS (Laudon in Laudon, 2000) in pozitivno vpliva na uspeh izvedbe projektov, saj lahko končni uporabniki pripomorejo k izboljšanju izkoristka IS v smeri poslovnih zahtev in kontrole delovanja sistema. Poleg tega imajo uporabniki občutek, da sodelujejo pri razvoju IS, kar ima pozitivno vlogo na management sprememb.
6.3 Raziskovalni model kritičnih dejavnikov uspeha
V strokovni literaturi se danes pogosto pojavljajo članki na temo kritičnih dejavnikov uvajanja rešitev ERP, ki smo jih podrobneje opredelili v prvem delu tega poglavja. Tako smo dobili KDU, za katere strokovna javnost meni, da so pomembnejši. Ker se želimo priključiti tem raziskavam, nas je zanimalo, ali imajo tudi v slovenskem prostoru v prvem delu opredeljeni KDU enako pomembnost za slovenske organizacije, kot jo opredeljuje svetovna strokovna javnost. Večina prebranih člankov opredeljuje KDU v projektu uvedbe rešitve ERP (na splošno). Pri prebiranju strokovne literature nismo zasledili raziskave, ki bi preučevala pomembnost posameznih KDU rešitev ERP v posameznih fazah uvedbe rešitve ERP. Poleg tega vemo, da vsi omenjeni KDU niso enako pomembni v vseh fazah uvedbe rešitve ERP, zato smo pripravili raziskovalni model KDU z vidika faz uvajanja. Pri uvajanju rešitev ERP lahko organizacija uvede rešitev ERP po metodi ponudnika rešitve ERP. Večina organizacij se poslužuje tega načina uvedbe rešitve ERP, saj naj bi metodologija ponudnika rešitve ERP upoštevala kritičnost dejavnikov uvedbe, ki so posebej pomembni za posamezno rešitev ERP. Zanima nas, ali se pomembnost KDU rešitev ERP spreminja glede na metodo uvedbe. V prebrani strokovni literaturi avtorji omenjajo KDU »Komunikacija znotraj projektnega tima in med projektnim timom ter ostalimi v organizacij« kot en KDU ali pa kot dva KDU. Ker želimo izpostaviti pomembnost komunikacije znotraj projektnega tima in komunikacije med projektnim timom in organizacijo smo se odločili, da ta KDU 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.
112
6.3.1 Kritični dejavniki uspeha z vidika faz uvajanja
Na osnovi strokovne literature s področja KDU uvajanja rešitev ERP lahko predpostavimo, da vsi KDU niso enako pomembni v vseh fazah uvedbe rešitve ERP, pač pa so nekateri pomembni skozi vse faze uvedbe rešitve ERP, drugi so bolj pomembni v začetnih fazah uvedbe rešitve ERP, tretji pa v kasnejših fazah uvedbe rešitve ERP. V tabeli 15 smo na osnovi prebrane literature prikazali pomembnost KDU glede na posamezne faze uvajanja rešitev ERP. Projekt uvajanja rešitve ERP smo razdelili na naslednjih 6 faz:
1. faza: izbira rešitve ERP, 2. faza: analiza poslovnih procesov, 3. faza: konfiguriranje rešitve ERP, 4. faza: testiranje rešitve ERP, 5. faza: uvedba rešitve ERP in 6. faza: stabilizacija delovanja.
TABELA 15: KDU glede na faze uvedbe rešitve ERP
I. FAZA 2. FAZA 3. FAZA 4. FAZA 5. FAZA 6. FAZA
Jasni cilji, strategija in obseg uvajanja rešitve X X X X X X
Vključitev in podpora uprave X X X X X X
Aktivna vloga sponzorja projekta X X X X
Organizacija projektnega tima in njegove kompetence X X X X
Uporaba principov projektnega managementa X X X X
Komunikacija znotraj projektnega tima X X X
Komunikacija med projektnim timom in ostalimi v organizaciji X X X X
Vključevanje zunanjih svetovalcev X X
Vključitev in sodelovanje uporabnikov X X X
Izobraževanje končnih uporabnikov X X
Management sprememb X X X X X X
Prenova poslovnih procesov X X
Izbira tehnološke arhitekture rešitve ERP X
Čim manj prilagajanja rešitve ERP posebnostim organizacije X X
Prenos podatkov iz starih rešitev v rešitev ERP X X
Menimo, da so glede na prebrano literaturo v vseh fazah uvajanja rešitve ERP pomembni naslednji KDU: jasni cilji, strategija in obseg uvajanja, vključitev in podpora uprave in management sprememb. V fazi izbire rešitve ERP se organizacija odloči za zamenjavo obstoječ-ega/ih IS z rešitvijo ERP, rešitvijo BoB oziroma z lastno rešitvijo. Tako mora organizacija na osnovi prednosti in slabosti izbrati med rešitvijo ERP, rešitvijo BoB oziroma lastnim razvojem. Če se odloči za rešitev ERP, mora iz množice na trgu uveljavljenih rešitev izbrati tisto, ki se kar najbolje prilega organizaciji. V tej fazi mora imeti organizacija dobro opredeljene cilje, strategije in obseg uvajanja. Poleg tega se mora organizacija že v prvi fazi zavedati, da bo uvedba novega
113
IS spremenila ustaljene delovne procese in zato mora začeti urejati spremembe, ki jih bo prinesla uvedba rešitve ERP. V fazi analize poslovnih procesov preučimo na osnovi izbrane rešitve ERP obstoječe poslovne procese in poslovne procese rešitve ERP. Če je možno, prilagodimo svoje poslovne procese procesom rešitve ERP, sicer pa na konceptualni ravni pripravimo načrt. Poleg dejavnikov, ki so pomembni v vseh fazah uvedbe, v tej fazi posebej izpostavljamo naslednje dejavnike: organizacija projektnega tima in njegove kompetence, uporaba principov projektnega managementa, komunikacija znotraj projektnega tima, komunikacija med projektnim timom in ostalimi v organizaciji, prenova poslovnih procesov in čim manj prilagajanja rešitve ERP posebnostim organizacije. V fazi konfiguriranja rešitve ERP je potrebno prilagoditi izbrano rešitev ERP, da bo le-ta ustrezala pričakovani funkcionalnost rešitve ERP. Pomembnejši KDU te faze so: aktivna vloga sponzorja projekta, organizacija projektnega tima in njegove kompetence, uporaba principov projektnega managementa, komunikacija znotraj projektnega tima, vključevanje zunanjih svetovalcev, prenova poslovnih procesov ter čim manj prilagajanja rešitve ERP posebnostim organizacije. V fazi testiranja rešitve ERP je potrebno na testni instanci preveriti delovanje prilagojene rešitve ERP. V tej fazi so pomembnejši naslednji KDU: aktivna vloga sponzorja projekta, organizacija projektnega tima in njegove kompetence, uporaba principov projektnega managementa, komunikacija znotraj projektnega tima, komunikacija med projektnim timom in ostalimi v organizaciji, vključitev in sodelovanje uporabnikov ter prenos podatkov iz starih rešitev v rešitev ERP. V fazi uvedbe rešitve ERP pripravimo produkcijsko instanco, izvedemo zadnja testiranja, prenesemo prečiščene podatke v produkcijsko instanco, izvedemo izobraževanje in pripravimo vse potrebno, da lahko zaženemo rešitev ERP v živo. Pomembnejši dejavniki te faze so: aktivna vloga sponzorja projekta, organizacija projektnega tima in njegove kompetence, uporaba principov projektnega managementa, komunikacija znotraj projektnega tima, komunikacija med projektnim timom in ostalimi v organizaciji, vključevanje zunanjih svetovalcev, vključitev in sodelovanje uporabnikov, izobraževanje končnih uporabnikov ter prenos podatkov iz starih rešitev v rešitev ERP. Po zagonu v živo sledi faza stabilizacija delovanja, kjer je potrebno dodatno izobraževanje končnih uporabnikov, da bodo čim bolje izkoristili zmogljivost uvedene rešitve ERP. V raziskavi želimo preučiti pomembnost KDU glede na faze uvajanja slovenskih organizacij, ki imajo uvedeno rešitev ERP.
6.3.2 Kritični dejavniki uspeha z vidika metodologij
Večina večjih ponudnikov rešitev ERP ima za uvajanje svoje rešitve pripravljeno svojo metodologijo uvajanja. Tako želimo preveriti KDU po pomembnosti z vidika metodologij uvajanja. Pri uvedbi projektov rešitve SAP, se danes v večji meri uporablja metodologija ASAP. Metodologija vsebuje strukturiran pristop uvedbe, s pomočjo katerega projektni tim hitro uvede novo rešitev. Poleg hitre uvedbe prinaša metodologija ASAP tudi druge prednosti kot so: boljše sprejetje rešitve SAP s strani uporabnikov, dobro definiran zemljevid in dobro
114
dokumentacijo skozi vse faze metodologije ASAP (Estaves et al, 2002, 4). Tudi pri uvedbi rešitve SAP moramo biti pozorni na KDU, ki so bili navedeni v prejšnjem poglavju. Razdelitev KDU glede na faze uvedbe rešitve SAP s pomočjo metodologije ASAP je v svojem članku predstavil Estaves et al (2002, 5). Pri uvedbi rešitve ERP s pomočjo metodologije ASAP si po pomembnosti sledijo naslednji KDU (1 pomeni najpomembnejši)41:
1. projektni management, 2. sodelovanje končnih uporabnikov, 3. notranja in zunanja komunikacija, 4. podpora uprave, 5. management sprememb, 6. izobraževanje končnih uporabnikov, 7. prenova poslovnih procesov, 8. organizacija projektnega tima in njegove kompetence, 9. zunanji svetovalci, 10. jasni cilji, strategija in obseg uvedbe rešitve ERP, 11. čim manj prilagajanja rešitve ERP posebnostim organizacije, 12. izbira tehnološke arhitekture rešitve ERP.
Podrobnejšo tabelo KDU glede na faze metodologije ASAP najdemo v prilogi A na strani 157. Po navedbah organizacije Ittoolbox (2003) je metodologija ASAP v veliko pomoč pri izogibanju pastem in vsebuje podroben nabor vsebinsko-specifičnih procedur, ki vodijo v uspešno strukturirano uvedbo in optimizacijo funkcionalnosti rešitve mySAP ERP. Isti vir tudi navaja, da je v metodologiji ASAP večini KDU namenjeno veliko pozornosti med fazami uvedbe, kljub temu pa ni namenjeno dovolj pozornosti naslednjim štirim KDU oz. ni učinkovite podpore za (Ittoolbox, 2003):
1. podporo uprave, 2. vlogo projektnega managerja, 3. zaupanje med partnerji in 4. formaliziranim projektnim planom.
Uprava mora dajati znake, da zaupa v projekt uvedbe rešitve SAP. Zaupanje v projekt uvedbe si lahko pridobi tako, da spremlja obseg virov in proračun projekta. Zato bi moralo biti upravi ves čas projekta zagotovljeno, da lahko preveri trenutni status uvedbe in/ali bo investicija pokrila predvidene cilje, kar pa s trenutnimi orodji podjetja SAP ni zagotovljeno. Kritična je tudi vloga projektnega managerja in celotnega vodstvenega tima projekta. Pri teh vlogah se lahko pojavita dva problema: konflikt interesov in politične posledice. Konflikt interesov se nanaša na odločitev, ali naj bodo v glavnem projektnem timu tudi predstavniki ponudnika rešitev ERP. Ti lahko vplivajo na uvedbo, saj lahko vsako informacijo posredujejo v organizaciji tako, da bodo sami ali njihovi pogodbeni partnerji v celoti izpeljali uvedbo. Politične posledice, ki imajo vpliv na spremembo strukture organizacije, se nanašajo na vprašanje, ali naj bodo managerji člani projektne skupine, ki uvaja rešitev ERP. Le-ti so motivirani z dejstvom, da si pridobijo čim boljšo pozicijo po končani uvedbi. Brez vnaprej pripravljenih ciljev za ta profil ljudi lahko njihovo vedenje onemogoči najbolj učinkovito pot do končnega rezultata. 41 V seznamu so navedeni samo tisti KDU, ki smo jih kot najpomembnejše opredelili na osnovi strokovne literature na začetku tega poglavja. Ostali KDU, ki jih izpostavlja Estaves et al (2003, 5) so še: projektni plan, iskanje in odprava motenj, predanost zaposlenih in svetovalcev, management obsega, zaupanje med partnerji, hitre odločitve,
115
Uspeh pri uvedbi je odvisen tudi od sprotnega odpravljanja neskladnosti med partnerji in organizacijo. Ključni vidik urejanja tega KDU je dvostranski pristop, ki definira, kaj bo narejeno in kdaj bo narejeno. Izvršen je v treh delih: določitev celotnega plana uvedbe in njihovih stroškov, določitev urnika procesov, ki jih je potrebno nenehno posodabljati in meriti, izvršitev le-teh ter določitev ključnih mejnikov (opravljeno delo) in časovni plan za celotno skupino partnerjev. Brez formaliziranega, učinkovitega in »živega« projektnega plana, ki bi omogočal določanje točnega statusa na osnovi doseženih ciljev, je status uvedbe projekta rešitve ERP nedefiniran. Metodologija ASAP in njena orodja zagotavljajo dobro začetno točko za izdelavo takšnega plana, v katerem definiramo zahtevane komponente. Naslednji koraki pa niso podprti, so pa pomembni in zahtevajo dobro podporo prilagajanju planov posameznim uvedbam, vpogled v kritične točke projekta in definiranje ključnih mejnikov. Pomembno je, da je program projektnega plana prilagojen posamezni organizaciji. Za nadziranje napredka projekta lahko danes uporablja projektni tim orodja za urejanje projektnega managementa, kot je npr. MS Project. S pomočjo takšnega orodja lahko kreiramo plan opravil s primernim urnikom, definiramo mejnike in prilagodimo odvisnost med opravili. Opravila v planu so identična opravilom v zemljevidu in jih je mogoče uvoziti kot predlogo iz orodij ASAP (Brand, 1999, 131). Zaradi nezadostne pozornosti orodij ASAP, ki podpirajo metodologijo ASAP, si lahko organizacije danes pomagajo z nakupom oz. najemom programov drugih programerskih hiš (kot npr. zgoraj omenjen MS Project), ki pripomorejo k zagotavljanju podpore zgornjih štirih kritičnih dejavnikov uspeha. V raziskavi želimo KDU rangirati po pomembnosti glede na to, ali so uvedli rešitev ERP po metodologiji ponudnika. Nato želimo primerjati, ali se vrstni red KDU razlikuje z vrstnim redom KDU z vidika uvedbe po lastni metodi. Nadalje želimo preveriti tudi, kako so razporejeni KDU glede na metodologijo uvedbe ASAP oziroma On Target. Pričakujemo, da se ne bodo pojavile razlike med KDU metodologije ASAP in KDU metodologije On Target.
6.4 Raziskava kritičnih dejavnikov uspeha
Z raziskavo KDU se ukvarjamo že dve leti, in sicer smo začeli tako, da smo najprej poiskali knjige in članke preko »on-line« baz in preštudirali temeljno literaturo na temo uvajanja rešitev ERP (1). Pri prebiranju literature smo si izpisovali KDU, ki so jih omenili avtorji in jih nato razvrstili po pomembnosti (2). Nato smo pripravili raziskovalni model, v katerem smo opredelili, kaj želimo z raziskavo preveriti (3). Na osnovi raziskovalnega modela smo pripravili vprašalnik (4), čemur je sledilo verificiranje vprašalnika (5). V naslednjem koraku smo pridobili elektronske naslove vzorca organizacij, katerim smo poslali spletni (oziroma klasični) vprašalnik (6). Sledilo je opominjanje anketirancev in prejemanje odgovorov na vprašalnik (7). Po zaključku zbiranja anket je sledila obdelava podatkov s pomočjo programov MS Excel 2003 in SPSS 12.0 (8). Na osnovi obdelave podatkov smo naredili osnovno analizo obdelanih rezultatov (9). V nadaljevanju raziskave smo naredili še podrobnejšo analizo rezultatov s pomočjo zahtevnejših statističnih testov (10). Nato pa bo sledilo zbiranje podatkov s pomočjo študij primerov slovenskih organizacij, ki so uvedle rešitev ERP (11) in obdelava ter analiza rezultatov (12). Potek raziskave KDU vidimo tudi na sliki 39.
116
SLIKA 39: Potek raziskave KDU rešitev ERP v slovenskem okolju
6.4.1 Priprava vprašalnika
Zaradi značilnosti anket, ki so povzetek praks, situacij ali pogledov v določenem trenutku in jih izvedemo s pomočjo vprašalnika ali intervjuja, smo se odločili, da je za nas v začetni fazi najprimernejša anketa (Galliers, 1992, 150). Fowler (2001) dodaja, da lahko pridobimo podatke z anket, s pomočjo osebnega intervjuja, telefonskega intervjuja, e-pošte, spletnega vprašalnika ... Če izpolnjujejo anketiranci vprašalnike elektronsko, so manjši stroški izvajanja anketiranja, čas zbiranja statističnih podatkov je krajši, kakovost zbranih podatkov pa je lahko boljša, ker odpade potreba po večkratnem vnosu podatkov v datoteko za statistično obdelavo z določenim statističnim programom. Zato smo se odločili, da bomo anketo izvedli s pomočjo spletnega vprašalnika na takšen način, da bomo poslali spletni naslov ankete anketirancem preko elektronske pošte. Zato smo najprej zbrali elektronske naslove anketirancev, pripravili spletno anketo ter jo verificirali. Pri zbiranju elektronskih naslovov smo se obrnili na ponudnike rešitev ERP in sicer, podjetje SAP Slovenija za rešitev mySAP ERP, Microsoft za rešitev Navision in podjetje Linkpro za rešitev GEAC System 21. S podjetij SAP Slovenija in Linkpro so nam posredovali elektronske naslove vodij projektov uvedbe rešitve ERP. Ker s podjetjem Microsoft nismo uspeli vzpostaviti kontakta, smo se obrnili na partnerje, ki uvajajo to rešitev ERP. Nekateri izmed partnerjev so nam z veseljem priskočili na pomoč in posredovali spletni vprašalnik svojim strankam, drugi pa niso želeli sodelovati z nami. Pri tistih partnerjih smo na njihovih spletnih straneh poiskali referenčna podjetja ter v spletni storitvi GVIN42 poiskali naslove teh podjetij. Spletni vprašalnik smo pripravili v programu MS FrontPage in je sestavljen iz treh delov. S pomočjo prvega dela smo želeli pridobiti splošno sliko o organizacijah, ki so odgovorile na vprašalnik. Ta sklop sestavljajo vprašanja o velikosti podjetja, panogi in uvedenih modulih. V drugem delu nas je podrobneje zanimala izvedba uvedbe rešitve ERP. Tako so nas zanimali: razlogi za odločitev za uvedbo rešitve, med katerimi rešitvami ERP so se organizacije odločale v ožjem izboru, kateri so bili razlogi za izbiro uvedene rešitve ERP, v kolikšni meri je izbrana rešitev ustrezala poslovnemu procesu organizacije, v kolikšni meri so poslovne procese organizacije prilagodili poslovnim procesom rešitve ERP, koliko mesecev je
42 Spletna storitev GVIN se nahaja na spletnem naslovu http://www.gvin.com.
117
trajal proces uvedbe, ali se je v času uvedbe spremenil obseg predvidene funkcionalnosti, stroški uvedbe in problemi pri uvajanju. V tretjem delu vprašalnika pa smo želeli preveriti, kateri KDU so usodno vplivali na proces uvajanja rešitve ERP v slovenskih organizacijah. Tako smo ta del razdelili na dva dela. V prvem delu nas je zanimala pomembnost posameznih dejavnikov glede na posamezno fazo uvajanja. V drugem delu nas je zanimalo rangiranje KDU po pomembnosti glede na pristop uvajanja in glede na metodo uvajanja. Ker smo imeli ločene naslove za organizacije, ki imajo uvedeno rešitev mySAP ERP, MS Navision in GEAC System 21, smo prilagodili vprašalnike tako, da smo pri tretjem vprašanju za vsako rešitev pripravili module, ki jih uvajajo. Vprašalniki se nahajajo na spletnih naslovih:
• vprašalnik SAP R/3 in mySAP ERP na http://epf-oi.uni-mb.si:8000/ERP/index_s.htm • vprašalnik Microsoft Navision na http://epf-oi.uni-mb.si:8000/ERP/index_n.htm • vprašalnik GEAC System 21 na http://epf-oi.uni-mb.si:8000/ERP/index_g.htm
Vprašalnik je sestavljen iz 15 vprašanj. Večina vprašanj je objektivnega tipa. Pri tistih vprašanjih, kjer nas je zanimal razlog, pa je vprašanje sestavljeno tako, da morajo anketiranci obrazložiti svojo izbiro odgovora (predvidevajo opisne odgovore).
6.4.2 Zbiranje podatkov
Spletne vprašalnike smo pošiljali preko elektronske pošte na naslove vodij projektov uvedbe v organizacijah. V elektronskem sporočilu smo poslali dopis s povezavo na spletno stran ankete. Ker imajo v nekaterih organizacijah zaprte vse nestandardne porte za spletne strani, kot je npr. port 8000, kjer se nahaja naša spletna anketa, smo vsem poslali enako anketo v pdf obliki (priloga B, stran 157). Prvo pošiljanje dopisov (s spletnim naslovom ankete) preko elektronske pošte je potekalo v aprilu 2005, in sicer za rešitvi MS Navision in mySAP ERP. V aprilu je potekalo tudi pošiljanje vprašalnikov preko klasične pošte vodjem informatike oziroma direktorju podjetja za rešitev MS Navision. Pošiljanje elektronske pošte smo ponovili v maju 2005. Nismo pa ponovno pošiljali klasične pošte. V maju smo poslali dopis (s spletnim naslovom ankete) preko elektronske pošte vodjem projektov za rešitev GEAC System21 (2 krat). Z anketiranjem smo zaključili konec maja 2005. Na anketo je odgovorilo 49 anketirancev od 206 poslanih anket. Sledi podrobnejša analiza pošiljanja anket. Na spletni strani podjetja SAP Slovenija smo zasledili 73 referenčnih podjetij (25. 3. 05), vendar so nam s podjetja SAP Slovenija posredovali 54 elektronskih naslovov vodij projektov, tako da smo poslali vprašalnike. Dobili smo malo manj kot polovico odgovorov, in sicer 22 odgovorov. Na spletnih straneh Microsofta smo zasledili, da imamo v Sloveniji okrog 250 namestitev. Tako smo poslali 30 anket preko spleta in 117 anket preko klasične pošte. Prejeli smo 23 odgovorov. Konec aprila 2005 smo pridobili še elektronske naslove vodij projektov organizacij, ki imajo uvedeno rešitev GEAC System 21. Elektronske naslove nam je posredovalo podjetja Linkpro d.o.o. V Sloveniji je izvedenih 5 uvedb, od tega smo dobili 3 odgovore.
118
6.4.3 Obdelava podatkov
Odgovore vprašalnikov za rešitve SAP, Navision in GEAC smo zbrali v datoteko oblike csv. To datoteko smo uvozili v MS Office Excel 2003. Datoteke z rezultati posameznih rešitev smo združili v eno datoteko, kjer smo dodali stolpec z oznako rešitve. Tako smo dobili datoteko z 49 odgovori, od katerih je bil eden neveljaven, zato smo ga izključili iz nadaljnje obdelave. Za obdelavo podatkov smo uporabili programa MS Office Excel 2003 in SPSS 12. Sledi podrobnejša analiza podatkov posameznih vprašanj. Vprašanja, ki se nanašajo na zadnji sklop vprašanj (o KDU) pa so predstavljena v naslednjem poglavju. Na anketo je uspešno odgovorilo 48 vprašanih, ki so opredelili velikost organizacije43 sledeče: 13 organizacij je označilo možnost majhno podjetje (12 z rešitvijo Navision in 1 rešitvijo SAP), 16 organizacij srednjeveliko podjetje (3 rešitvijo GEAC, 8 z rešitvijo Navision in 5 z rešitvijo SAP) in 19 organizacij veliko podjetje (3 z rešitvijo Navision in 16 z rešitvijo SAP), kar vidimo tudi v grafu 1. GRAF 1: Razvrstitev rešitev glede na velikost podjetja
0
12
1
3
8
5
0
3
16
0
2
4
6
8
10
12
14
16
18
GEAC Navision SAP
Malo podjetjeSrednjeveliko podjetjeVeliko podjetje
Vprašanje: Opredelite dejavnost organizacije je bilo opisno vprašanje. Dejavnosti smo razvrstili glede na klasifikacijo statističnega urada Slovenije (KLASJE)44. Organizacije smo razvrstili po dejavnostih na osnovne kategorije (prva črka klasifikacije), razen za proizvodnjo, kjer smo dejavnosti razvrstili na podkategorije (prvi dve črki klasifikacije). Razdelitev dejavnosti se nahaja v prilogi C na strani 160. V grafu 2 vidimo, da se večina odgovorov (25 od 48 oziroma 52,1 %) nanaša na proizvodne organizacije (dejavnost D). S sedmimi odgovori (14,6 %) sledita dejavnost trgovina, popravila motornih vozil in izdelkov široke porabe (dejavnost G) ter poslovanje z nepremičninami, najem in poslovne storitve (dejavnost K). Podrobnejšo razdelitev organizacij glede na panogo in uvedeno rešitev ERP vidimo v naslednji tabeli 16. Iz tabele lahko razberemo, da so se vse tri uvedbe rešitev GEAC izvedle v proizvodnih podjetjih, vendar ne v isti industrijski panogi. Pri rešitvi Navision je bilo v proizvodno dejavnost uvedenih 7 namestitev (dejavnost D), sledi trgovina s 5 namestitvami
43 V slovenskem merilu je majhna organizacija do 50 zaposlenih, prihodek do 4,2 mio EUR in vrednost aktive do 2,1 mio EUR; srednje velika organizacija do 250 zaposlenih, prihodek do 16,8 mio EUR in vrednost aktive do 8,4 mio EUR in velika organizacija nad 250 zaposlenih, prihodek nad 16,8 mio EUR in vrednost aktive nad 8,4 mio EUR. 44 KLASJE se nahaja na spletnem naslovu: http://www.stat.si/klasje/tabela.aspx?cvn=1891 (9. 8. 05).
119
(dejavnost G) in storitve tudi s 5 namestitvami (dejavnost K). 15 namestitev rešitve SAP je bilo uvedenih v proizvodnji dejavnosti (dejavnost D) od tega 5 v proizvodnji kovin in kovinskih izdelkov (dejavnost DJ), 4 v proizvodnji strojev in naprav (dejavnost DK) in 3 v proizvodnji kemikalij, kemičnih izdelkov in plastičnih mas. GRAF 2: Pregled organizacij po dejavnosti po klasifikaciji KLASJE
52%
4%4%
15%
6%2%
15% 2% D
E
F
G
I
J
K
L
Iz teh podatkov vidimo, da je rešitev Navision bolj prisotna v trgovinski in storitveni dejavnosti, saj imamo na tem področju tudi več majhnih in srednjevelikih organizacij, kjer je v večji meri prisotna rešitev Navision. Rešitev SAP pa je bolj prisotna na proizvodnem področju, kar je bilo tudi pričakovano, saj ima industrijske rešitve, ki predstavljajo standarde za posamezne industrijske panoge, kot npr. rešitev za farmacijo. TABELA 16: Pregled namestitev rešitev po dejavnostih
Dejavnost45 D46 DA DB DE DG DJ DK DL E F G I J K L Skupaj Rešitev G 0 0 0 1 1 0 1 0 0 0 0 0 0 0 0 3 N 1 0 1 1 2 0 0 2 1 2 5 2 1 5 0 23 S 2 1 0 0 3 5 4 0 1 0 2 1 0 2 1 22Skupaj 3 1 1 2 6 5 5 2 2 2 7 3 1 7 1 48
G = rešitev GEAC, N = rešitev Navision in S = rešitev SAP Nadalje nas je zanimalo, koliko modulov izbrane rešitve so uvedle organizacije. Pri rešitvi GEAC imajo vse tri organizacije uvedene modul Finančno poslovanje in modul Upravljanje s kupci in logistika, ena organizacija pa ima uveden tudi modul Planiranje proizvodnje in kontrola. Podrobnejše podatke najdemo v tabeli 32 priloge D na strani 161. Organizacije, ki imajo uvedeno rešitev Navision, imajo uveden modul Finančno poslovanje. Pri uvajanju rešitve MS Navision je pogoj, da moramo najprej uvesti modul Finančno poslovanje, nato pa lahko uvedemo ostale module. Iz tabele 33 v prilogi D vidimo, da ima precej organizacij uvedena tudi modula Skladiščno poslovanje (16 namestitev) in Upravljanje s kupci (11 namestitev). Iz tabele pa lahko razberemo tudi to, da imajo organizacije v prihodnosti namen uvajati tudi dodatne module s palete rešitve MS Navision. Večina organizacij, ki ima uvedeno rešitev SAP, ima uveden modul Finančnega knjigovodstva, 16 organizacij modul Upravljanje osnovnih sredstev in 14 organizacij modul Proizvodnja in distribucija in modul Materialno poslovanje, 12 organizacij modul Planiranje proizvodnje itd. S dobljenih podatkov pa lahko tudi sklepamo, da imajo organizacije namen
45 Opis oznak dejavnosti se nahaja v prilogi C na strani 161. 46 Tiste organizacije, ki so pod dejavnost napisale proizvodnja in niso podrobneje napisale industrijo, se nahajajo v stolpcu D.
120
uvajati dodatne module v prihodnosti tako s področja »back office« kot tudi nove module s področja e-poslovanja, kamor spadajo moduli SCM, CRM in BI. Tabela s podrobnejšimi podatki se nahaja v prilogi D na strani 162 (tabela 34). V drugem sklopu vprašanj nas je zanimal proces izbire in uvedbe izbrane rešitve ERP. V tem sklopu smo pripravili 11 vprašanj (od vprašanja 4 do 10 in od vprašanja 12 do 15). Rezultate prikazujemo v nadaljevanju tega poglavja. Najprej so nas zanimali najpomembnejši trije razlogi, zakaj so se organizacije odločile za izbiro rešitve ERP. Največ anketirancev (17)47 je odgovorilo, da zaradi celovitosti rešitve. Sledili pa so naslednji odgovori:
• boljši dostop do podatkov s strani zaposlenih (12), • posodobitev poslovnih procesov s pomočjo rešitve ERP (9), • enkraten vnos podatkov (8), • nezdružljivost obstoječih IS (8), • večja zanesljivost delovanja sistema (7), • zahteva lastnika (6), • poročila (5) in • prilagodljivost in fleksibilnost rešitve ERP (5).
Manj kot 5-krat pa so se pojavili naslednji odgovori: poslovanje s poslovnimi partnerji preko e-poslovanja (4), ažurnost podatkov (3), dobra podpora s strani ponudnika rešitev ERP (3), z nabavo rešitve ERP si organizacija kupi kontinuiran razvoj rešitve (3), modularna arhitektura rešitve ERP (3), ekonomičnost (2), izboljšanje organizacijske strukture (2), povečanje organizacijske fleksibilnosti (2), preizkušen programski paket (2), razpoložljivost posebnih funkcionalnosti za posamezno panogo (2) itd. V procesu izbire rešitve ERP organizacija izbere rešitev ERP na osnovi rešitev, ki se nahajajo v ožjem izboru. Zanimalo nas je, med katerimi tremi rešitvami ERP so se organizacije odločale v ožjem izboru (graf 3). GRAF 3: Število v ožjem izboru omenjenih rešitev ERP v odstotkih
24%
23%22%
16%
5% 3% 7%Lokalni ponudnikiNavisionSAPBaanOracleLastna rešitevDrugo
Precejšnje število odgovorov se nanaša na lokalne ponudnike rešitev ERP (22), med katerimi so bili največkrat omenjeni Comtron Tron Intercenter; Kopa, Hermes Datalab, Panteon, Perftech in SAOP. Z enim odgovorom manj, sledi rešitev Navision (21) in nato rešitev SAP (20). Ostale omenjene rešitve ERP so še: Baan (15), Oracle (5), lastna rešitev (3) in drugo (5). Iz podatkov nadalje vidimo, da so se organizacije, ki so uvedle rešitev MS Navision odločale predvsem med rešitvijo Navision in rešitvami slovenskih ponudnikov rešitev ERP. Ta podatek 47 V nadaljevanju poglavja pomeni številka v oklepaju število odgovorov.
121
ne preseneča, saj je večina slovenskih rešitev ERP zasnovanih za male in srednjevelike organizacije in so konkurenčne rešitvi MS Navision. Organizacije, ki so uvedle rešitev SAP (pretežno velike organizacije) so v ožjem izboru pretežno izbirale med rešitvami SAP, Baan in Oracle. Na vprašanje, kateri so bili glavni razlogi, zakaj ste se odločili za izbrano rešitev ERP, se je največkrat pojavil odgovor »reference« (11). Sledili so naslednji odgovori:
• celovitost ponudbe rešitve ERP (10), • zmogljivost in stabilnost delovanja rešitve ERP (9), • zagotovitev podpore (8), • stroški in cena ERP (7), • zahteve lastnikov oziroma kupcev (6).
Poleg teh odgovorov so se pojavili še sledeči: usklajenost tehnoloških platform (4), sledenje tehnološkemu razvoju (4), prekrivanje funkcionalnosti rešitve ERP s funkcionalnostjo organizacije (4), zaupanje in dobro ime uvajalca rešitev ERP (4), standard v panogi (4), metodologija uvajanja (4), dostop do podatkov in izdelava poročil v realnem času (4), standardni sistem (4), povezljivost rešitve ERP z drugimi IS (4), lokalizacija (4), modularnost rešitve (3), lokalizacija (3), usklajenost rešitve ERP s poslovno strategijo in vizijo kupca ERP (2), razširjenost na trgu (2), skladnost rešitve s slovensko zakonodajo in računovodskimi standardi (2), konkurenca ima uvedeno enako rešitev ERP (2). Na vprašanje, v kolikšni meri je izbrana rešitev ERP ustrezala poslovnemu procesu vaše organizacije, so bili možni štirje odgovori, in sicer: popolnoma, v veliki meri, delno ali slabo. Dobili smo 45 odgovorov (93,8). Nihče ni označil možnost slabo, sicer pa je v 7 primerih rešitev ERP popolnoma ustrezala poslovnemu procesu organizacije, 32 primerih je ustrezala v veliki meri in 6 primerih je ustrezala delno (graf 4 podrobneje pa v tabeli 35 v prilogi D, na strani 162). GRAF 4: Prikaz prileganja izbrane rešitve ERP poslovnim procesom organizacije v odstotkih
V veliki meri71 %
Popolnoma16 %
Delno13 %
Želeli smo preveriti, ali je v vseh treh opazovanih rešitvah ERP enak delež, ki mu ustrezajo odgovori popolno, v veliki meri in delno prileganje posamezni rešitvi ERP (H0). Tako s pomočjo kontigenčne tabele (tabela 17) vidimo, da se večina rešitev MS Navision (14 namestitev) in rešitev SAP (17) v veliki meri prilegala poslovnim procesom organizacije. χ2
test (χ2 =3,167, P= 0,53 – Likelihood Ratio) nam ne omogoča, da bi zavrnili to hipotezo (H0), glede na to lahko predvidevamo, da enak delež rešitev ustreza odgovorom glede na rešitev.
122
TABELA 17: Pregled prileganja posameznih rešitev poslovnim procesom organizacij
Popolno V veliki meri Delno Skupaj Rešitev GEAC 1 1 1 3 Navision 4 14 3 21 SAP 2 17 2 21 Skupaj 7 32 6 45
G = rešitev GEAC, N = rešitev Navision in S = rešitev SAP
Na vprašanje, kateri pristop uvajanja so organizacije uporabile, je odgovorilo 46 anketirancev (95,8 %). Izbrali so lahko izmed naslednji pet možnosti (tabela 36 v prilogi D na strani 162):
I. uvedli smo vse module hkrati in nato na vnaprej določen dan zagnali v živo rešitev ERP, stare informacijske sisteme pa ugasnili (»Big bang pristop«);
II. nove module rešitve ERP smo uvedli zaporedno, npr. najprej finančni modul, nato proizvodni modul itd.(fazni pristop);
III. po uvedbi rešitve ERP in zagonu rešitve ERP sta nekaj časa delovala oba sistema (vzporedni pristop);
IV. najprej smo uvedli rešitev ERP za enostavnejši poslovni proces, kasneje pa smo uvedli rešitev ERP za zahtevnejše poslovne procese (procesni pristop);
V. kombinacija zgornjih pristopov. Z grafa 5 vidimo, da je skoraj polovica vprašanih organizacij uporabila pristop Bing bang (22 odgovorov oziroma 45,8 %), sledi kombinacija vseh pristopov s 16,7 % (8 odgovorov) in nato fazni pristop s 14,6 % (7 odgovorov). GRAF 5: Prikazuje pristop uvajanja v odstotkih
I48 %
II15 %
III13 %
IV7 %
V17 %
I – pristop Big bang, II – fazni pristop, III – vzporedni pristop, IV – procesni pristop in V – kombinacija pristopov Iz tega vprašanja lahko nadalje ugotovimo, kateri pristop je bil uporabljen pri posameznih rešitvah. Na grafu 6 vidimo, da je bilo največ namestitev SAP (13 namestitev) uvedenih po pristopu Big Bang in da nobena organizacija, ki ima uvedeno rešitev SAP, ni uporabila vzporednega pristopa. Tudi rešitev MS Navision je bila največkrat uvedena po pristopu Big bang (8-krat) in sledi pa vzporedni pristop (6-krat). Zanimalo nas je, ali sta spremenljivki pristop uvedbe in uvedena rešitev neodvisni med sabo (H0). χ2-test nam potrjuje, da spremenljivki nista neodvisni med sabo (χ2= 15,165; P=0,056).
123
GRAF 6: Grafični prikaz porazdelitve rešitev glede na pristop uvajanja
1 10
10
8
2
6
1
5
13
4
01
3
0
2
4
6
8
10
12
14
I II III IV V
Pristop
Šte
vilo
odg
ovor
ov
GNS
G - GEAC, N - Navision, S – SAP; I - Big bang, II – fazni pristop, III – vzporedni pristop, IV – procesni pristop, V – kombinacija pristopov Sledilo je vprašanje, po kateri metodi so organizacije uvedle rešitev ERP. Anketiranci so imeli na voljo tri odgovore, in sicer: po metodi ponudnika rešitve ERP, po lastni metodi ali drugo. Odgovorilo je 45 anketirancev (93,8 %), 3 odgovori pa so manjkali (6,3 %; tabela 37 v prilogi D na strani 162). 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 %), ostali anketiranci pa so odgovorili z drugo (3 odgovori oz. 6,3 %) kar nam prikazuje tudi graf 7. GRAF 7: Prikaz različnih metod uvajanja slovenskih organizacij
Po metodi ponudnika
75 %
Drugo7 %Po lastni metodi
18 %
Če nadalje razdelimo odgovore glede metode uvedbe na posamezne proučevane rešitve ERP, vidimo v tabeli 18, da je bilo po metodi ponudnika uvedenih 34 rešitev, in sicer: po metodi ponudnika GEAC 2 rešitvi, po metodi On Target podjetja Microsoft 17 rešitev in po metodi ASAP podjetja SAP 15 rešitev. TABELA 18: Prikaz rešitev glede na metodo uvedbe
Metoda uvedbe \ Rešitev GEAC Navision SAP Skupaj Po metodi ponudnika 2 17 15 34 Po lastni metodi 0 4 4 8 Drugo 1 0 2 3 Skupaj 3 21 21 45
124
Pri uvedbi rešitev ERP morajo pogosto organizacije svoje poslovne procese prilagoditi poslovnim procesom rešitve ERP. Zanimalo nas je, koliko so anketiranci poslovne procese organizacije prilagodili uvedeni rešitvi. Na voljo so imeli štiri odgovore: v celoti, v veliki meri, delno in nič. Na to vprašanje je odgovorilo 46 anketirancev (95,8 %), 2 anketiranca nista odgovorila na vprašanje (4,2 %). Nihče od anketirancev ni v celoti prilagodil svoje poslovne procese procesom rešitve ERP, 11 oz. 22,9 % vprašanih je odgovorilo, da so jih prilagodili v veliki meri, 34 oz. 70,8 % vprašanih je odgovorilo, da so jih prilagodili delno in samo eden je odgovoril, da niso prilagajali poslovnih procesov procesom rešitve ERP (tabela 38 v prilogi D na strani 162). Iz tabele 19 vidimo, da se največ odgovorov nanaša na delno prilagajanje rešitve tako pri rešitvi Navision (18 odgovorov) kot pri rešitvi SAP (15 odgovorov). TABELA 19: Prikaz prilagoditev procesov glede na uvedeno rešitev ERP
Rešitev V veliki meri Delno Nič Skupaj
GEAC 2 1 0 3 Navision 4 18 0 22 SAP 5 15 1 21
Skupaj 11 34 1 46 Na vprašanje, koliko mesecev je trajal proces uvajanja rešitve ERP, so imeli anketiranci na voljo 5 odgovorov, in sicer: do 3 mesece, 3 do 6 mesecev, 6 do 9 mesecev, 9 do 12 mesecev in nad dvanajst mesecev (graf 8). Na to vprašanje je odgovorilo 45 anketirancev (93,8 %), 3 niso odgovorili na vprašanje (6,3 %; tabela 39 v prilogi D na strani 163). Največ odgovorov se je nanašalo na več kot 12 mesecev (15 vprašanih oz. 31,3 %). Od teh jih je 11 uvedlo rešitev SAP, 3 rešitev Navision in 1 rešitev GEAC (tabela 20). Sledi 10 odgovorov (20,8 %) za obdobje od 3 do 6 mesecev, v katerem je bilo izvedenih 8 namestitev rešitve Navision in 2 namestitvi rešitve SAP. 8 odgovorov za obdobje 9 do 12 mesecev, v katerem so bile uvedene 4 rešitve Navision, 3 rešitve SAP in 1 rešitev GEAC. Sledi 7 odgovorov za obdobje od 6 do 9 mesecev in 5 odgovorov za obdobje do 3 mesece. GRAF 8: Grafični prikaz časa uvedbe rešitve ERP v slovenskih organizacijah
9 do 12 mesecev18 %
6 do 9 mesecev16 %
3 do 6 mesecev22 %
Do 3 mesece11 %Nad 12 mesecev
33 %
TABELA 20: Čas uvedbe rešitve ERP glede na izbrano rešitev
GEAC Navision SAP Skupaj
Do 3 mesece 1 3 1 5 3 do 6 mesecev 0 8 2 10 6 do 9 mesecev 0 3 4 7 9 do 12 mesecev 1 4 3 8 Nad 12 mesecev 1 3 11 15
Skupaj 3 21 21 45
125
Glede na dobljene podatke smo želeli preveriti, ali sta v povezavi velikost organizacije in čas uvedbe rešitve ERP. S pomočjo Spearmanove korelacije dobimo rezultat: r = 0.437, P = 0.003, ki nam kaže, da sta ti dve spremenljivki zmerno pozitivno korelirani na nivoju 5 %. Iz tega lahko sklepamo, da večje organizacije uvajajo rešitve ERP dalj časa, kar je bilo tudi pričakovati. Vprašanje časa uvedbe se je nadaljevalo s podvprašanjem »Ali je projekt uvedbe rešitve ERP trajal dlje od načrtovanega«. Možna sta bila dva odgovora, in sicer: da ali ne. Na vprašanje je odgovorilo 39 anketirancev (81,3 %), 9 jih na vprašanje ni odgovorilo (18,8 %). 24 anketirancev je odgovorilo z ne, kar je 61,5 %. 15 anketirancev je odgovorilo z da, kar je 38,5 %. V teh organizacijah se je uvajanje rešitve ERP v povprečju zavleklo za 6,75 mesecev od načrtovanega časa. Najpogostejši razlogi, ki so jih anketiranci navedli za zamudo pri uvajanju rešitve ERP, so bili: zaradi kompleksnost poslovnih procesov je zmanjkalo časa za celovito testiranje sistema, v začetni fazi je bilo izobraževanje uporabnikov slabo, razširitev predvidenega obsega rešitve ERP, prilagajanje slovenski zakonodaji, pasivno sodelovanje projektnega tima pri analizi, nepoznavanje procesa, zelo ozko znanje o celotnem procesu, vztrajanje pri obstoječih postopkih, nepripravljenost na spremembe, omejena podpora sponzorja, delavci, ki so sodelovali v procesu, so bili preveč obremenjeni s svojim tekočim delom, togost delovne organizacije pri sprejemanju kritičnih odločitev pri spremembi delovnih procesov, napačna ocena trajanja uvajanja. Na vprašanje »Ali se je obseg predvidene funkcionalnosti v času uvajanja spremenil« so bili možni naslednji odgovori: precej zmanjšal, malo zmanjšal, se ni spremenil, malo povečal in precej povečal. Na vprašanje je odgovorilo 44 anketirancev (91,7 %), 4 anketiranci niso odgovorili na vprašanje (8,3 %). Med odgovori je bilo največ takšnih, kjer se obseg funkcionalnosti ni spremenil (16 odgovorov, kar je 36,4 %), sledijo odgovori, kjer se je obseg funkcionalnosti malo povečal (12 odgovorov, kar je 27,3 %), nato so odgovori, kjer se je funkcionalnost precej povečala (10 odgovorov, 22,7 %), 6 anketirancev (13,6 %) je odgovorilo, da se je obseg funkcionalnosti malo zmanjšal. Nihče pa ni odgovoril, da se je obseg funkcionalnosti precej zmanjšal (graf 9). GRAF 9: Prikaz spremembe načrtovane funkcionalnosti v času uvedbe rešitve ERP v odstotkih
Malo povečal27 %
Se ni spremenil36 %
Malo zmanjšal14 %
Precej povečal23 %
Če podrobneje pogledamo podatke o spremembi funkcionalnosti po posameznih preučevanih rešitvah ERP vidimo, da se obseg predvidene funkcionalnosti ni spremenil v 16 primerih, in sicer 1-krat pri uvedbi rešitve GEAC, 9-krat pri uvedbi rešitve Navision in 6-krat pri uvedbi rešitve SAP (tabela 21). Se je pa v 12 primerih malo povečal in sicer največkrat (9-krat) pri uvedbah rešitve SAP in 3-krat pri uvedbi rešitve Navision. 10 odgovorov pa se je nanašalo na precejšnje povečanje funkcionalnosti v času uvedbe, od tega 6 odgovorov za uvedbo rešitve Navision in po 2 odgovora za ostali dve rešitvi. Najpogostejši razlogi, zakaj se je obseg funkcionalnosti spremenil od načrtovanega, so bili:
126
• z uvajanjem se dejansko spozna funkcionalnost sistema in s tem se odkrije nove priložnosti, ki jih ni smiselno izpustiti iz projekta;
• tekom analiziranja in definiranja poslovnih procesov so ključni uporabniki bolje doumeli pomen uvedbe integrirane informacijske podpore, kar je posledično pomenilo povečanje obsega funkcionalnosti;
• slaba analiza delovnih procesov in nesodelovanje vodstvenega kadra ter uporabnikov; • prehod na novejšo verzijo, izdelava dodatnih poročil; • pojavili so se novi uporabniki iz drugih oddelkov družbe; • novi zakonski predpisi.
TABELA 21: Prikaz odvisnosti spremembe funkcionalnosti glede na uvedeno rešitve ERP
Malo
zmanjšal Se ni
spremenil Malo povečal Precej povečal Skupaj
GEAC 0 1 0 2 3 Navision 3 9 3 6 21 SAP 3 6 9 2 20
Skupaj 6 16 12 10 44 S pomočjo Spearmanove korelacije smo preverili korelacijo obsega funkcionalnosti z velikostjo organizacije, stroški uvedbe, časom uvajanja in prilagajanjem poslovnih procesov organizacije poslovnim procesom rešitve ERP. Spearmanova korelacija je bila signifikantna na 10 % nivoju le za korelacijo med obsegom funkcionalnosti rešitve ERP in prilagajanju poslovnih procesov organizacije poslovnim procesom rešitve ERP (r = 0,286; P = 0,06). Iz tega lahko sklepamo, da je med njima nizka pozitivna korelacija, kar pomeni, da če je morala organizacija v povprečju svoje poslovne procese v veliki meri prilagoditi poslovnim procesom rešitve ERP, potem se je funkcionalnost rešitve ERP malo zmanjšala. Pri stroških uvedbe rešitve ERP nas ni zanimal znesek, pač pa, ali so se stroški projekta uvedbe rešitve ERP spremenili od načrtovanih. Anketiranci so imeli na voljo naslednjih 5 odgovorov: precej manjši od načrtovanih, malo manjši od načrtovanih, enaki načrtovanim, malo večji od načrtovanih in precej večji od načrtovanih. Na vprašanje je odgovorilo 44 organizacij, kar je 91,7 %, 4 organizacije niso odgovorile na zastavljeno vprašanje (8,3 %). Tabelo 40, ki prikazuje frekvence odgovorov se nahaja v prilogi D (stran 163), tu pa prikazujemo grafično ponazoritev odstotkov spremembe stroškov uvedbe ERP glede na načrtovane stroške uvedbe rešitve ERP (graf 10). Od možnih odgovorov se je največkrat pojavil odgovor malo večji od načrtovanih (21 odgovorov, 47,7 %), sledi odgovor enaki načrtovanim z 11 odgovori oz. 25 %, nato odgovor precej večji od načrtovanih z 10 odgovori (22,7 %) in z 2 odgovoroma malo manjši od načrtovanih. Nihče ni odgovoril, da so bili stroški precej manjši od načrtovanih. GRAF 10: Grafični prikaz spremembe stroškov uvedbe glede na načrtovane stroške v odstotkih
Malo manjši od načrtovanih
5% Enaki načrtovanim
25%
Malo večji od načrtovanih
47%
Precej večji od načrtovanih
23%
127
Če primerjamo spremembo stroškov glede na uvedeno rešitev, vidimo v tabeli 22, da se pri odgovoru malo manjši od načrtovanih pojavi samo rešitev SAP, pri odgovoru enak načrtovanim se pojavi 6 odgovorov za rešitev Navision in 5 odgovorov za rešitev SAP. Pri odgovoru malo večji od načrtovanih se najpogosteje pojavi rešitev SAP (12 odgovorov), 7- krat rešitev Navision in 2-krat rešitev GEAC. Vidimo, da se je pri 22,7 % (10 odgovorov) obseg stroškov precej povečal glede na načrtovane stroške in sicer, največ z 8 odgovori pri rešitvi Navision. TABELA 22: Prikaz odvisnosti spremembe stroškov glede na uvedeno rešitev ERP
Rešitev \ Stroški Malo manjši od
načrtovanih Enak
načrtovanim Malo večji od načrtovanih
Precej večji od načrtovanih Skupaj
GEAC 0 0 2 1 3 Navision 0 6 7 8 21
SAP 2 5 12 1 20 Skupaj 2 11 21 10 44
Najpogostejši odgovori, zakaj so se stroški uvedbe spremenili od načrtovanih, so bili:
• večji obseg funkcionalnosti kot je bil načrtovan, • večje število svetovalnih ur zunanjih svetovalcev, • večje število vmesnikov z ostalimi aplikacijami, kot je bilo prvotno načrtovano, • vztrajanje pri prilagajanju rešitve ERP obstoječim postopkom in procesom, • uporaba lastnega znanja, • potrebne so bile večje prilagoditve sistema našim potrebam, nekaterih bistvenih
izpisov za delo v organizaciji osnovna verzija programa ni vsebovala, • potrebna nadgradnja in dodelave zaradi nepravilnega delovanja in netočnih podatkov.
Spearmanova korelacija je signifikantna na 10 % nivoju (r = 0,289, P = 0,06) za nizko pozitivno korelacijo med stroški uvedbe in ustreznostjo poslovnih procesov rešitve ERP poslovnim procesom organizacije. To pomeni, da če so poslovni procesi rešitve ERP v veliki meri ustrezali poslovnim procesom organizacije, potem so bili stroški uvedbe nižji. Na vprašanje, ali so se pri uvajanju rešitve ERP pojavili večji problemi, sta bila možna odgovora da ali ne. Na to vprašanje je odgovorilo 44 organizacij oz. 91,7 %, niso pa odgovorile 4 organizacije (8,3 %). Večina organizaciji (68,2 % oz. 30 odgovorov) meni, da se pri uvajanju niso pojavili večji problemi, medtem ko jih 31,8 % oz. 14 organizacij meni, da so se pojavili večji problemi, ki so sledeči: odpor uporabnikov do sprememb, slabo izvedeno izobraževanje ter slaba in nepopolna navodila za uporabo, neprimerni svetovalci, spremenjeno delovanje zaradi nadgradenj osnove rešitve, preslabo računalniško znanje uporabnikov, nizka strokovnost in nesistematično uvajanje ponudnika rešitve, premalo vključen srednji management, nezadostno testiranje rešitve s strani uporabnikov, ne dovolj definirani procesi, kadrovska problematika tako pri nas kot pri uvajalcu. Če pogledamo, pri kateri rešitvi se številčno najpogosteje pojavljajo problemi, potem ugotovimo, da so se v največji meri pojavili pri rešitvi Navision (8 odgovorov). TABELA 23: Kontigenčna tabela spremenljivk rešitev in problem
Rešitev \ Problem DA NE Skupaj
GEAC 1 2 3Navision 8 13 21SAP 5 15 20
Skupaj 14 30 44
128
Če pri obdelavi upoštevamo samo rezultate rešitev Navision in SAP, potem lahko uporabimo χ2 test za testiranje ničelne hipoteze, da je enak delež organizacij, ki so uvedle rešitev Navision in rešitev SAP, imelo enake probleme. Ker je P = 0,368, ničelno hipotezo zavrnemo.
6.5 Analiza kritičnih dejavnikov uspeha
V tretjem oziroma osrednjem delu vprašalnika so morali vprašani rangirati KDU od 1 do 15, kjer je 1 pomenilo najpomembnejši dejavnik in 15 najmanj pomemben dejavnik. Na ta del vprašalnika, je odgovorilo 65 % (oz. 31) vprašanih, ki so razporedili KDU po sledečem vrstnem redu (podrobnejši pregled podatkov je v tabeli 41 priloge E na strani 162) :
1. jasni cilji, strategija in obseg uvajanja rešitve (Mx = 2,72)48, 2. vključitev in podpora uprave (Mx = 5,66), 3. organizacija projektnega tima in njegove kompetence (Mx = 5,81), 4. vključitev in sodelovanje uporabnikov (Mx = 6,42), 5. komunikacija med projektnim timom in ostalimi v organizaciji (Mx = 7,28), 6. komunikacija znotraj projektnega tima (Mx = 7,58), 7. izobraževanje končnih uporabnikov (Mx = 7,71), 8. prenova poslovnih procesov (Mx = 7,74), 9. vključevanje zunanjih svetovalcev (Mx = 8,47), 10. aktivna vloga sponzorja projekta (Mx = 8,84), 11. prenos podatkov iz starih rešitev v rešitev ERP (Mx = 9,13), 12. čim manj prilagajanja rešitve ERP posebnostim organizacije (Mx = 9,19), 13. uporaba principov projektnega managementa (Mx = 9,87), 14. management sprememb (Mx = 10,74), 15. izbira tehnološke arhitekture rešitve ERP (Mx = 11,63).
Iz tabele 42 v prilogi E (stran 162) vidimo, da so nekateri izmed KDU odvisni. Med njimi obstaja zmerna pozitivna korelacija. Ti KDU so:
• uporaba principov projektnega managementa ter izbira tehnološke arhitekture (r = 0,499),
• management sprememb ter čim manj prilagajanja rešitve ERP posebnostim organizacije (r = 0,487),
• aktivna vloga sponzorja ter prenova poslovnih procesov (r = 0,469), • komunikacija med projektnim timom in ostalimi v organizaciji ter management
sprememb (r = 0,465), • vključitev in podpora uprave ter vključevanjem zunanjih svetovalcev (r = 0,464), • aktivna vloga sponzorja ter vključitev in sodelovanje uporabnikov (r = 0,464), • komunikacija med projektnim timom in ostalimi v organizaciji ter prenos podatkov iz
starih rešitev v rešitev ERP (r = 0,457), • izobraževanje uporabnikov rešitve ERP ter čim manj prilagajanja rešitve ERP
posebnostim organizacije (r = 0,45), • prenova poslovnih procesov ter izbira tehnološke arhitekture (r = 0,433), • komunikacija znotraj projektnega tima ter prenova poslovnih procesov (r = 0,432), • organizacija projektnega tima in njegove kompetence ter management sprememb (r =
0,429), • organizacija projektnega tima in njegove kompetence ter vključitev in sodelovanje
uporabnikov pri uvedbi ERP (r = 0,419),
48 Mx označuje aritmetično sredino.
129
• vključitev in sodelovanje uporabnikov pri uvedbi ERP ter management sprememb (r = 0,416),
• komunikacija znotraj projektnega tima ter prenos podatkov iz starih rešitev v rešitev ERP (r = 0,415),
• aktivna vloga sponzorja ter čim manj prilagajanja rešitve ERP posebnostim organizacije (r = 0,4).
Rangiranje KDU po pomembnosti iz raziskave lahko sedaj primerjamo s pomembnostjo posameznih KDU iz strokovne literature (sklic na TABELA 13: V zadnjih petih letih objavljeni članki na temo KDU uvajanja rešitev ERP na strani 99), kar vidimo v tabeli 24. Med njima (rangiranje KDU strokovne literature in raziskave) obstaja visoka statistično značilna povezanost (r = 0,745, P = 0,001). TABELA 24: Primerjava rangiranja KDU iz strokovne literature in ankete
Strokovna literatura Anketa Jasni cilji, strategija in obseg uvajanja rešitve 2 1 Vključitev in podpora uprave 1 2 Organizacija projektnega tima in njegove kompetence 3 3 Vključitev in sodelovanje uporabnikov 9 4 Komunikacija med projektnim timom in ostalimi v organizaciji 7-8* 5 Komunikacija znotraj projektnega tima 7-8* 6 Izobraževanje končnih uporabnikov 4 7 Prenova poslovnih procesov 5 8 Vključevanje zunanjih svetovalcev 11 9 Aktivna vloga sponzorja projekta 13 10 Prenos podatkov iz starih rešitev v rešitev ERP 10 11 Čim manj prilagajanja rešitve ERP posebnostim organizacije 15 12 Uporaba principov projektnega managementa 12 13 Management sprememb 6 14 Izbira tehnološke arhitekture rešitve ERP 14 15 * Ker je v večini strokovnih člankov komunikacija znotraj projektnega tima in komunikacija med projektnim timom in ostalimi v organizaciji združena, smo pri analizi KDU oba dejavnika označili kot en dejavnik. V tabeli 24 vidimo, da so tako v strokovni literaturi kot v raziskavi zelo pomembni naslednji KDU: jasni cilji, strategija in obseg uvajanja rešitve, vključitev in podpora uprave ter organizacija projektnega tima in njegove kompetence. So pa na visoko mesto (4 mesto) anketiranci vključili KDU vključitev in sodelovanje uporabnikov, medtem ko ga strokovna literatura uvršča v spodnji del tabele KDU (na 9 mesto). Največji razkorak med KDU v primerjavi tvori KDU management sprememb, ki ga strokovna literatura uvršča na 6 mesto po pomembnosti KDU, medtem ko ga raziskava uvršča na predzadnje mesto pomembnosti KDU (14 mesto). Ostalim KDU se sicer mesto pomembnosti spreminja glede na strokovno literaturo in raziskavo, vendar ostajajo v obeh primerih ali v zgornjem delu pomembnosti KDU-jev ali v spodnjem delu pomembnosti KDU (debelejša črta v tabeli). Glede na povprečno mesto - rang posameznih KDU glede na variiranje ranga med odgovori organizacij, lahko 15 KDU razvrstimo v 4 skupine, kot vidimo na sliki 40. Znotraj posamezne skupine ni značilnih razlik med rangi KDU. V posameznih skupinah so naslednji KDU:
1. skupina enakovrednih KDU, vrstni red glede na povprečno oceno: R1 - jasni cilji, strategija in obseg uvajanja rešitve.
2. skupina enakovrednih KDU, vrstni red glede na povprečno oceno: R2 - vključitev in podpora uprave, R4 - organizacija projektnega tima in njegove kompetence.
3. skupina enakovrednih KDU, vrstni red glede na povprečno oceno:
130
R9 - vključitev in sodelovanje uporabnikov, R6 - komunikacija med projektnim timom in ostalimi v organizaciji, R10 - izobraževanje končnih uporabnikov, R7 - komunikacija znotraj projektnega tima, R12 - prenova poslovnih procesov, R8 - vključevanje zunanjih svetovalcev, R3 - aktivna vloga sponzorja projekta, R15 - prenos podatkov iz starih rešitev v rešitev ERP.
4. skupina enakovrednih KDU, vrstni red glede na povprečno oceno: R5 - uporaba principov projektnega managementa, R11 - management sprememb, R13 - izbira tehnološke arhitekture rešitve ERP.
SLIKA 40: Grafična razvrstitev KDU glede na rang raziskave
0
2
4
6
8
10
12
14
16
R1 R2 R4 R9 R6 R10 R7 R12 R8 R3 R15 R14 R5 R11 R13
Inte
rval
zau
panj
a za
pov
preč
ne ra
nge
V vprašalniku smo dali anketirancem možnost, da so opredelili tudi druge za njih pomembne KDU. Kot KDU, za katere menijo anketiranci, da so še pomembni, so: razpoložljivost članov projektnega tima podjetja (delo poleg rednih obveznosti) (3), integracija z ostalimi rešitvami (2 odgovora), 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 ERP rešitvi in obratno, hitrost uvedbe. Kritične dejavnike uspeha uvedb rešitev ERP želimo sedaj analizirati še s treh vidikov, in sicer:
1. z vidika faz uvajanja, 2. z vidika metodologij uvajanja, 3. z vidika pristopa uvajanja.
V nadaljevanju poglavja imamo narejeno osnovno analizo raziskave KDU z vseh treh vidikov.
6.5.1 Analiza kritičnih dejavnikov uspeha z vidika faz uvajanja
Z vidika faz uvajanja so morali anketiranci označiti s številkami 1, 2, 3 ali 4 pomembnost KDU v posameznih fazah uvajanja, pri čemer 1 pomeni najmanj pomembno in 4 najbolj pomembno. Anketiranci so morali izpolniti tabelo, kar je storilo 48 vprašanih. Od teh 48
131
odgovorov je 6 anketirancev (12,5 %) pustilo vsa polja označena z 1. Ker je bila ena osnovna nastavitev v tabeli, menimo da niso izpolnili tabele in smo jih iz nadaljnje obdelave izpustili. Za ostale odgovore (42 odgovorov oziroma 87,5 %) smo izračunali aritmetične vrednosti KDU v posameznih fazah uvedbe, ki jih prikazujemo v tabeli 25. Ker so lahko vprašani v vsakem polju označili vrednosti 1, 2, 3 ali 4, je povprečna vrednost vsote teh vrednosti 2,5. Zato smo vsa polja v tabeli, pri katerih je aritmetična vrednost večja ali enaka 2,5, označili s sivim ozadjem. TABELA 25: Prikaz srednjih vrednosti (aritmetična sredina) KDU glede na faze uvajanja
Vsi Izbira rešitve ERP
Analiza poslovnih procesov
Konfiguriranje rešitve ERP
Testiranje rešitve ERP
Uvedba rešitve ERP
Stabilizacija delovanja
Jasni cilji, strategija in obseg uvajanja rešitve 3,36 3,10 3,05 2,62 2,81 2,64
Vključitev in podpora uprave 3,00 2,40 1,81 1,71 2,40 2,17 Organizacija projektnega tima in njegove kompetence 2,19 3,12 3,10 3,05 3,19 2,74
Vključitev in sodelovanje uporabnikov 1,95 2,52 2,19 3,00 2,88 2,81
Komunikacija med projektnim timom in ostalimi v organizaciji 2,21 3,14 2,55 2,86 2,93 2,83
Komunikacija znotraj projektnega tima 2,33 3,24 2,98 2,95 3,02 2,88
Izobraževanje končnih uporabnikov 1,79 2,10 2,31 2,83 2,83 2,86
Prenova poslovnih procesov 2,38 2,90 2,50 2,36 2,50 2,29 Vključevanje zunanjih svetovalcev 2,21 2,55 2,88 2,40 2,62 2,14
Aktivna vloga sponzorja projekta 2,45 2,21 1,81 1,86 2,17 1,98
Prenos podatkov iz starih rešitev v rešitev ERP 1,93 2,02 2,36 2,60 2,60 1,93
Čim manj prilagajanja rešitve ERP posebnostim organizacije 2,40 2,60 2,57 2,19 2,19 2,00
Uporaba principov projektnega managementa 2,12 2,57 2,31 2,40 2,55 2,02
Management sprememb 1,71 2,02 2,07 2,24 2,24 2,45 Izbira tehnološke arhitekture rešitve ERP 2,29 1,86 2,10 1,93 1,79 1,90
Opomba: KDU so v tabeli razvrščeni po pomembnosti glede na raziskavo (rang)49. Iz tabele lahko tako razberemo, da KDU: aktivna vloga sponzorja projekta, management sprememb in izbira tehnološke arhitekture za rešitev ERP za vprašane niso pomembni v nobeni fazi uvajanja. Po drugi strani pa se dejavnik jasni cilji, strategija in obseg uvajanja rešitve pojavlja kot kritični dejavnik v vseh fazah uvajanja. V vseh fazah uvajanja razen v fazi Izbira rešitve ERP se pojavijo kot KDU tudi: organizacija projektnega tima in njegove kompetence, komunikacija znotraj projektnega tima ter komunikacija med projektnim timom in ostalimi v organizaciji. V nadaljevanju poglavja bomo našteli pomembnejše KDU raziskave glede na fazo uvedbe. V fazi Izbira rešitve ERP se pojavita samo dva pomembnejša KDU:
1. jasni cilji, strategija in obseg uvajanja rešitve (Mx = 3,36)50 in 2. vključitev in podpora uprave (Mx = 3,00).
49 Tabelarični prikaz variance, modusa, standardnega odklona KDU ter prikaz KDU glede na faze uvajanja za rešitev Navision in SAP se nahajajo v prilogi F na strani 165. 50 Mx je vzorčna aritmetična sredina.
132
V fazi Analiza poslovni procesov je med pomembnejšimi KDU 8 dejavnikov, in sicer: 1. komunikacija znotraj projektnega tima (Mx = 3,24), 2. komunikacija med projektnim timom in ostalimi v organizaciji (Mx = 3,14), 3. organizacija projektnega tima in njegove kompetence (Mx = 3,10), 4. prenova poslovnih procesov (Mx = 2,9), 5. čim manj prilagajanja rešitve ERP posebnostim organizacije (Mx = 2,6), 6. uporaba principov projektnega managementa (Mx = 2,57), 7. vključevanje zunanjih svetovalcev (Mx = 2,55) in 8. vključitev in sodelovanje končnih uporabnikov (Mx = 2,52).
V fazi Konfiguriranje rešitve ERP je 7 pomembnejših KDU:
1. organizacija projektnega tima (Mx = 3,10), 2. jasni cilji, strategija in obseg uvajanja rešitve ERP (Mx = 3,05), 3. komunikacija znotraj projektnega tima(Mx = 2,98), 4. vključevanje zunanjih svetovalcev (Mx = 2,88), 5. čim manj prilagajanja rešitve ERP posebnostim organizacije (Mx = 2,57), 6. komunikacija med projektnim timom in ostalimi v organizaciji (Mx = 2,55) in 7. prenova poslovnih procesov (Mx = 2,5).
V fazi Testiranje rešitve ERP so pomembnejši naslednji KDU:
1. organizacija projektnega tima in njegove kompetence (Mx = 3,05), 2. vključitev in sodelovanje uporabnikov (Mx = 3,00), 3. komunikacija znotraj projektnega tima (Mx = 2,95), 4. komunikacija med projektnim timom in ostalimi v organizaciji (Mx = 2,86), 5. izobraževanje končnih uporabnikov (Mx = 2,83), 6. jasni cilji, strategija in obseg uvajanja rešitve (Mx = 2,62) in 7. prenos podatkov iz starih rešitev v rešitev ERP (Mx = 2,60).
V fazi Uvedba rešitve ERP je po rezultatih raziskave največ KDU in sicer 10, ki so sledeči:
1. organizacija projektnega tima in njegove kompetence (Mx = 3,19), 2. komunikacija znotraj projektnega tima (Mx = 3,02), 3. komunikacija med projektnim timom in ostalimi v organizaciji (Mx = 2,93), 4. vključitev in sodelovanje uporabnikov (Mx = 2,88), 5. izobraževanje končnih uporabnikov (Mx = 2,83), 6. jasni cilji, strategija in obseg uvajanja rešitve (Mx = 2,81), 7. vključevanje zunanjih svetovalcev (Mx = 2,62), 8. prenos podatkov iz starih rešitev v rešitev ERP (Mx = 2,60), 1 9. uporaba principov PM (Mx = 2,55) in 10. prenova poslovnih procesov (Mx = 2,50).
V fazi Stabilizacija delovanja se pojavlja 6 pomembnejših KDU:
1. komunikacija znotraj projektnega tima (Mx = 2,88), 2. izobraževanje končnih uporabnikov (Mx = 2,86), 3. komunikacija med projektnim timom in ostalimi v organizaciji (Mx = 2, 83), 4. vključitev in sodelovanje uporabnikov (Mx = 2,81), 5. organizacija projektnega tima (Mx = 2,74) in 6. jasni cilji, strategija in obseg uvajanja rešitve (Mx = 2,64).
Če KDU z vidika faz uvajanja primerjamo z rangi KDU raziskave, potem vidimo, da se pomembnejši KDU glede na rang pojavljajo tudi kot pomembnejši KDU z vidika faz, kar
133
lahko opazimo iz tabele zgoraj. Poleg tega vidimo tudi, da najmanj pomembna KDU glede na rang, to sta management sprememb (rang 14) in izbira tehnološke opreme (rang 15), nista pomembna niti glede na KDU z vidika faz. Če pogledamo samo tiste KDU v posameznih fazah, ki so pomembnejši (sivo ozadje v tabeli zgoraj) vidimo, da pri nekaterih pomembnost skozi faze pada, pri nekaterih raste oziroma niha. Tako vidimo, da aritmetična sredina KDU jasni cilji, strategija in obseg uvajanja rešitve glede na faze pada (razen v fazi uvedbe), iz česar lahko sklepamo, da je zelo pomembno, da dobro definiramo jasne cilje, strategijo in obseg uvajanja rešitve ERP na začetku projekta uvajanja rešitve ERP. Prav tako pada KDU organizacija projektnega tima in njegove kompetence (razen v fazi uvedbe), iz česar lahko tudi sklepamo, da je pomembno v začetnih fazah uvedbe rešitev ERP izbrati in organizirati primeren projektni tim ter mu jasno določiti njegove kompetence. Predvsem je dobra organizacija projektnega tima in dobro definirane kompetence pomembne v fazi analiza poslovnih procesov in pa v fazi uvedba rešitve ERP. Z organizacijo projektnega tima predvidevamo, da je povezan tudi KDU komunikacija znotraj projektnega tima, kjer je glede na faze prav tako najpomembnejša v fazi analize poslovnih procesov in fazi uvedbe rešitve ERP. Na osnovi dobljenih podatkov želimo preveriti, ali se pomembnost KDU z vidika faz razlikuje med našim raziskovalnim modelom (glej tabela 15 na strani 112) in raziskavo, ki jih prikazujemo v tabeli 26. TABELA 26: Prikaz primerjave pomembnosti KDU z vidika faz glede na strokovno literaturo in raziskavo
I. FAZA 2. FAZA 3. FAZA 4. FAZA 5. FAZA 6. FAZA
T R T R T R T R T R T R
Jasni cilji, strategija in obseg uvajanja rešitve X X X X X X X X X X X X
Vključitev in podpora uprave X X X X X X X
Aktivna vloga sponzorja projekta X X X X
Organizacija projektnega tima in njegove kompetence X X X X X X X X X
Uporaba principov projektnega managementa X X X X X X
Komunikacija znotraj projektnega tima X X X X X X X X
Komunikacija med projektnim timom in ostalimi v organizaciji X X X X X X X X X
Vključevanje zunanjih svetovalcev X X X X X
Vključitev in sodelovanje uporabnikov X X X X X X X
Izobraževanje končnih uporabnikov X X X X X
Management sprememb X X X X X X
Prenova poslovnih procesov X X X X X
Izbira tehnološke arhitekture rešitve ERP X
Čim manj prilagajanja rešitve ERP posebnostim organizacije X X X X
Prenos podatkov iz starih rešitev v rešitev ERP X X X X
T – raziskovalni model na osnovi strokovne literature; R - raziskava
134
S tabele vidimo, da večina KDU glede na faze podobno tako v strokovni literaturi kot v raziskavi. Glede na raziskavo KDU z vidika faz vidimo, da KDU aktivna vloga sponzorja, management sprememb in izbira tehnološke arhitekture rešitve ERP ni pomembna, se pa pojavlja kot dokaj pomemben dejavnik v strokovni literaturi. Kot pomemben KDU skozi vse faze uvedbe rešitve ERP je bil opredeljen tudi KDU vključitev in podpora uprave, ki pa ji raziskava ne potrjuje takšne pomembnosti razen v fazi izbira rešitve ERP. Daje pa raziskava večjo pomembnost KDU kot strokovna literatura v fazi stabilizacije naslednjim KDU: organizaciji projektnega tima in njegovim kompetencam, komunikaciji znotraj projektnega tima, komunikaciji med projektnim timom in ostalimi v organizaciji ter vključevanju in sodelovanju uporabnikov.
6.5.2 Analiza kritičnih dejavnikov uspeha z vidika metodologij uvajanja
Analizo KDU z vidika metodologij uvajanja smo dobili tako, da smo pri obdelavi KDU upoštevali samo odgovor »Po metodi ponudnika« devetega vprašanja. Dobili smo 34 odgovorov oziroma 70,8 % od vseh odgovorov (glej tudi tabelo 18 na strani 123). Zanimalo nas je, ali metodologija vpliva na pomembnost KDU. Od 34 odgovorov je range ocenilo 23 vprašanih, kjer smo s pomočjo aritmetične sredine dobili, kateri KDU je za vprašane najpomembnejši (tabelo 43 s priloge G na strani 166). Rezultat obdelave je sledeč:
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 ostalimi 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 ), 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 managementa (MX = 10,2 ), 14. management sprememb (MX = 11,4 ), 15. izbira tehnološke arhitekture rešitve ERP (MX = 12,4 ).
Če primerjamo dobljeni rezultat s celotnim rezultatom ankete (poglavje Analiza kritičnih dejavnikov uspeha na str. 128), vidimo, da metodologija uvajanja rešitve ERP na splošno ne spremeni pomembnosti posameznih KDU. Zamenjal se je le vrstni red KDU komunikacija znotraj projektnega tima in izobraževanje končnih uporabnikov, ostali KDU so po pomembnosti ostali na istih mestih. Preverili smo, ali obstaja korelacija med posameznimi KDU, ki so uvedli rešitev ERP po metodi ponudnika. V tabeli 27 vidimo, da obstaja med nekaterimi KDU visoka pozitivna korelacija, zmerna pozitivna korelacija, kot tudi zmerna negativna korelacija.
135
TABELA 27: Korelacijska tabela KDU glede na rang, ki so uvedli rešitev ERP po metodi ponudnika
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R1 1 ,843(**) ,352 ,706(**) ,338 ,260 ,186 -,056 -,223 -,143 ,436(*) -,158 -,151 -,380 -,273R2 ,843(**) 1 ,478(*) ,631(**) ,435(*) ,015 ,029 -,081 -,331 -,262 ,449(*) -,306 -,326 -,176 -,396R3 ,352 ,478(*) 1 ,344 ,416 -,220 -,292 -,107 -,229 -,262 ,262 -,183 -,247 ,104 -,425R4 ,706(**) ,631(**) ,344 1 ,426(*) ,570(**) ,340 -,273 -,215 -,426(*) ,387 -,054 -,429 -,145 -,477(*)R5 ,338 ,435(*) ,416 ,426(*) 1 ,083 -,007 -,045 -,276 -,491(*) ,092 -,278 -,192 -,178 -,304R6 ,260 ,015 -,220 ,570(**) ,083 1 ,616(**) -,188 ,124 -,344 ,111 ,227 ,106 -,448(*) -,112R7 ,186 ,029 -,292 ,340 -,007 ,616(**) 1 -,234 ,077 -,262 ,061 ,088 ,163 -,088 -,082R8 -,056 -,081 -,107 -,273 -,045 -,188 -,234 1 ,122 -,101 -,227 ,149 ,350 ,025 ,126R9 -,223 -,331 -,229 -,215 -,276 ,124 ,077 ,122 1 ,251 -,403 ,077 ,576(**) -,243 ,235R10 -,143 -,262 -,262 -,426(*) -,491(*) -,344 -,262 -,101 ,251 1 ,016 ,104 ,139 -,069 ,443(*)R11 ,436(*) ,449(*) ,262 ,387 ,092 ,111 ,061 -,227 -,403 ,016 1 ,183 -,083 ,016 -,213R12 -,158 -,306 -,183 -,054 -,278 ,227 ,088 ,149 ,077 ,104 ,183 1 ,195 ,243 ,431(*)R13 -,151 -,326 -,247 -,429 -,192 ,106 ,163 ,350 ,576(**) ,139 -,083 ,195 1 -,106 ,192R14 -,380 -,176 ,104 -,145 -,178 -,448(*) -,088 ,025 -,243 -,069 ,016 ,243 -,106 1 ,124R15 -,273 -,396 -,425 -,477(*) -,304 -,112 -,082 ,126 ,235 ,443(*) -,213 ,431(*) ,192 ,124 1
** Correlation is significant at the 0.01 level (2-tailed). – Pearsonova korelacija * Correlation is significant at the 0.05 level (2-tailed). – 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 managementa R6 - Komunikacija znotraj projektnega tima R7 - Komunikacija med projektnim timom in ostalimi v organizaciji R8 - Vključevanje zunanjih svetovalcev
R9 - Vključitev in sodelovanje uporabnikov R10 - Izobraževanje končnih uporabnikov R11 - Management 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
136
Visoka pozitivna korelacija na 1 % nivoju obstaja med: • med jasnimi cilji, strategijo in obsegom uvajanja rešitve ter vključevanjem in podporo
uprave (r = 0,843) in • med jasnimi cilji, strategijo in obsegom uvajanja rešitev ter organizacijo projektnega
tima in njegovimi kompetencami (r = 0,706). Zmerna pozitivna korelacija na 1 % nivoju obstaja med:
• vključitvijo in podporo uprave ter organizacijo projektnega tima in njegovimi kompetencami (r = 0,631),
• komunikacijo znotraj projektnega tima ter komunikacija med projektnim timom in ostalimi v organizaciji (r = 0,616),
• vključitev in sodelovanje uporabnikov ter izbira tehnološke arhitekture rešitve ERP (r = 0,576) in
• organizacijo projektnega tima in njegovimi kompetencami ter komunikacijo znotraj projektnega tima (r = 0,57).
Zmerna pozitivna korelacija na 5 % nivoju obstaja med:
• vključitvijo in podporo uprave ter aktivno vlogo sponzorja projekta (r = 0,478), • vključitvijo in podporo uprave ter managementom sprememb (r = 0,449), • izobraževanjem končnih uporabnikov ter prenos podatkov iz starih rešitev v rešitev
ERP (r = 0,443), • jasnimi cilji, strategijo in obsegom uvajanja rešitve ter managementom sprememb (r =
0,436), • vključitvijo in podporo uprave ter uporabo principov projektnega managementa (r =
0,435), • prenova poslovnih procesov ter prenos podatkov iz starih rešitev v rešitev ERP (r =
0,431) in • organizacijo projektnega tima in njegove kompetence ter uporaba principov
projektnega managementa (r = 0,426). Obstaja tudi zmerna negativna korelacija na 5 % nivoju in sicer med:
• uporabo principov projektnega managementa ter izobraževanjem končnih uporabnikov (r = -0,491),
• organizacijo projektnega tima in njegovimi kompetencami ter prenosom podatkov iz starih rešitev v rešitev ERP (r = -0,477),
• komunikacija znotraj projektnega tima ter čim manj prilagajanja rešitve ERP posebnostim organizacije (r = -0,448) in
• organizacijo projektnega tima in njegovimi kompetencami ter izobraževanjem končnih uporabnikov (r = -0,426).
Nadalje smo želeli primerjati rangiranje posameznih metodologij. Od 23 odgovorov se 11 odgovorov nanaša na rešitev Navision, ki se uvaja po metodi On Target, 10 odgovorov za rešitev SAP, ki se uvaja po metodi ASAP in 2 odgovora rešitve GEAC. Rezultate rangiranja KDU glede na posamezne metodologije uvajanja vidimo v tabeli 28. Ker je samo 5 uvedb rešitev GEAC System 21 v Sloveniji, od katerih smo dobili rezultate iz treh organizacij, jih v podrobnejšo analizo KDU z vidika posameznih metodologij nismo zajeli.
137
TABELA 28: Prikaz rangiranja posameznih KDU glede na rešitve GEAC, Navision in SAP
Rešitev GEAC Rešitev Navision Rešitev SAP
MXG RangG MXN Rangn MXS Rangs
Jasni cilji, strategija in obseg uvajanja rešitve 6,5 6 3,45 1 1,7 1 Vključitev in podpora uprave 9,5 12 5,64 2 3,4 2 Aktivna vloga sponzorja projekta 14,5 15 9,4 10 7,2 4 Organizacija projektnega tima in njegove kompetence 8 9 6,18 3 4 3
Uporaba principov projektnega managementa 11,5 13 10,7 13 9,33 12 Komunikacija znotraj projektnega tima 5,5 3 7,55 6 8,22 8 Komunikacija med projektnim timom in ostalimi v organizaciji 5,5 4 8,73 9 7,3 5
Vključevanje zunanjih svetovalcev 4,5 2 10,1 12 8 7 Vključitev in sodelovanje uporabnikov 3,5 1 6,82 4 7,44 6 Izobraževanje končnih uporabnikov 7,5 7 7,09 5 8,78 10 Management sprememb 13,5 14 11,2 14 11,1 14 Prenova poslovnih procesov 8 10 8,27 7 8,33 9 Izbira tehnološke arhitekture rešitve ERP 6 5 12,8 15 13,3 15 Čim manj prilagajanja rešitve ERP posebnostim organizacije 8,5 11 9,8 11 8,8 11
Prenos podatkov iz starih rešitev v rešitev ERP 7,5 8 8,64 8 9,89 13 MXG, MXN, MXS – aritmetične sredine za posamezne rešitve Rešitev MS Navision uvajajo partnerska podjetja podjetja Microsoft po metodologiji On Target. Iz zgornje tabele vidimo, da glede na metodologijo uvajanja On Target je pomembnost KDU sledeča:
1. jasni cilji, strategija in obseg uvajanja rešitve, 2. vključitev in podpora uprave, 3. organizacija projektnega tima in njegove kompetence, 4. vključitev in sodelovanje uporabnikov, 5. izobraževanje končnih uporabnikov, 6. komunikacija znotraj projektnega tima , 7. prenova poslovnih procesov, 8. prenos podatkov iz starih rešitev v rešitev ERP, 9. komunikacija med projektnim timom in ostalimi v organizaciji, 10. aktivna vloga sponzorja projekta, 11. čim manj prilagajanja rešitve ERP posebnostim organizacije, 12. vključevanje zunanjih svetovalcev, 13. uporaba principov projektnega managementa, 14. management sprememb, 15. izbira tehnološke arhitekture rešitve ERP.
Rešitev mySAP ERP uvaja podjetje SAP in njegova partnerska podjetja po metodologiji ASAP. Iz zgornje tabele vidimo, da so glede na metodologijo ASAP najpomembnejši KDU sledeči:
1. jasni cilji, strategija in obseg uvajanja rešitve, 2. vključitev in podpora uprave, 3. organizacija projektnega tima in njegove kompetence, 4. aktivna vloga sponzorja projekta, 5. komunikacija med projektnim timom in ostalimi v organizaciji, 6. vključitev in sodelovanje uporabnikov, 7. vključevanje zunanjih svetovalcev,
138
8. komunikacija znotraj projektnega tima, 9. prenova poslovnih procesov, 10. izobraževanje končnih uporabnikov, 11. čim manj prilagajanja rešitve ERP posebnostim organizacije, 12. uporaba principov projektnega managementa, 13. prenos podatkov iz starih rešitev v rešitev ERP, 14. management sprememb, 15. izbira tehnološke arhitekture rešitve ERP.
Iz tabele 26 vidimo, da so v obeh metodologijah 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 razliko v rangiranju doseže KDU aktivna vloga sponzorja projekta. Pri metodologiji ASAP rešitve SAP je ta KDU na četrtem mestu, medtem ko je pri metodologiji On Target rešitve Navision na desetem mestu. Ta razlika je verjetno odraz tega, da rešitev Navision uvajajo majhne in srednje velike organizacije (v vključenih odgovorih 6 –majhnih organizacij ter 5 srednjevelikih in velikih organizacij), medtem ko rešitev SAP uvajajo srednjevelike in velike organizacije (vse organizacije, ki so bile vključene v raziskavo so srednjevelike oz. velike organizacije). Tako predvidevamo, da v majhnih podjetjih direktor (uprava) prevzame vlogo sponzorja projekta in zaradi tega ni tako pomemben KDU rešitve Navision. Večje razlike med rangi obeh metodologij se pojavijo še pri KDU: izobraževanje končnih uporabnikov (5 mesto Navision, 10 mesto SAP), vključevanje zunanjih svetovalcev (12 mesto Navision, 7 mesto SAP), komunikacija med projektnim timom in ostalimi v organizaciji (9 mesto Navision, 5 mesto SAP), prenos podatkov iz starih rešitev v rešitev ERP (8 mesto Navision, 13 mesto SAP). Zanimivo je tudi sledeče, da pri rešitvi 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 vključitev in sodelovanje uporabnikov pojavi na 6 mestu, izobraževanje končnih uporabnikov pa šele na 10 mestu. Iz podatkov smo želeli preveriti, ali obstaja korelacija med metodologijo ponudnika oziroma lastno metodologijo in časom uvedbe. Statistična obdelava nam ni pokazala signifikantne korelacije. Za konec tega poglavja nas je še zanimalo, ali obstajajo razlike v pomembnosti KDU (rang), če smo uvedli rešitev po metodologiji ponudnika, oziroma če smo jo uvedli po lastni metodologiji. Range obeh metod nam prikazuje tabela 29. S tabele vidimo, da je najpomembnejši KDU v obeh primerih jasni cilji, strategija in obseg uvajanja rešitve. Se pa pojavi velika razlika v pomembnosti KDU vključitev in podpora uprave, ki je šele na 11 mestu pomembnosti KDU če uvajamo rešitev po lastni metodi, če pa uvajamo rešitev po metodi ponudnika pa je na 2 mestu. Malo manjši, pa kljub temu velik razkorak v pomembnosti je tudi v KDU izbira tehnološke arhitekture. Pri uvedbi po lastni metodi je izbira tehnološke arhitekture srednje pomembna (na 10 mestu), medtem ko je pri metodi ponudnika le ta nepomembna (na 15 mestu). Iz rangiranja po lastni metodi lahko sklepamo, da želijo organizacije v tem primeru prilagoditi rešitev ERP svojim poslovnim procesom in da smatrajo projekt uvedbe kot projekt IT.
139
TABELA 29: Prikaz pomembnosti KDU glede na uvedbo rešitev ERP po metodologiji ponudnika oziroma po lastni metodologiji
Po metodi ponudnika Po lastni metodi Jasni cilji, strategija in obseg uvajanja rešitve 1 1 Vključitev in podpora uprave 2 11 Aktivna vloga sponzorja projekta 10 13 Organizacija projektnega tima in njegove kompetence 3 5 Uporaba principov projektnega managementa 13 15 Komunikacija znotraj projektnega tima 5 6 Komunikacija med projektnim timom in ostalimi v organizaciji 7 4 Vključevanje zunanjih svetovalcev 9 12 Vključitev in sodelovanje uporabnikov 4 2 Izobraževanje končnih uporabnikov 6 3 Management sprememb 14 14 Prenova poslovnih procesov 8 7 Izbira tehnološke arhitekture rešitve ERP 15 10 Čim manj prilagajanja rešitve ERP posebnostim organizacije 12 9 Prenos podatkov iz starih rešitev v rešitev ERP 11 8
* Razvrstitev KDU na range po lastni metodi ponudnika je prikazana v prilogi H na strani 167
6.5.3 Analiza kritičnih dejavnikov uspeha z vidika pristopa uvajanja
Rešitve ERP lahko uvajamo po več pristopih, in sicer: pristopu big bang, faznem pristopu, vzporednem pristopu, procesnem pristopu oziroma kombinacij predhodno omenjenih pristopov51. V naši raziskavi je na vprašanje o vrsti pristopa uvedbe odgovorilo 32 anketirancev (66,67 %). Od tega jih je 15 uvedlo rešitev ERP po pristopu big bang, 3 po faznem pristopu, 5 po vzporednem pristopu, 3 po procesnem pristopu in 6 po kombinacij pristopov (graf 11). GRAF 11: Odstotkovni prikaz pristopov uvajanja
Big bang47 %
Fazni pristop9 %
Vzporedni pristop16 %
Procesni pristop9 %
Kombinacija pristopov19 %
Ker so vzorci manjši od 30 enot, ne moremo narediti podrobnejše statistične obdelave, kljub temu pa lahko s tabele 28 razberemo, da je v vseh pristopih najpomembnejši KDU jasni cilji, strategija in obseg uvajanja, sicer pa je pomembnost KDU glede na posamezne pristope zelo različna.
51 Posamezni pristopi so podrobneje razloženi v poglavju »Pristopi k uvajanju celovitih informacijskih rešitev« na strani 77.
140
TABELA 30: Prikazuje range KDU glede na posamezne pristope uvedbe rešitve ERP
Big bang Fazni pristop Vzporedni pristop
Procesni pristop
Kombinacija vseh
MX1 RX1 MX2 RX2 MX3 RX3 MX4 RX4 MX5 RX5 Jasni cilji, strategija in obseg uvajanja rešitve 3,13 1 2,00 1 1,60 1 1,33 1 3,67 1
Vključitev in podpora uprave 5,53 3 6,33 7 4,40 2 5,67 4 6,67 5 Aktivna vloga sponzorja projekta 8,43 8 14,67 15 8,40 11 8,67 10 7,33 8 Organizacija projektnega tima in njegove kompetence 4,93 2 4,67 2 7,40 5 8,67 9 5,83 3
Uporaba principov projektnega managementa 9,79 12 12,33 13 11,00 14 9,33 12 8,17 11
Komunikacija znotraj projektnega tima 6,86 5 8,00 9 8,40 9 12,33 13 6,00 4 Komunikacija med projektnim timom in ostalimi v organizaciji 7,53 6 5,67 5 7,40 6 7,33 7 7,33 7
Vključevanje zunanjih svetovalcev 7,62 7 6,33 8 11,00 12 9,33 11 8,83 12 Vključitev in sodelovanje uporabnikov 6,29 4 6,00 6 6,60 4 6,67 6 6,67 6 Izobraževanje končnih uporabnikov 8,43 9 5,00 3 6,60 3 8,67 8 7,83 9 Management sprememb 11,86 14 13,00 14 11,80 15 5,00 3 9,00 13 Prenova poslovnih procesov 8,93 10 10,67 11 7,80 7 3,67 2 5,50 2 Izbira tehnološke arhitekture rešitve ERP 12,31 15 10,67 12 11,00 13 13,33 14 10,33 15
Čim manj prilagajanja rešitve ERP posebnostim organizacije 9,57 11 9,33 10 8,40 10 6,33 5 10,33 14
Prenos podatkov iz starih rešitev v rešitev ERP 9,86 13 5,33 4 8,20 8 13,67 15 7,83 10
MX=povprečje rangov, MX1=povprečje rangov za pristop big bang, MX2=povprečje rangov, MX3=povprečje rangov za fazni pristop, M4=povprečje rangov, MX5=povprečje rangov za vzporedni pristop; Pri pristopu Big bang, kjer zaženemo vse module v živo na isti dan, je pomembnost KDU sledeča (1 – najpomembnejši, 15 – najmanj pomemben):
1. jasni cilji, strategija in obseg uvajanja rešitve, 2. organizacija projektnega tima in njegove kompetence, 3. vključitev in podpora uprave, 4. vključitev in sodelovanje uporabnikov, 5. komunikacija znotraj projektnega tima, 6. komunikacija med projektnim timom in ostalimi v organizaciji, 7. vključevanje zunanjih svetovalcev, 8. aktivna vloga sponzorja projekta, 9. izobraževanje končnih uporabnikov, 10. prenova poslovnih procesov, 11. čim manj prilagajanja rešitve ERP posebnostim organizacije, 12. uporaba principov projektnega managementa, 13. prenos podatkov iz starih rešitev v rešitev ERP, 14. management sprememb, 15. izbira tehnološke arhitekture rešitve ERP.
Pri faznem pristopu uvajamo module zaporedno, pri čemer smatrajo anketiranci, da je pomembnost KDU sledeča:
1. jasni cilji, strategija in obseg uvajanja rešitve, 2. organizacija projektnega tima in njegove kompetence, 3. izobraževanje končnih uporabnikov, 4. prenos podatkov iz starih rešitev v rešitev ERP, 5. komunikacija med projektnim timom in ostalimi v organizaciji, 6. vključitev in sodelovanje uporabnikov,
141
7. vključitev in podpora uprave, 8. vključevanje zunanjih svetovalcev, 9. komunikacija znotraj projektnega tima , 10. čim manj prilagajanja rešitve ERP posebnostim organizacije, 11. prenova poslovnih procesov, 12. izbira tehnološke arhitekture rešitve ERP, 13. uporaba principov projektnega managementa, 14. management sprememb, 15. aktivna vloga sponzorja projekta.
Za vzporedni pristop je značilno, da nekaj časa tečeta sočasno obstoječi IS in uvedena rešitev ERP. Anketiranci, ki so uvedli rešitev po tem pristopu, so opredelili pomembnost KDU sledeče:
1. jasni cilji, strategija in obseg uvajanja rešitve, 2. vključitev in podpora uprave, 3. izobraževanje končnih uporabnikov, 4. vključitev in sodelovanje uporabnikov, 5. organizacija projektnega tima in njegove kompetence, 6. komunikacija med projektnim timom in ostalimi v organizaciji, 7. prenova poslovnih procesov, 8. prenos podatkov iz starih rešitev v rešitev ERP, 9. komunikacija znotraj projektnega tima, 10. čim manj prilagajanja rešitve ERP posebnostim organizacije, 11. aktivna vloga sponzorja projekta, 12. vključevanje zunanjih svetovalcev, 13. izbira tehnološke arhitekture rešitve ERP, 14. uporaba principov projektnega managementa, 15. management sprememb.
Kadar uvedemo rešitev ERP najprej za en poslovni proces in nato še za druge poslovne procese, govorimo o procesnem pristopu uvajanja rešitve ERP. Najpomembnejši KDU glede na procesni pristop so:
1. jasni cilji, strategija in obseg uvajanja rešitve, 2. prenova poslovnih procesov, 3. management sprememb, 4. vključitev in podpora uprave, 5. čim manj prilagajanja rešitve ERP posebnostim organizacije, 6. vključitev in sodelovanje uporabnikov, 7. komunikacija med projektnim timom in ostalimi v organizaciji, 8. izobraževanje končnih uporabnikov, 9. organizacija projektnega tima in njegove kompetence, 10. aktivna vloga sponzorja projekta, 11. vključevanje zunanjih svetovalcev, 12. uporaba principov projektnega managementa, 13. komunikacija znotraj projektnega tima, 14. izbira tehnološke arhitekture rešitve ERP, 15. prenos podatkov iz starih rešitev v rešitev ERP.
142
Če se organizacija odloči, da bo npr. neke module najprej uvedla po enem izmed zgornjih pristopov in nato nadaljuje z uvajanjem modulov rešitve ERP po drugem pristopu, govorimo o kombiniranem pristopu. Pomembnost KDU glede na ta pristop je sledeča:
1. jasni cilji, strategija in obseg uvajanja rešitve, 2. prenova poslovnih procesov, 3. organizacija projektnega tima in njegove kompetence, 4. komunikacija znotraj projektnega tima, 5. vključitev in podpora uprave, 6. vključitev in sodelovanje uporabnikov, 7. komunikacija med projektnim timom in ostalimi v organizaciji, 8. aktivna vloga sponzorja projekta, 9. izobraževanje končnih uporabnikov, 10. prenos podatkov iz starih rešitev v rešitev ERP, 11. uporaba principov projektnega managementa, 12. vključevanje zunanjih svetovalcev, 13. management sprememb, 14. čim manj prilagajanja rešitve ERP posebnostim organizacije, 15. izbira tehnološke arhitekture rešitve ERP.
Iz tabele vidimo, da razen KDU jasni cilji, strategija in obseg uvajanja nikjer v celoti ne sovpadajo KDU glede na pristop. Vidimo, da so pri nekaterih pristopih pomembni eni KDU, ki so za druge pristope nepomembni, kot npr. prenova poslovnih procesov, kjer zaseda drugo mesto po pomembnosti pri procesnem pristopu in kombiniranem pristopu ter šele deseto mesto pri pristopu big bang in enajsto mesto pri faznem pristopu. Podobno velja za KDU komunikacija znotraj projektnega tima, ki je razvrščen na 5 mesto po pomembnosti glede na pristop Big bang, medtem ko je pri faznem in vzporednem pristopu na 9 mestu, pri procesnem pa celo na 13 mestu. Vidimo tudi, da je KDU management sprememb med pomembnejšimi KDU v procesnem pristopu, medtem ko se pri ostalih pristopih uvršča proti koncu pomembnosti.
143
7 SKLEP
V nalogi smo najprej definirali pojem ERP, predstavili zgodovino razvoja celovitih informacijskih rešitev, koncept in zgradbo rešitev ERP, življenjski cikel rešitev ERP in opredelili usmerjenost rešitev ERP. Ugotovili smo, katere rešitev ERP so trenutno dostopne na trgu in za katere se organizacije najpogosteje odločajo. Predstavili smo smernice nadaljnjega razvoja rešitev ERP. Nato smo predstavili potek uvajanja rešitev ERP, strategijo uvajanja rešitev ERP in projektno organizacijo, ki je potrebna za uspešno uvedbo rešitev ERP. V okviru izbire in nakupa rešitve ERP, smo opredelili razloge za posodobitev in prenovo IS, analizo poslovnih procesov, pristope k izbiri rešitve ERP in ocenitev ter management nakupa rešitev ERP. Pripravili smo metriko za ocenjevanje kakovosti rešitve ERP v uporabi s strani končnega uporabnika za izbiro najprimernejše rešitve ERP v organizaciji. Metrika je splošna in jo je potrebno prilagoditi posebnostim posamezne organizacije. V okviru metod uvajanja rešitev ERP smo predstavili pristope k uvajanju rešitev ERP in podrobneje opisali metodologiji ASAP podjetja SAP in On Target podjetja Microsoft, ki se uporabljata pri uvajanju rešitev ERP. Nadalje smo naredili primerjalno analizo med zgoraj omenjenima metodologijama. V osrednjem delu naloge smo se poglobili v kritične dejavnike uspeha (KDU) uvajanja rešitev ERP. Na osnovi strokovne literature smo izdelali raziskovalni model KDU z vidika faz uvajanja in raziskovalni model KDU z vidika metodologij uvajanja. V raziskavi smo zajeli slovenske organizacije, ki so uvedle rešitev mySAP ERP (oziroma SAP R/3), MS Navision in System 21. Na osnovi dobljenih rezultatov smo izdelali analizo KDU glede na pomembnost posameznih KDU. Analiza raziskave nam je razkrila, da je za slovenske organizacije najpomembnejši KDU pri uvajanju rešitev ERP »jasni cilji, strategija in obseg uvajanja« ter da med nekaterimi KDU obstaja pozitivna korelacija. V raziskavi smo ugotovili, da so tako v raziskavi kot v strokovni literaturi enako pomembni isti KDU. Z vidika faz uvajanja KDU smo potrdili naš raziskovalni model, da vsi KDU niso enako pomembni v vseh fazah uvedbe, pač pa so nekateri bolj pomembni v začetnih fazah, nekateri pa v nadaljevanju. Rezultati analize KDU z vidika metodologij uvajanja se ne razlikujejo od pomembnosti posameznih KDU. Zamenjal se je le vrstni red KDU »komunikacija znotraj projektnega tima« in »izobraževanje končnih uporabnikov«. Ostali KDU so po pomembnosti ostali na istih mestih. Prav tako smo z te analize razbrali, da obstaja statistično pomembna pozitivna in negativna korelacija med posameznimi KDU, v primeru, da smo uvedli rešitev ERP po metodi ponudnika. Iz analize KDU z vidika pristopa uvajanja ugotovimo, da je v vseh pristopih uvajanja najpomembnejši KDU »jasni cilji, strategija in obseg uvajanja«, sicer pa se pomembnost KDU glede na posamezne pristope zelo razlikuje. V nadaljevanju raziskave želimo preveriti uporabnost metrike za ocenitev kakovosti rešitve ERP s strani končnega uporabnika na konkretnih primerih. Prav tako pa želimo nadaljevati raziskavo KDU, tako da bomo izdelali podrobnejšo analizo rezultatov s pomočjo zahtevnejših statističnih testov. Nato pa bo sledilo še zbiranje, obdelava in analiza podatkov s pomočjo študije primerov izbranih slovenskih organizacij, ki so uvedle rešitev ERP.
144
LITERATURA
1. Aduri, R., Lin, W. in Ma, Y. (2002). The price tag of Enterprise Resource Planning (ERP) system implementation failure: version 2.0 [online]. Ittoolbox. Available: http://erp.ittoolbox.com/documents/document.asp?i=2374 [29.8.2003].
2. Akkermans, H. in Helden, K. (2002). Vicious and virtuous cycles in ERP implementation: a case study of interrelations between CSF. European Journal of Information Systems, II, pp. 35-46 [database online]. Available: http://erp.ittoolbox.com/documets/document.asp?i=2387 [29.8.2003].
3. Al-Mashari M., A. Al-Mudimigh, in M. Zairi. 2003. Enterprise resource planning: A taxonomy of critical factors. European Journal of Operational Research, 146, 2, pp. 352-364 [database online]. Available: ScienceDirect database. [27.2.2004].
4. Al-Mashari, M. in Zairi, M. 1999. BPR implementation process: an analysis of key success and failure. Business Process Management Journal, 5, 1, pp. 87 [database online]. Available: ProQuest database [5.11.2004].
5. 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: Al-Sehali [samozal.].
6. Anderegg, T. CFPIM, CIRM in CIERP. 2000. ERP: A-Z implementer's guide for success. Eau Claire (WI): Resource Publishing.
7. Bajwa, D. S., Garcia, J. E. in Mooney, T. 2004. An integrative framework for the assimilation of enterprise resource planning systems: phases, antecedents, and outcomes. The Journal of Computer Information Systems, 44, 3, pp. 81-90 [database online]. Available: ProQuest Computing database [5.11.2004].
8. Bakija, A. 2001. ARIS + ASAP…Procesno orientirana vpeljava poslovno informacijskega sistema SAP R/3. [Online]. Available: http://www.drustvo-informatika.si/dogodki/arhiv/dsi2001/sekcija_a/bakija.doc [8.5.2004].
9. Bancroft, N.H., H. Seip in A.Sprengel. 2001. Implementacija SAP R/3: kako uvesti velik sistem v veliko organizacijo, 2 izdaja. Slovenj Gradec: [samozal.] D. Kuster.
10. Beckley, G. in Gaines, R. 1991. Implementation of business systems is as important as the hardware. The CPA Journal, 61, 2, pp. 61-63 [database online]. Available: ABI/INFORM Global database [5.11.2004].
11. Belak J. 2002. Politika podjetja in strateški management. Maribor: Založba MER.
12. Bender, K. W. et al. 2000. Process innovation – case studies of critical success factors. Engineering Management Journal, 12, 4, pp. 17-24 [database online]. Available: ABI/INFORM Global database [18.11.2004].
13. Bernroider, E. in S. Koch. 2000. Differences in Characteristics of the ERP System Selection Process between Small or Medium and Large Organization. AMCIS, pp. 1022-1028 [online]. Available: http://sap.ittoolbox.com/documents/document.asp?i=1949 [2.9.2003].
145
14. Bradford M. in 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, pp. 205-225 [database online]. Available: ScienceDirect database [27.2.2004].
15. Brady J.A., E.F. Monk in B.J. Wagner. 2001. Concepts in enterprise resource planning - Course Technology. Australia [etc.]: Thomson Learning.
16. Brand, H. 1999. SAP R/3 Implementation with ASAP – the official SAP Guide. San Francisco [etc.]: SYBEX.
17. Bruges, P. (2002). ERP implementation methodologies [online]. Ittoolbox. Available: http://erp.ittoolbox.com/documet.asp?i=1864 [29.8.2003].
18. Cadle, J. in D. Yeates. 2001. Project management for information systems. England [etc.]: Prentice Hall.
19. Cotterell, M. in B. Hughes. 1995. Software project management. London [etc.]: International Thomas Computer Press.
20. Davenport, T. H. 1999. Putting the enterprise into the enterprise system. V A Harvard business review: on the business value of IT, uredniki B. L. Martin, G. Batchelder, W. P. Yetter in J. Newcomb. USA: Harvard Business School Publishing.
21. Estaves J., J. A. Pastor in J. Casanovas. (2002). Using the Partial Least Squares (PLS) method to establish CSF interdependence in ERP implementation projects [online]. Ittoolbox. Available: http://erp.ittoolbox.com/documents/document.asp?i=2321 [15.9.2003].
22. Flower, F. J. 2002. Survey Research Methods – Third Edition. Thousan Oaks [etc.]: Sage Publications.
23. Framingham, M. 2004. IDC Releases Top 10 Vendors in ERP Applications Market; Market Consolidation Will Continue at Gradual Pace [Online]. Available: http://www.directionsmag.com/press.releases/ [10.7.2005].
24. Galliers, R. 1992. Information Systems Research – Isssues, Methods and Practical Guidenlines. London [etc.]: Oxford Blackwell Scientific Publications.
25. Gattiker, T. in CFPIM. 2002. Anatomy of an ERP implementation gone away. In Production and Inventory Management Journal, 43, pp. 96-105 [database online]. Available: ABI/INFORM Global database [5.11.2004].
26. Gormly, E. (2001). EAI Overview [online]. Ittoolbox. Available: http://eai.ittoolbox.documents/document.asp?i=1246 [2.9.2003].
27. Hamilton, S. 2002. Maximizing Your ERP System – A Practial Guide for Managers. New York [etc.]: McGraw-Hill.
28. Harrington, J. H., E. K. C. Esseling, in H.Nimwegen. 1997. Business Process Improvement Workbook – Documentation, Analysis, Design, and Management of Business Process Improvement. New York [etc.]: McGraw-Hill.
29. Hartman, F. in R. A. Ashrafi. 2002. Project management in the information systems and information technologies industries. In Project Management Journal, 33, 3, pp. 5-15 [database online]. Available: ABI/INFORM Global database [5.11.2004].
30. Harwood, S. 2004. ERP: The implementation cycle. Oxford [etc.]: Butterworth Heinemann.
146
31. Hauc, A. 2002. Projektni management. Ljubljana: GV založba.
32. Havelka, D. 2003. A user-oriented model of factors that affect information requirements determination process quality. In Information Resource Management Journal, 16, 4, pp. 15- 32 [database online]. Available: ABI/INFORM Global database [5.11.2004].
33. Holland, C. P. in B. Light. 1999. A critical success factors model for ERP implementation. V IEEE Software, 5-6, pp. 30–35 [database online]. Available: ProQuest database [27.2.2004].
34. IDS Scheer. (2002). System Design with ARIS HOBE TM and Rational Unified Process ® - ARIS and UML – white paper [Online]. Available: http://www.ids-scheer.com/ [12.4.2004].
35. IDS Scheer. (2004). ARIS Framework Concept Concept –presentation [Online]. Avaiable: http://www.ids-scheer.com/ [13.4.2004].
36. ISO/IEC 9126-1. 2001. ISO/IEC 9126-1: Software engineering – Product quality – Part 1: Quality model. Geneva: International Standards Organization.
37. ISO/IEC 9126-2. 2003a. ISO/IEC 9126-2: Software engineering – Product quality – Part 1: External metrics. Geneva: International Standards Organization.
38. ISO/IEC 9126-2. 2003b. ISO/IEC 9126-2: Software engineering – Product quality – Part 3: Internal metrics, Geneva: International Standards Organization.
39. ISO/IEC 9126-2. 2004. Software engineering – Product quality – Part 3: Quality in use. Geneva: International Standards Organization.
40. Ittoolbox. (2003). ASAP argumentation with programme management framework [online]. Available: http://sap.ittoolbox.com/documents/document.asp?i=2324 [23.9.2003].
41. Jarrar, Y.F., A. Al-Mudimigh in M. Zairi. 2000. ERP implementation critical success factors – the role and impact of business process management. In ICMIT, 2, pp. 122-127 [database online]. Available: Proquest database [11.11.2004].
42. Jennex, M. in O. Adelakun. 2003. Success factors for offshore information system development. In Journal of Information Technology Cases and Applications, 5, 3, pp. 12-31 [database online]. Available: ABI/INFORM Global database [5.11.2004].
43. Kalakota, R. in M. Robinson. 2001. E-Business 2.0: roadmap for success. USA [etc.]: Addison-Wesley.
44. Kanter, J. in J. J. Walsh. 2004. Toward more successful project management. In Information Systems Management, 21, 2, pp. 16-21 [database online]. Available: ABI/INFORM Global database [18.11.2004].
45. Kendra, K. and L. J. Taplin. 2004. Project success: A cultural framework. In Project Management Journal, 35, 1, pp. 30–45 [database online]. Available: ABI/INFORM Global database [5.11.2004].
46. Kežmah, B. 2003. Model odločanja za izbiro ustrezne celovite informacijske rešitve - magistrsko delo. Maribor: B. Kežmah [samozal.].
47. Khan, A. 2002. Implementing SAP with an ASAP methodology focus. San Jose [etc.]: Writers Club Press.
147
48. Kirchmer, M. 1999. Business Process Oriented Implementation of Standard Software – How to achieve competitive advantage efficiently and effectively – second edition. Berlin [etc.]: Springer.
49. Kosi, M. (2004). Microsoft Business Solutions - Navision - ERP sistem za majhna in srednje velika podjetja [Online]. Available: http://epf-oi.uni-mb.si/clani/bobek/Informatika [10.12.2004].
50. Krell, E. (2003). The Great Debate: ERP vs. BoB [Online]. Available: http://www.businessfinancemag.com [29.8.2003].
51. Larocca D. 2002. Naučite se sami SAP R/3 v 24. urah. Slovenj Gradec: D. Kuster [samozal.].
52. Laudon, K. C. in J. P. Laudon. 2000. Management information systems: organization and technology in the networked enterprise: sixth edition. London etc.: Prentice-Hall.
53. Lientz, B. P. and K. P. Rea. 1998. Project management for the 21st century. San Diego: Academic Press.
54. Light, B., C.P. Holland in K. Wills. 2001. ERP and best of breed: a comparative analysis. In Business Process Management Journal, 7, 3, pp. 216-224 [online database]. Available: Emerald database [15.4.2005].
55. Mabert, V. A., A. Soni and M. A. Venkataramanan. 2003. Enterprise resource planning: Managing the implementation process. In European Journal of Operational Research, 146, 2, pp. 302-314 [database online]. Available: ScienceDirect database [27.2.2004].
56. Microsoft. 2004a. Implementation Methodology Course – Instructors Manual. Microsoft Business Solution Navision 3.60 SI – Metodologija [CD]. Available: Microsoft Corporation. [15.2.2005]
57. Microsoft. 2004b. Implementation Methodology Diagnostic Course – Instructors Manual. Microsoft Business Solution Navision 3.60 SI – Metodologija [CD]. Available: Microsoft Corporation. [15.2.2005]
58. Microsoft. 2004c. Implementation Methodology for project managers Course – Instructors Manual. Microsoft Business Solution Navision 3.60 SI – Metodologija [CD]. Available: Microsoft Corporation. [15.2.2005]
59. Microsoft. 2004d. MBS Partner Methodlogy Overview. Microsoft Business Solution Navision 3.60 SI – Metodologija [CD]. Available: Microsoft Corporation. [15.2.2005]
60. Miller, S. S. 1998. ASAP - Implementation at the speed of business. New York [etc,]: McGraw-Hill.
61. Nah, F. F., J. L. Lau, and J. Kuang. 2001. Critical factors for successful implementation of enterprise systems. In Business Process Management Journal, 7, 3, pp. 285-296 [database online]. Available: http://erp.tollbox.com/documetnts/documet.asp?i=1874 [29.8.2003].
62. Nosan, M. (2005). Uporaba orodja ARIS Toolset pri modeliranju poslovnih procesov. Predstavitev v PPT na EPF Maribor [4.6.05].
63. O'Brien, J. A. 2003. Introduction to information systems: twelfth edition. Boson [etc.]: McGraw-Hill Irwin.
64. O'Leary, D. E. 2000. Enterprise resource planning system: Systems, life cycle, electronic commerce and risk. USA: Cambridge university press.
148
65. Parr, A. in G. Shanks. 2000. A model of ERP project implementation. In Journal of Information Technology, 15, pp. 289-303 [database online]. Available: ProQuest database [11.11.2004].
66. Pivka, Marjan. 1996. Kakovost v programskem inženirstvu. Izola: DESK.
67. Pronet. 2005. Izgradnja poslovno informacijskih sistemov (ERP) - Microsoft Business Solutions-Navision [online]. Available: http://www.pronet.si/wps/portal/ [3.3.2005].
68. Rebernik, M. 1999. Ekonomika podjetja. Ljubljana: GV.
69. Reif, H. 2001. Complementing Traditional Information Systems Implementation Methodologies for Successful ERP System Implementations: dissertation. Virginia: Reif [samozal.]. Available: ProQuest database [10.3.2004].
70. Robson, W. 1994. Strategic management and information systems: an integrative approach. Great Britain: Pitman Publishing.
71. SAP AG. 2002. SAP Engagement Lifecycle Model – Terminology & Definition [pdf datoteka]. SAP Press [interno gradivo podjetja].
72. Scheer, A.W. 2000. ARIS – Business Process Modeling- third edition. Berlin [etc.]: Springer.
73. Schmidt, R., K. Lytinen, M. Keil in P. Cule. 2001. Identifying software project risks: an international Delphi study. In Journal of Management Information Systems, 17, 4, pp. 5-36 [database online]. Available: ABI/INFORM Global database [18.11.2004].
74. Shields, M. G. 2001. E-business and ERP: Rapid implementation and project planning. New York [etc.]: John Wiley & sons, inc.
75. Shrednick, H. R., R. J. Shutt in M. Weiss. 1992. Empowerment: key to IS world-class quality. In MIS Quarteryl, 16, 4, pp. 491-505 [database online]. Available: ABI/INFORM Global database [11.11.2004].
76. Siriginidi, S. 2000. Enterprise resource planning in reengineering business. In Business Process Management Journal, 6, 5 [database online]. Available: Emerald database [5.11.2004].
77. Skok, W. in H. Döringer. 2001. Potencial impact of cultural differences on enterprise resource planning (ERP) projects. In The electronic journal on information systems in developing countries, 7, 5, pp. 1-8 [online]. Available: http://erp.ittoolbox.com/documents/document.asp?i=2359 [2.9.2003].
78. Skok, W. in M. Legge. 2002. Evaluating enterprise resource planning (ERP) systems using an interpretive approach. In Knowledge and Process Management, 9, 2, p.p. 72-82 [database online]. Available: ProQuest database [5.9.2003].
79. Somers T. M. in K. G. Nelson. 2004. A taxonomy of players and activities across the ERP project life cycle. In Information & Management, 41, 3, pp. 257-278 [database online]. Available: ScienceDirect database [27.2.2004].
80. Sternad, S. in S. Bobek. 2004. ERP solutions implementation critical success factors: What do matter and what do not. V The 16th International Conference on Systems Research, Informatics and Cybernetics. Baden-Baden: IIAS.
81. Taylor, J. 2004. Managing information technology projects. New York [etc.]: Amacom.
82. Thickins, G. 2003. New-Reality IT: How less can be more, Agiliti White Paper [online]. Ittoolbox. Available: http://ittoolbox.com/documents/document.asp?i=2323 [1.9.2003].
149
83. Umble E. J., R. R. Haft in M. Umble. 2002. Enterprise resource planning: Implementation procedures and CSF. In European Journal of Operational Research, 146, 2, p.p. 241-257 [database online]. Available: ScienceDirect database [27.2.2004].
84. Umble, E. J. in M. Umble. 2002. Avoiding ERP implementation failure. In Industrial Management, 44, 1, pp. 25-33 [database online]. Available: ABI/INFORM Global database [5.11.2004].
85. Wallace, T. F. in M. H. Kremzar. 2001. ERP: making it happen – the implementer’s guide to success with enterprise resource planning. New York [etc.]: John Wiley & Sons, Inc.
86. Walsh, J. J. in J. Kanter. 1988. Toward more successful project management. In Journal of Systems Management, 39, 1, pp. 16-21 [database online]. Available: ABI/INFORM Global database [5.11.2004].
87. Web, A. 1998. Plan to Successd in ERP Implementation [online]. Available: http://members.aol.com/AllenWeb/succeed.html [2.9.2003].
88. Welti, N. 1999. Successful SAP R/3 implementation: Practical management of ERP projects. England [etc.]: Addison-Wesley.
89. Zhang, L., M. K. O.Lee, Z. Zhang in P. Banerjee. 2002. Critical success factors of enterprise resource planning systems implementation success in China [online]. In HICSS’03 [database online]. Available: ProQuest database [10.2.2004].
150
SEZNAM UPORABLJENIH KRATIC
ABAP - Advamced Business Application Programming (jezik 4 generacije, ki se uprablja pri rešitvi SAP
API - Application Programming Interfaces ARIS - ARchitecture of integrated Information Systemy ASAP - Accelerated SAP (pospešeni SAP) ASP - Application Sevice Provider (ponudnik aplikacijskih storitev) B2B - Business to Business BoB - Best-of-breed CASE - Computer Aded Software Engineering CEL - Customer Engagement Lifecycle ( prodajna metodologija podjetja SAP) CIM - Computer-Integrated Manufacturing CPI - Continuous Process Improvement (nenehen proces izboljšav) CRM - Customer Relation Management (upravljanje s človeškimi viri) CSF - Critical success factor EAI - Enterprise Application Integration (celovita integracija aplikacij) EIS - Executive Information Systems ERM - Enterprise Resource Management (upravljanje virov podjetja) ERP - Enterprise Resource planing (planiranje podjetniških virov) ERP II - Enterprise Resource planing II GUI - Graphical User Interface (grafični uporabniški vmesnik) IS - Informacijski sistem IT - Informacijska tehnologija JIT - Just in Time KDU - Kritični dejavniki uspeha MBS - Microsoft Business Solution MRP - Material Requirements Planning (planiranje zahtev materiala) MRP II - Manufacturing Resource Planning (planiranje proizvodnjih virov) OLAP - Online Analytical Processing OPT - Total quality management OS - Operacijski sistem PB - Podatkova baza RFI - Request For Information (zahtevo po informacijah) RFP - Request for Proposal (zahtevo za ponudbo) ROI - Return On Investment (koeficient rentabilnosti) SCM - Supply Change Management (obvladovanje nabavnih verig in logistike) SQL - Structured Query Language SUPB - Sistem za upravljanje s podatkovno bazo TQM - Total quality management UML - Unified Modelling Language VoIP - Voice over Internet Protocol WAP - Wireless Application Protocol WBS - Work Breakdown Structure XML - Extensible Markup Language
151
KAZALO SLIK SLIKA 1: Zgodovina rešitev ERP ____________________________________________________________ 12 SLIKA 2: Koncept rešitve ERP kot trikotnika ___________________________________________________ 16 SLIKA 3: Grafični prikaz koncepta rešitve ERP _________________________________________________ 17 SLIKA 4: Razširjeno programsko okolje organizacije ____________________________________________ 17 SLIKA 5: Tehnična arhitektura ERP sistema ___________________________________________________ 18 SLIKA 6: Življenjski cikel rešitve ERP ________________________________________________________ 19 SLIKA 7: Življenjski cikel rešitve ERP z mejniki ________________________________________________ 19 SLIKA 8: Življenjski cikel IS ________________________________________________________________ 21 SLIKA 9: Življenjski cikel IS, kjer projekt razvoja in uvedbe IS ni končan v predvidenem času in s predvidenimi stroški _________________________________________________________________________________ 21 SLIKA 10: Vpliv prihajajoče tehnologije na obstoječo ____________________________________________ 22 Slika 11: Življenjski cikel rešitve ERP ________________________________________________________ 23 Slika 12: Funkcijsko usmerjen razvoj standardnih rešitev _________________________________________ 25 SLIKA 13: Funkcijski in procesni pogled na podjetje _____________________________________________ 25 SLIKA 14: Potek projekta uvajanja rešitve ERP _________________________________________________ 28 SLIKA 15: Zemljevid hitre implementacije _____________________________________________________ 31 SLIKA 16: Odnosi med obsegom projekta, viri projekta in časom za izvedbo projekta ___________________ 35 SLIKA 17: Učinek dobrega projektnega managementa ___________________________________________ 35 SLIKA 18: Razširjena projektna organizacija __________________________________________________ 37 SLIKA 19: Karakteristike svetovalcev _________________________________________________________ 41 SLIKA 20: Stopnja sprememb _______________________________________________________________ 44 SLIKA 21: Proces pristopa izbire EPR sistema _________________________________________________ 45 SLIKA 22: Možnosti ukrepanja, kadar poslovne zahteve in zmožnosti paketa niso enake _________________ 48 SLIKA 23: Orodja za analiziranje in načrtovanje poslovnih procesov organizacije _____________________ 49 SLIKA 24: Procesni model poslovno usmerjene uvedbe standardne rešitve ___________________________ 50 SLIKA 25: Arhitektura ARIS hiše ____________________________________________________________ 51 SLIKA 26: Razdelitev posameznih elementov poslovnega procesa v različne poglede _________________ 52 SLIKA 27: Delovno okolje orodja ARIS Toolset _________________________________________________ 54 SLIKA 28: Koncept ARIS HOBE _____________________________________________________________ 55 SLIKA 29: Pristop velikega poka in malega velikega poka ________________________________________ 76 SLIKA 30: Metodologija CEL _______________________________________________________________ 78 SLIKA 31: Prepletenost modulov v rešitvi Navision ______________________________________________ 88 SLIKA 32: Tehnološki investicijski cikel _______________________________________________________ 88 SLIKA 33: Prodajna metodologija ___________________________________________________________ 90 SLIKA 34: Koraki metodologije On Target ____________________________________________________ 91 SLIKA 35: Povezava med metodologijama _____________________________________________________ 92 SLIKA 36: Povezava med posameznimi testi ___________________________________________________ 94 SLIKA 37: Koraki testiranja ________________________________________________________________ 94 SLIKA 38: KDU rešitev ERP in informacijskih projektov na splošno _______________________________ 109 SLIKA 39: Potek raziskave KDU rešitev ERP v slovenskem okolju _________________________________ 116 SLIKA 40: Grafična razvrstitev KDU glede na rang raziskave ____________________________________ 130
152
KAZALO TABEL TABELA 1: Primerjava med ERP in ERP II ____________________________________________________ 14 TABELA 2: Primerjava razvojnih faz rešitev ERP _______________________________________________ 14 TABELA 3: Pet največjih svetovnih ponudnikov rešitev ERP _______________________________________ 15 TABELA 4: Glavne aktivnosti v procesu uvajanja rešitve ERP _____________________________________ 28 TABELA 5: Odvisnost ciljev ________________________________________________________________ 29 TABELA 6: Seznam metodologij ponudnikov rešitev ERP in svetovalnih hiš ___________________________ 30 TABELA 7: Glavne razlike med rešitvijo BoB in rešitvijo ERP _____________________________________ 46 TABELA 8: Celotni stroški rešitve ERP v odstotkih ______________________________________________ 70 TABELA 9: Primerjava ASAP in standardne metodologije ________________________________________ 81 TABELA 10: Časovna razporeditev faz metodologije ASAP _______________________________________ 82 TABELA 11: Primerjava osnovnih značilnosti rešitev mySAP ERP in MBS Navision ____________________ 96 TABELA 12: Primerjava pomembnejših značilnosti metodologij uvajanja ASAP in On Target ____________ 97 TABELA 13: V zadnjih petih letih objavljeni članki na temo KDU uvajanja rešitev ERP _________________ 99 TABELA 14: Objavljeni članki o KDU uvedb IS na splošno ______________________________________ 110 TABELA 15: KDU glede na faze uvedbe rešitve ERP ____________________________________________ 112 TABELA 16: Pregled namestitev rešitev po dejavnostih __________________________________________ 119 TABELA 17: Pregled prileganja posameznih rešitev poslovnim procesom organizacij __________________ 122 TABELA 18: Prikaz rešitev glede na metodo uvedbe ____________________________________________ 123 TABELA 19: Prikaz prilagoditev procesov glede na uvedeno rešitev ERP ___________________________ 124 TABELA 20: Čas uvedbe rešitve ERP glede na izbrano rešitev ____________________________________ 124 TABELA 21: Prikaz odvisnosti spremembe funkcionalnosti glede na uvedeno rešitve ERP ______________ 126 TABELA 22: Prikaz odvisnosti spremembe stroškov glede na uvedeno rešitev ERP ____________________ 127 TABELA 23: Kontigenčna tabela spremenljivk rešitev in problem __________________________________ 127 TABELA 24: Primerjava rangiranja KDU iz strokovne literature in ankete __________________________ 129 TABELA 25: Prikaz srednjih vrednosti (aritmetična sredina) KDU glede na faze uvajanja ______________ 131 TABELA 26: Prikaz primerjave pomembnosti KDU z vidika faz glede na strokovno literaturo in raziskavo _ 133 TABELA 27: Korelacijska tabela KDU glede na rang, ki so uvedli rešitev ERP po metodi ponudnika ______ 135 TABELA 28: Prikaz rangiranja posameznih KDU glede na rešitve GEAC, Navision in SAP _____________ 137 TABELA 29: Prikaz pomembnosti KDU glede na uvedbo rešitev ERP po metodologiji ponudnika oziroma po lastni metodologiji_______________________________________________________________________ 139 TABELA 30: Prikazuje range KDU glede na posamezne pristope uvedbe rešitve ERP __________________ 140 TABELA 31: Pomembnost KDU skozi ASAP faze uvedbe ________________________________________ 154 TABELA 32: Uvedeni moduli rešitve GEAC System 21 (vprašanje 3) _____________________________ 159 TABELA 33: Uvedeni moduli rešitve MS Navision (vprašanje 3) ___________________________________ 159 TABELA 34: Uvedeni moduli rešitve mySAP ERP (vprašanje 3) ___________________________________ 159 TABELA 35: Prikazuje število in odstotke, v kolikšni meri izbrana rešitev ERP ustreza poslovnemu proces (vprašanje 7) ___________________________________________________________________________ 160 TABELA 36: Prikazuje frekvence pristopov uvajanja rešitve ERP __________________________________ 160 TABELA 37: Prikazuje, katero metodo uvajanja so organizacije izbrale _____________________________ 160 TABELA 38: Prikazuje, koliko so morale organizacije v povprečju prilagoditi svoje poslovne procese procesom rešitve ERP ____________________________________________________________________________ 160 TABELA 39: Čas uvedbe rešitve ERP ________________________________________________________ 161 TABELA 40: Prikazuje frekvence in odstotke odgovorov na vprašanje povečanja stroškov uvedbe ________ 161 TABELA 41: Prikazuje KDU po rangu pomembnosti ____________________________________________ 162 TABELA 42: Korelacijska matrika za KDU (glede na rang) ______________________________________ 162 TABELA 43: Osnovna statistična analiza KDU glede na metodologijo uvedbe ________________________ 164
153
KAZALO GRAFIKONOV GRAF 1: Razvrstitev rešitev glede na velikost podjetja __________________________________________ 118 GRAF 2: Pregled organizacij po dejavnosti po klasifikaciji KLASJE _______________________________ 119 GRAF 3: Število v ožjem izboru omenjenih rešitev ERP v odstotkih ________________________________ 120 GRAF 4: Prikazuje prileganje izbrane rešitve ERP poslovnim procesom organizacije v odstotkih _________ 121 GRAF 5: Prikazuje pristop uvajanja v odstotkih _______________________________________________ 122 GRAF 6: Grafični prikaz porazdelitve rešitev glede na pristop uvajanja _____________________________ 123 GRAF 7: Prikaz različnih metod uvajanja slovenskih organizacij _________________________________ 123 GRAF 8: Grafični prikaz časa uvedbe rešitve ERP v slovenskih organizacijah ________________________ 124 GRAF 9: Prikazuje spremembo načrtovane funkcionalnosti v času uvedbe rešitve ERP v odstotkih ________ 125 GRAF 10: Grafični prikaz spremembe stroškov uvedbe, glede na načrtovane stroške v odstotkih _________ 126 GRAF 11: Odstotkovni prikaz pristopov uvajanja ______________________________________________ 139
154
PRILOGA A
Tabela prikazuje KDU glede na metodologijo uvajanja ASAP po posameznih fazah metodologije ASAP. Ocenjena je z lestvico od 1 do 10, kjer pomeni 1 nepomemben dejavnik, 10 pa zelo pomemben dejavnik. TABELA 31: Pomembnost KDU skozi ASAP faze uvedbe
Kritični dejavniki uspeha 1.
faza 2.
faza 3.
faza 4.
faza 5.
faza
Org
aniz
acijs
ki v
idik
Strateški vidik
Podpora uprave 8 5 5 6 8
Management sprememb 6 9 6 5 6
Management obsega 5 4 4 5 5
Organizacija projektnega tima in njegove kompetence
5 4 4 4 4
Prenova poslovnih procesov 4 7 4 4 5
Projektni manager 10 10 9 10 10
Sodelovanje končnih uporabnikov 5 8 10 7 5
Zaupanje med partnerji 5 4 4 5 5
Taktični vidik
Predanost zaposlenih in svetovalcev 5 5 4 5 6
Notranja in zunanja komunikacija 7 7 5 6 8
Projektni plan 9 7 7 7 5
Program izobraževanja 5 5 5 7 4
Iskanje in odprava motenj 4 4 7 9 7
Zunanji svetovalci 5 4 4 4 4
Hitre odločitve 3 5 5 5 4
Tehn
ološ
ki
vidi
k
Strateški vidik
Jasni cilji, strategija in obseg uvajanja rešitve ERP 5 4 4 4 4
Izogibanje prilagajanju 4 4 4 4 4
Različica rešitve ERP 4 4 4 4 4
Tehnološki vidik
Prilagajanje programske opreme 5 6 10 6 6
Prenašanje podatkov med rešitvijo ERP in obstoječimi IS 3 4 4 4 4
Vir: prirejeno po Estaves et al, 2003, 5
155
PRILOGA B
VPRAŠALNIK O CELOVITIH INFORMACIJSKIH REŠITVAH SAP R/3 in mySAP ERP
1. Opredelite velikost vaše organizacije (v slovenskem merilu):
o Majhno podjetje (do 50 zaposlenih, prihodek do 4,2 mio EUR in vrednost aktive do 2,1 mio EUR) o Srednjeveliko podjetje (do 250 zaposlenih, prihodek do 16,8 mio EUR in vrednost aktive do 8,4 mio EUR) o Veliko podjetje (nad 250 zaposlenih, prihodek nad 16,8 mio EUR in vrednost aktive nad 8,4 mio EUR)
2. Opredelite dejavnost vaše organizacije: __________________________________________ 3. Katere module rešitve SAP ste uvedli (imamo) in katere še nameravate uvesti (bomo)?
Imamo Bomo Imamo Bomo Proizvodnja in distribucija (SD) Upravljanje osnovnih sredstev (AM)
Materialno poslovanje (MM) Projektni sistem (PS)
Planiranje proizvodnje (PP) Potek dela (WF)
Obvladovanje kakovosti (QM) Industrijske rešitve (IS)
Vzdrževanje (PM) Supply Chain Management (SCM)
Kadrovski sistemi (HR) Customer Relationship Management
(CRM) Finančno knjigovodstvo (FA)
Kontroling (CO) Business intelegence (BI)
4. Navedite tri najpomembnejše razloge, zakaj ste se odločili za izbiro rešitve ERP?
1. _______________________________________________________________________ 2. _______________________________________________________________________ 3. _______________________________________________________________________
5. Med katerimi rešitvami ERP ste se odločali v procesu izbire rešitev ERP? 1. _______________________________________________________________________ 2. _______________________________________________________________________ 3. _______________________________________________________________________
6. Navedite tri glavne razloge, zakaj ste se odločili za izbiro rešitve SAP v vašo organizacijo? 1. _______________________________________________________________________ 2. _______________________________________________________________________ 3. _______________________________________________________________________
7. V kolikšni meri je rešitev SAP ustrezala poslovnemu procesu vaše organizacije? Popolno V veliki meri Delno Slabo
8. Kateri pristop uvajanja ste uporabili?
I. Uvedli smo vse module hkrati in nato v naprej določen dan zagnali v živo rešitev ERP, stare informacijske sisteme pa ugasnili (»Bing bang pristop«).
II. Nove module rešitve ERP smo uvedli zaporedno, npr. najprej finančni modul, nato proizvodni modul, itd.(fazni pristop).
III. Po uvedbi rešitve ERP in zagonu rešitve ERP sta nekaj časa delovala oba sistema (stari informacijski sistemi in rešitev ERP; vzporedni pristop).
IV. Najprej smo uvedli rešitev ERP za enostavnejši poslovni proces, kasneje pa smo uvedli rešitev ERP za zahtevnejše poslovne procese (procesni pristop).
V. Kombinacija zgornjih pristopov. 9. Po kateri metodi ste uvedli rešitev SAP?
o Po metodi ponudnika rešitve ERP. o Po lastni metodi. o Drugo.
156
10. Na spodnji skali opredelite, za koliko ste morali v povprečju svoje poslovne procese prilagoditi poslovnim procesom rešitve SAP.
o V celoti o V veliki meri o Delno o Nič
11. Kritični dejavniki uspeha (v nadaljevanju KDU) usodno vplivajo na proces uvajanja rešitve
ERP. V spodnji tabeli so navedeni najpomembnejši KDU, ki jih navaja strokovna literatura. Za vsak KDU označite, kako pomemben je bil v posamezni fazi uvajanja. V vsako polje vnesite eno izmed štirih možnosti: 1 – nepomemben, 2 – manj pomemben, 3 – pomemben in 4 – zelo pomemben.
Primer:
Rang
1. KDU 1 1 2 3 3 2 2. KDU 2 4 3 2 1 1
Rang
Jasni cilji, strategija in obseg uvajanja rešitve
Vključitev in podpora »top managementa«
Aktivna vloga sponzorja projekta
Organizacija projektnega tima in njegove kompetence
Uporaba principov projektnega managementa
Komunikacija znotraj projektnega tima
Komunikacija med projektnim timom in ostalimi v organizaciji
Vključevanje zunanjih svetovalcev
Vključitev in sodelovanje uporabnikov pri uvedbi ERP
Izobraževanje uporabnikov rešitve ERP
Management sprememb
Prenova poslovnih procesov
Izbira tehnološke arhitekture
Čim manj prilagajanja rešitve ERP posebnostim organizacije
Prenos podatkov iz starih rešitev v rešitev ERP
V stolpcu »Rang« zgornje tabele označite pomembnost KDU uvajanja za vašo organizacijo (1- najpomembnejši dejavnik do 15 – najmanj pomembni dejavnik). Ali so se v procesu uvajanja rešitve SAP pojavili še kateri drugi KDU? _________________________________________________________________________________
IZBIRA
REŠITVE
ANALIZA
PROCESOV
KONFIGU-RIRANJE
REŠITVE
TESTIRA-NJE
REŠITVE
UVEDBA REŠITVE
STABILI-ZACIJA
DELOVANJA
IZBIRA
REŠITVE
ANALIZA
PROCESOV
KONFIGU-RIRANJE
REŠITVE
TESTIRA-NJE
REŠITVE
UVEDBA REŠITVE
STABILI-ZACIJA
DELOVANJA
157
12. Koliko mesecev je trajal proces uvajanja rešitve SAP?
o do 3 mesece
o 3 - 6 mesecev o 6 - 9 mesecev o 9-12 mesecev o nad 12 mesecev
Ali je projekt uvedbe rešitve SAP trajal dlje od načrtovanega?
o DA, za __________ mesecev o NE Če je odgovor DA, potem navedite razlog(e): ___________________________________
13. Na začetku projekta ste načrtovali predvideno funkcionalnost rešitve SAP. Ali se je obseg
predvidene funkcionalnosti v času uvajanja spremenil?
o Precej zmanjšal
o Malo zmanjšal
o Ni se spremenil
o Malo povečal
o Precej povečal
Navedite razlog: _________________________________________________________
14. Ali so se stroški projekta uvedbe rešitve SAP spremenili od načrtovanih?
o Precej manjši od načrtovanih
o Malo manjši od načrtovanih
o Enaki načrtovanim
o Malo večji od načrtovanih
o Precej večji od načrtovanih
Navedite razlog:__________________________________________________________
15. Ali so se pri uvajanju rešitve SAP pojavili večji problemi?
o DA o NE
Če je odgovor DA, potem navedite najpomembnejše probleme pri uvajanju:
1. __________________________________________________________ 2. __________________________________________________________ 3. __________________________________________________________
16. Navedite vaš položaj v organizaciji: ______________________________________________ Zahvaljujem se vam, da ste si vzeli čas in izpolnili vprašalnik. Če vas zanimajo rezultati ankete, potem napišite elektronski naslov, kamor vam jih lahko posredujem. Vaš elektronski naslov: ________________________________________________________ S spoštovanjem, Simona Sternad E-pošta: [email protected] Spletni naslov: http://epf-oi.uni-mb.si Tel.: (02)-22-90-248 Faks: (02)-25-16-681 Prosim pošljite anketo na spodnji naslov: Ekonomsko-poslovna fakulteta Maribor (Simona Sternad) Razlagova 14 2000 Maribor
158
PRILOGA C
Razvrstitev dejavnosti po SURS52: A KMETIJSTVO, LOV, GOZDARSTVO B RIBIŠTVO IN RIBIŠKE STORITVE C RUDARSTVO D PROIZVODNJA
A PROIZVODNJA HRANE, PIJAČ, KRMIL IN TOBAČNIH IZDELKOV B PROIZVODNJA TEKSTILIJ, USNJENIH OBLAČIL, TEKSTILNIH IN KRZNENIH
IZDELKOV C PROIZVODNJA USNJA, OBUTVE IN USNJENIH IZDELKOV, RAZEN OBLAČIL D OBDELAVA IN PREDELAVA LESA, PROIZVODNJA IZDELKOV IZ LESA, PLUTE,
SLAME IN PROTJA, RAZEN POHIŠTVA E PROIZVODNJA VLAKNIN, PAPIRJA IN KARTONA TER IZDELKOV IZ PAPIRJA IN
KARTONA, ZALOŽNIŠTVO IN TISKARSTVO F PROIZVODNJA KOKSA, NAFTNIH DERIVATOV, JEDRSKEGA GORIVA G PROIZVODNJA KEMIKALIJ, KEMIČNIH IZDELKOV, UMETNIH VLAKEN H PROIZVODNJA IZDELKOV IZ GUME IN PLASTIČNIH MAS I PROIZVODNJA DRUGIH NEKOVINSKIH MINERALNIH IZDELKOV J PROIZVODNJA KOVIN IN KOVINSKIH IZDELKOV K PROIZVODNJA STROJEV IN NAPRAV L PROIZVODNJA ELEKTRIČNE IN OPTIČNE OPREME M PROIZVODNJA VOZIL IN PLOVIL N PROIZVODNJA POHIŠTVA IN DRUGE PREDELOVALNE DEJAVNOSTI, RECIKLAŽA
E OSKRBA Z ELEKTRIČNO ENERGIJO, PLINOM IN VODO F GRADBENIŠTVO G TRGOVINA, POPRAVILA MOTORNIH VOZIL IN IZDELKOV ŠIROKE PORABE H GOSTINSTVO I PROMET, SKLADIŠČENJE IN ZVEZE J FINANČNO POSREDNIŠTVO K POSLOVANJE Z NEPREMIČNINAMI, NAJEM IN POSLOVNE STORITVE L DEJAVNOST JAVNE UPRAVE IN OBRAMBE, OBVEZNO SOCIALNO ZAVAROVANJE M IZOBRAŽEVANJE N ZDRAVSTVO IN SOCIALNO VARSTVO O DRUGE JAVNE, SKUPNE IN OSEBNE STORITVENE DEJAVNOSTI P ZASEBNA GOSPODINJSTVA Z ZAPOSLENIM OSEBJEM Q EKSTERITORIALNE ORGANIZACIJE IN ZDRUŽENJA
52 Vir: http://www.stat.si/klasje/tabela.aspx?cvn=1891
159
PRILOGA D
Vprašanje je bilo za vsako rešitev prirejeno tako, da smo se izognili pisnim odgovorom. Tako imamo rezultate odgovorov v treh tabelah, in sicer v tabeli 32 za rešitev GEAC System 21, v tabeli 33 za rešitev MS Navision in v tabeli 34 za rešitev mySAP ERP. Tako smo za vsako rešitev pripravili nabor modulov, anketiranci pa so morali označiti uvedene module. Ne glede na uvedeno rešitev ERP smo vse anketirance spraševali, katere module rešitve ERP imajo uvedene (stolpec Imamo) in ali nameravajo v prihodnosti uvesti še dodatne module (stolpec Bomo) uvedene rešitve. TABELA 32: Uvedeni moduli rešitve GEAC System 21 (vprašanje 3)
Imamo Bomo Prazno Finančno poslovanje 3 0 0 Upravljanje s kupci in logistika 3 0 0 Planiranje proizvodnje in kontrola 1 0 2 Urejanje po-prodajnih aktivnosti 0 0 3 Vertikalne rešitve 0 0 3 E-poslovanje 0 0 3
TABELA 33: Uvedeni moduli rešitve MS Navision (vprašanje 3)
Imamo Bomo Prazno Finančno poslovanje 23 0 0 Proizvodnja in distribucija (SCM) 7 5 11 Upravljanje s kupci (SCM) 11 5 7 E-poslovanje 6 4 13 Vertikalne rešitve 4 2 17 Skladiščno poslovanje 16 0 7
TABELA 34: Uvedeni moduli rešitve mySAP ERP (vprašanje 3)
Imamo Bomo Prazno Proizvodnja in distribucija (SD) 14 3 5 Materialno poslovanje (MM) 14 7 1 Planiranje proizvodnje (PP) 12 4 6 Obvladovanje kakovosti (QM) 8 5 9 Vzdrževanje (PM) 3 7 12 Kadrovski sistemi (HR) 10 7 5 Finančno knjigovodstvo (FA) 18 3 1 Kontroling (CO) 11 3 8 Upravljanje osnovnih sredstev (AM) 16 3 3 Projektni sistem (PS) 4 6 12 Potek dela (WF) 3 5 14 Industrijske rešitve (IS) 2 2 18 Supply Chain Management (SCM) 1 6 15 Customer Relationship Management (CRM) 1 6 15 Business intelegence (BI) 4 5 13
160
TABELA 35: Prikazuje število in odstotke, v kolikšni meri izbrana rešitev ERP ustreza poslovnemu proces (vprašanje 7)
Število
odgovorov Odstotki Veljavni odstotki
Veljavno Popolnoma 7 14,6 15,6 V veliki meri 32 66,7 71,1 Delno 6 12,5 13,3 Skupaj 45 93,8 100,0 Manjka 3 6,3 Skupaj 48 100,0
TABELA 36: Prikazuje frekvence pristopov uvajanja rešitve ERP
Število
odgovorov Odstotki Veljavni odstotki
Veljavno Big bang 22 45,8 47,8 Fazni pristop 7 14,6 15,2 Vzporedni pristop 6 12,5 13,0 Procesni pristop 3 6,3 6,5 Kombinacija 8 16,7 17,4 Skupaj 46 95,8 100,0 Manjka 2 4,2 Skupaj 48 100,0
TABELA 37: Prikazuje, katero metodo uvajanja so organizacije izbrale
Število
odgovorov Odstotki Veljavni odstotki
Veljavno Po metodi ponudnika 34 70,8 75,6 Po lastni metodi 8 16,7 17,8 Drugo 3 6,3 6,7 Skupaj 45 93,8 100,0 Manjka 3 6,3 Skupaj 48 100,0
TABELA 38: Prikazuje, koliko so morale organizacije v povprečju prilagoditi svoje poslovne procese procesom rešitve ERP
Število
odgovorov Odstotki Veljavni odstotki Veljavno V veliki meri 11 22,9 23,9 Delno 34 70,8 73,9 Nič 1 2,1 2,2 Skupaj 46 95,8 100,0 Manjka 2 4,2 Skupaj 48 100,0
161
TABELA 39: Čas uvedbe rešitve ERP
Število
odgovorov Odstotki Veljavni odstotki
Veljavno Do 3 mesece 5 10,4 11,1 3 do 6 mesecev 10 20,8 22,2 6 do 9 mesecev 7 14,6 15,6 9 do 12 mesecev 8 16,7 17,8 Nad 12 mesecev 15 31,3 33,3 Skupaj 45 93,8 100,0 Manjka 3 6,3 Skupaj 48 100,0
TABELA 40: Prikazuje frekvence in odstotke odgovorov na vprašanje povečanja stroškov uvedbe
Število
odgovorov Odstotki Veljavni odstotki
Veljavno Malo manjši od načrtovanih 2 4,2 4,5 Enaki načrtovanim 11 22,9 25,0 Malo večji od načrtovanih 21 43,8 47,7 Precej večji od načrtovanih 10 20,8 22,7 Skupaj 44 91,7 100,0 Manjka 4 8,3 Skupaj 48 100,0
162
PRILOGA E TABELA 41: Prikazuje KDU po rangu pomembnosti
Veljavni Manjka Aritmet. sredina Mediana Stand. odklon Varianca
Jasni cilji, strategija in obseg uvajanja rešitve 32 16 2,72 1 3,787 14,338 Vključitev in podpora uprave 32 16 5,66 4 4,541 20,62 Aktivna vloga sponzorja projekta 31 17 8,84 9 4,503 20,273 Organizacija projektnega tima in njegove kompetence 32 16 5,81 5 3,578 12,802 Uporaba principov projektnega managementa 31 17 9,87 10 3,462 11,983 Komunikacija znotraj projektnega tima 31 17 7,58 7 3,775 14,252 Komunikacija med projektnim timom in ostalimi v organizaciji 32 16 7,28 8 2,667 7,112 Vključevanje zunanjih svetovalcev 30 18 8,47 10 4,462 19,913 Vključitev in sodelovanje uporabnikov 31 17 6,42 6 3,063 9,385 Izobraževanje končnih uporabnikov 31 17 7,71 7 3,309 10,946 Management sprememb 31 17 10,74 12 3,614 13,065 Prenova poslovnih procesov 31 17 7,74 8 3,838 14,731 Izbira tehnološke arhitekture rešitve ERP 30 18 11,63 13 3,662 13,413 Čim manj prilagajanja rešitve ERP posebnostim organizacije 31 17 9,19 10 4,362 19,028 Prenos podatkov iz starih rešitev v rešitev ERP 31 17 9,13 11 4,738 22,449
TABELA 42: Korelacijska matrika za KDU (glede na rang)
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15R1 ,000 ,051 ,002 ,060 ,191 ,239 ,324 ,204 ,270 ,037 ,342 ,234 ,010 ,041R2 ,000 ,017 ,000 ,015 ,321 ,189 ,464 ,039 ,054 ,072 ,334 ,011 ,101 ,007R3 ,051 ,017 ,232 ,038 ,266 ,100 ,308 ,464 ,237 ,180 ,469 ,313 ,399 ,044R4 ,002 ,000 ,232 ,040 ,000 ,193 ,419 ,014 ,093 ,429 ,127 ,089 ,211 ,036R5 ,060 ,015 ,038 ,040 ,362 ,378 ,305 ,143 ,048 ,041 ,309 ,499 ,186 ,084R6 ,191 ,321 ,266 ,000 ,362 ,001 ,375 ,347 ,112 ,383 ,432 ,125 ,144 ,415R7 ,239 ,189 ,100 ,193 ,378 ,001 ,261 ,239 ,153 ,465 ,190 ,050 ,357 ,452R8 ,324 ,464 ,308 ,419 ,305 ,375 ,261 ,396 ,367 ,268 ,295 ,086 ,393 ,207R9 ,204 ,039 ,464 ,014 ,143 ,347 ,239 ,396 ,018 ,416 ,264 ,004 ,242 ,195R10 ,270 ,054 ,237 ,093 ,048 ,112 ,153 ,367 ,018 ,320 ,224 ,045 ,450 ,003R11 ,037 ,072 ,180 ,429 ,041 ,383 ,465 ,268 ,416 ,320 ,008 ,351 ,487 ,150R12 ,342 ,334 ,469 ,127 ,309 ,432 ,190 ,295 ,264 ,224 ,008 ,433 ,100 ,294R13 ,234 ,011 ,313 ,089 ,499 ,125 ,050 ,086 ,004 ,045 ,351 ,433 ,257 ,015R14 ,010 ,101 ,399 ,211 ,186 ,144 ,357 ,393 ,242 ,450 ,487 ,100 ,257 ,092R15 ,041 ,007 ,044 ,036 ,084 ,415 ,452 ,207 ,195 ,003 ,150 ,294 ,015 ,092
*Sivo označene celice pomenijo zmerno pozitivno korelacijo med KDU; Sig. (1-tailed) 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 managementa R6 - Komunikacija znotraj projektnega tima R7 - Komunikacija med projektnim timom in ostalimi v organizaciji R8 - Vključevanje zunanjih svetovalcev
R9 - Vključitev in sodelovanje uporabnikov R10 - Izobraževanje končnih uporabnikov R11 - Management 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
163
PRILOGA F
V spodnjih tabelah je prikazana varianca, modus in standardni odklon KDU glede na faze uvajanja ter srednje vrednosti po fazah za rešitev Navision in za rešitev SAP. Varianca 1 2 3 4 5 6R1 0,77 0,92 0,68 1,22 1,085 1,36R2 1,37 1,27 0,94 0,75 1,174 1,26R3 1,52 1,29 1,04 1,15 1,362 1,34R4 1,04 0,94 0,82 1,22 0,987 1,27R5 1,03 1,28 1,05 1,17 1,278 0,95R6 1,4 1,11 1,05 1,22 1,146 1,33R7 1,44 1,1 1,23 1,25 1,336 1,17R8 1,39 1,18 1,33 1,27 1,412 1,25R9 1,17 1,13 1,13 1,32 1,327 1,23R10 1,29 1,36 1,19 1,12 1,362 1,34R11 0,75 1,05 0,99 1,21 1,161 1,47R12 1,41 1,5 1,09 1,21 1,329 1,38R13 1,57 0,86 1,06 0,95 0,855 1,11R14 1,52 1,42 1,37 1,04 1,182 1,27R15 1,39 1,29 1,21 1,37 1,466 1,19
Modus 1 2 3 4 5 6R1 4 4 3 3 3 4R2 4 2 1 1 3 1R3 1 1 1 1 1 1R4 1 4 3 4 4 3R5 2 4 2 2 4 2R6 1 4 4 4 4 4R7 1 4 3 4 4 4R8 1 3 4 2 4 1R9 1 3 1 4 4 4R10 1 1 3 3 4 4R11 1 1 2 2 1 1R12 1 4 3 3 4 1R13 1 1 1 1 1 1R14 1 3 3 1 1 1R15 1 1 1 4 4 1
Standard odklon 1 2 3 4 5 6R1 0,88 0,96 0,82 1,1 1,04 1,16R2 1,17 1,13 0,97 0,86 1,08 1,12R3 1,23 1,14 1,02 1,07 1,17 1,16R4 1,02 0,97 0,91 1,1 0,99 1,13R5 1,02 1,13 1,02 1,08 1,13 0,98R6 1,18 1,05 1,02 1,1 1,07 1,15R7 1,2 1,05 1,11 1,12 1,16 1,08R8 1,18 1,09 1,15 1,13 1,19 1,12R9 1,08 1,06 1,06 1,15 1,15 1,11R10 1,14 1,16 1,09 1,06 1,17 1,16R11 0,86 1,02 1 1,1 1,08 1,21R12 1,19 1,23 1,04 1,1 1,15 1,17R13 1,25 0,93 1,03 0,97 0,92 1,05R14 1,23 1,19 1,17 1,02 1,09 1,13R15 1,18 1,14 1,1 1,17 1,21 1,09
164
Navis. 1 2 3 4 5 6 SAP 1 2 3 4 5 6R1 3,40 3,13 3,00 2,67 2,80 2,93 R1 3,69 3,00 3,00 2,31 2,46 2,31R2 3,00 2,33 2,07 1,93 2,13 2,07 R2 3,31 2,54 1,54 1,62 2,77 2,38R3 2,40 2,33 1,80 2,07 2,00 1,93 R3 3,15 2,54 1,85 1,85 2,69 2,23R4 2,73 2,93 2,93 2,87 2,87 2,60 R4 1,77 3,23 3,31 3,38 3,46 3,00R5 2,53 2,47 2,53 2,20 2,20 2,00 R5 1,92 2,69 2,31 2,69 3,00 2,00R6 2,87 3,07 2,93 2,93 2,87 2,80 R6 1,77 3,54 2,92 3,00 3,31 2,92R7 2,67 3,13 2,53 3,07 2,93 3,07 R7 2,08 3,31 2,46 2,85 2,92 2,85R8 2,13 2,40 2,67 2,47 2,47 2,13 R8 2,08 2,92 3,31 2,46 2,85 2,23R9 2,33 2,47 2,33 3,00 3,00 2,73 R9 1,46 2,85 1,92 2,92 2,69 2,92R10 1,93 2,27 2,47 2,60 2,53 3,00 R10 1,46 1,69 1,85 2,69 2,77 3,08R11 1,87 2,07 1,93 2,00 2,27 2,33 R11 1,62 1,92 2,31 2,77 2,62 3,31R12 2,73 2,87 2,80 2,60 2,87 2,60 R12 2,54 3,15 2,23 2,46 2,62 2,54R13 2,73 2,07 2,13 2,00 1,93 1,73 R13 1,69 1,77 2,15 1,69 1,62 1,85R14 2,67 2,53 2,47 2,27 2,13 1,87 R14 2,31 2,77 2,62 2,23 2,23 2,15R15 2,53 2,33 2,47 2,53 2,80 2,13 R15 1,08 1,23 2,23 2,77 2,46 1,69 PRILOGA G TABELA 43: Osnovna statistična analiza KDU glede na metodologijo uvedbe
Veljavni Aritmetmetična sredina Standardni odklon R1 23 2,96 4,385 R2 23 5,00 4,573 R3 22 8,86 4,486 R4 23 5,39 3,590 R5 22 10,23 3,337 R6 22 7,64 3,749 R7 23 7,83 2,774 R8 21 8,67 4,531 R9 22 6,77 3,100 R10 22 7,82 2,822 R11 22 11,36 3,001 R12 22 8,27 3,254 R13 21 12,38 3,201 R14 22 9,23 4,163 R15 22 9,05 4,845 Valid N (listwise) 21
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 managementa R6 - Komunikacija znotraj projektnega tima R7 - Komunikacija med projektnim timom in ostalimi v organizaciji
R8 - Vključevanje zunanjih svetovalcev R9 - Vključitev in sodelovanje uporabnikov R10 - Izobraževanje končnih uporabnikov R11 - Management 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
165
PRILOGA H
Razvrstitev KDU po pomembnosti za lastno metodo uvajanja: 1. Jasni cilji, strategija in obseg uvajanja rešitve (M x= 2,50), 2. Vključitev in sodelovanje uporabnikov (Mx = 4,83), 3. Izobraževanje končnih uporabnikov (Mx = 5,33), 4. Komunikacija med projektnim timom in ostalimi v organizaciji (Mx = 5,83), 5. Organizacija projektnega tima in njegove kompetence (Mx = 6,67), 6. Komunikacija znotraj projektnega tima (Mx = 6,83), 7. Prenova poslovnih procesov (Mx = 7,17), 8. Prenos podatkov iz starih rešitev v rešitev ERP (Mx = 7,50), 9. Čim manj prilagajanja rešitve ERP posebnostim organizacije (Mx = 7,83), 10. Izbira tehnološke arhitekture rešitve ERP (Mx = 8,33), 11. Vključitev in podpora uprave (Mx= 8,50), 12. Vključevanje zunanjih svetovalcev (Mx = 8,67), 13. Aktivna vloga sponzorja projekta (Mx = 9,00), 14. Management sprememb (Mx = 9,3 ), 15. Uporaba principov projektnega managementa (Mx = 10,33).
166
DELOVNI ŽIVLJENJEPIS
1. Osebni podatki Ime in priimek: Simona Sternad Datum rojstva: 12. september 1974 Kraj rojstva: Celje Državljanstvo: Slovensko Naslov: Griže 40 A, 3302 Griže E-naslov: [email protected]; [email protected]
2. Izobraževanje
1981 – 1989 Osnovna šola Griže 1989 – 1993 Srednja ekonomsko-komercialna šola Celje 1993 – 1998 Pedagoška fakulteta Maribor, Univerza v Mariboru
Smer: Računalništvo z matematiko Naslov diplomskega dela: MULTIMEDIJA V IZOBRAŽEVANJU – Analiza multimedijskih gradnikov znotraj programskih jezikov Logo, Visual Basic, Delphi in Visual Cafe (julij, 1998) URL naslov: http://www.pfmb.uni-mb.si/didgradiva/diplome/sternad/
2000 - Podiplomski magistrski študij Ekonomija in poslovne vede na Ekonomsko-poslovni fakulteti Maribor Smer: Poslovna informatika
3. Zaposlitev
09/1998 – 10/2000 III. gimnazija Maribor Profesorica računalništva
11/2000 - Ekonomsko-poslovna fakulteta Maribor, Univerza v Mariboru Asistentka za poslovno informatiko 11/ 2000 – 09/2002 – vodenje vaj pri predmetu Poslovna informatika 10/ 2002 - - vodenje vaj pri predmetu Informatika
167
4. Članki in drugi sestavni deli Izvirni znanstveni članek 1. STERNAD, Simona, GIACOMELLI, Mojca, ZABUKOVŠEK, Uroš. Programski paket LearningSpace kot pripomoček za učenje na daljavo. V: RAJKOVIČ, Vladislav (ur.), URBANČIČ, Tanja (ur.), BERNIK, Mojca (ur.). Vzgoja in izobraževanje v informacijski družbi, (Organizacija, Letn. 33, 2000, št. 8). Kranj: Moderna organizacija, 2000, str. 541-545. [COBISS.SI-ID 2902803]. 2. STERNAD, Simona, BOBEK, Samo. Ocenjevanje kakovosti rešitev ERP z vidika končnih uporabnikov - primer metrike. Organizacija (Kranj), feb. 2005, letn. 38, št. 2, str. 89-97. [COBISS.SI-ID 7961116]. Pregledni znanstveni članek 3. STERNAD, Simona. Kritični dejavniki uvajanj celovite informacijske rešitve SAP po metodi ASAP. Naše gospod., 2003, let. 49, št. 5/6, str. 515-532. [COBISS.SI-ID 14406374]. Strokovni članek 4. STERNAD, Simona, KOSAR, Patricija, GIACOMELLI, Mojca. Videokonference v izobraževanju. V: RAJKOVIČ, Vladislav (ur.), URBANČIČ, Tanja (ur.), BERNIK, Mojca (ur.). Vzgoja in izobraževanje v informacijski družbi, (Organizacija, Letn. 32, 1999, št. 8/9). Kranj: Moderna organizacija, 1999, str. 476-482. [COBISS.SI-ID 2591251]. Objavljeni znanstveni prispevek na konferenci (vabljeno predavanje) 5. BOBEK, Samo, ŠPIČKA, Heri, STERNAD, Simona. A data warehouse based ALM system in a bank. V: LASKER, George Eric (ur.), ENGEMANN, Kurt J. (ur.). Advances in support systems research. Vol. VI, Cybernetic modeling & performance assessment of support systems and processes. Windsor (Ont., Can.): The International Institute for Advanced Studies in Systems Research and Cybernetics, cop. 2001, str. 21-25. [COBISS.SI-ID 6426140]. 6. BOBEK, Samo, POTOČAN, Vojko, STERNAD, Simona, ŠPIČKA, Heri. Information systems in virtual corporations: issues for ERP based E-business systems. V: 2002 Informing Science + IT Education Conference. [Compact disc ed.]. Cork (Ireland): University College Cork, Computer Science Department, 2002, str. 91-96. [COBISS.SI-ID 6371100]. Objavljeni znanstveni prispevek na konferenci 7. STERNAD, Simona, KOSAR, Patricija, GIACOMELLI, Mojca. Videokonferenca pri pouku = Videoconferencing in the classroom. V: ČAMPELJ, Borut (ur.), MAKUC, Alenka (ur.). 4. mednarodna izobraževalna računalniška konferenca - MIRK '99, 19. - 21. maj 1999, OŠ Cirila Kosmača, Piran. Ljubljana: Ministrstvo za šolstvo in šport: Zavod
168
Republike Slovenije za šolstvo: Zavod za odprto družbo, 1999, str. 89-93. [COBISS.SI-ID 5485852]. 8. STERNAD, Simona, GIACOMELLI, Mojca. Digitalni fotoaparat in videokamera ob računalniku Digital Cameras and Webcam. V: ČAMPELJ, Borut (ur.), SIKAVICA, Ines (ur.), LABERNIK, Zvonka (ur.). Mednarodna izobraževalna računalniška konferenca - MIRK 2000, 17. maj - 19. maj 2000, Piran. 1. natis. Ljubljana: Ministrstvo za šolstvo in šport: Zavod Republike Slovenije za šolstvo, program Ro: MIRK - Zavod za projektno in raziskovalno delo na internetu: Akademska in raziskovalna mreža Slovenije, 2000, str. 100-102. [COBISS.SI-ID 5480220]. 9. STERNAD, Simona, GIACOMELLI, Mojca, ZABUKOVŠEK, Uroš. Uporaba programskega paketa LearningSpace kot pripomočka za učenje na daljavo = Use of LearningSpace. V: ČAMPELJ, Borut (ur.), SIKAVICA, Ines (ur.), LABERNIK, Zvonka (ur.). Mednarodna izobraževalna računalniška konferenca - MIRK 2000, 17. maj - 19. maj 2000, Piran. 1. natis. Ljubljana: Ministrstvo za šolstvo in šport: Zavod Republike Slovenije za šolstvo, program Ro: MIRK - Zavod za projektno in raziskovalno delo na internetu: Akademska in raziskovalna mreža Slovenije, 2000, str. 151-152. [COBISS.SI-ID 5480476]. 10. BOBEK, Samo, POTOČAN, Vojko, STERNAD, Simona, ŠPIČKA, Heri. ERP based E-transformation of virtual organizations. V: LASKER, George Eric (ur.). Acta systemica : intelligent systems, (Acta Systemica, Vol. 3, no. 2). Windsor (Ont., Can.): International Institute for Advanced Studies in Systems Reserch and Cybernetics, cop. 2003, str. 19-22. [COBISS.SI-ID 7533340]. 11. STERNAD, Simona, BOBEK, Samo. Critical success factors in ERP solution implementation: management challenges. V: Challenges and prospects : refered proceedings. [Compact disc ed.]. Melaka: Multimedia University, cop. 2005, str. 1055-1072. [COBISS.SI-ID 8112156]. Objavljeni strokovni prispevek na konferenci 12. STERNAD, Simona, GIACOMELLI, Mojca, ZABUKOVŠEK, Uroš. LearningSpace 5 kot pripomoček za učenje na daljavo = LearningSpace 5 as a distance learning teaching tool. V: ADAMIČ MAKUC, Alenka (ur.), MEDICA, Ines (ur.), LABERNIK, Zvonka (ur.). 8. mednarodna izobraževalna računalniška konferenca - MIRK 2003, 15. maj-17. maj 2003, Piran. 1. natis. Ljubljana: Ministrstvo za šolstvo, znanost in šport: Zavod Republike Slovenije za šolstvo: Urad vlade RS za invalide in bolnike: Center Republike Slovenije za poklicno izobraževanje, Služba za EU programe: MIRK - Zavod za projektno in raziskovalno delo na omrežju internet: Akademska in raziskovalna mreža Slovenije; Piran: Osnovna šola Cirila Kosmača, 2003, str. 151-153. [COBISS.SI-ID 6813980]. 13. STERNAD, Simona, BOBEK, Samo. Management znanja pri poučevanju vsebin MS-Office = Toward knowledge management in teaching MS-Office. V: LABERNIK, Zvonka (ur.), VARŠEK, Matjaž (ur.). 10. mednarodna konferenca - MIRK'05, 19. - 21. maj 2005, Osnovna šola Cirila Kosmača Piran. [Zbornik ]. Ljubljana: Ministrstvo za šolstvo in šport: Zavod Republike Slovenije za šolstvo: Center za mobilnost in evropske programe
169
izobraževanja in usposabljanja: Zavod za projektno in raziskovalno delo na omrežju internet: Akademska in raziskovalna mreža Slovenije; Piran: Osnovna šola Cirila Kosmača, 2005, [5] f. [COBISS.SI-ID 8147484]. 14. ZABUKOVŠEK, Uroš, STERNAD, Simona. Virtualna učilnica z MS SharePoint = Virtual classroom with MS SharePoint. V: LABERNIK, Zvonka (ur.), VARŠEK, Matjaž (ur.). 10. mednarodna konferenca - MIRK'05, 19. - 21. maj 2005, Osnovna šola Cirila Kosmača Piran. [Zbornik ]. Ljubljana: Ministrstvo za šolstvo in šport: Zavod Republike Slovenije za šolstvo: Center za mobilnost in evropske programe izobraževanja in usposabljanja: Zavod za projektno in raziskovalno delo na omrežju internet: Akademska in raziskovalna mreža Slovenije; Piran: Osnovna šola Cirila Kosmača, 2005, [6] f. [COBISS.SI-ID 8147740]. Objavljeni povzetek znanstvenega prispevka na konferenci 15. BOBEK, Samo, POTOČAN, Vojko, STERNAD, Simona, ŠPIČKA, Heri. Information systems in virtual corporations: issues for ERP based E-business systems : [session] Working together. V: COHEN, Eli (ur.), BOYD, Elizabeth (ur.). Proceedings, (Informing science, 2002). Cork (Ireland): University College Cork, Computer Science Department, 2002, str. 52. [COBISS.SI-ID 6370076]. 16. STERNAD, Simona, BOBEK, Samo. Critical success factors in ERP solution implementation : management challenges. V: Challenges and prospects : abstract book. Melaka: Multimedia University, cop. 2005, str. 132-133. [COBISS.SI-ID 8112924]. Objavljeni povzetek strokovnega prispevka na konferenci 17. STERNAD, Simona, BOBEK, Samo. Management znanja pri poučevanju vsebin MS-Office = Toward knowledge management in teaching MS-Office. V: LABERNIK, Zvonka (ur.), VARŠEK, Matjaž (ur.). 10. mednarodna konferenca - MIRK'05, 19. - 21. maj 2005, Osnovna šola Cirila Kosmača Piran. [Zbornik povzetkov]. Ljubljana: Ministrstvo za šolstvo in šport: Zavod Republike Slovenije za šolstvo: Center za mobilnost in evropske programe izobraževanja in usposabljanja: Zavod za projektno in raziskovalno delo na omrežju internet: Akademska in raziskovalna mreža Slovenije; Piran: Osnovna šola Cirila Kosmača, 2005, str. 104. [COBISS.SI-ID 8146716]. 18. ZABUKOVŠEK, Uroš, STERNAD, Simona. Virtualna učilnica z MS SharePoint = Virtual classroom with MS SharePoint. V: LABERNIK, Zvonka (ur.), VARŠEK, Matjaž (ur.). 10. mednarodna konferenca - MIRK'05, 19. - 21. maj 2005, Osnovna šola Cirila Kosmača Piran. [Zbornik povzetkov]. Ljubljana: Ministrstvo za šolstvo in šport: Zavod Republike Slovenije za šolstvo: Center za mobilnost in evropske programe izobraževanja in usposabljanja: Zavod za projektno in raziskovalno delo na omrežju internet: Akademska in raziskovalna mreža Slovenije; Piran: Osnovna šola Cirila Kosmača, 2005, str. 139. [COBISS.SI-ID 8146972].
170
Drugi članki ali sestavki 19. STERNAD, Simona. III. gimnazija Maribor. V: WECHTERSBACH, Rado. Predstavitev informacije na spletu : vodnik za izpeljavo sklopa Računalniška omrežja, (Modeli poučevanja in učenja, Računalništvo/informatika). 1. natis. Ljubljana: Zavod Republike Slovenije za šolstvo, 2000, str. 80, str. 101-103. [COBISS.SI-ID 5481244]. 5. Monografije in druga zaključena dela Drugo učno gradito 20. STERNAD, Simona, BOBEK, Samo. Operacijski sistem Microsoft Windows XP za predmeta Informatika in Poslovna informatika : interno gradivo za študente Ekonomsko-poslovne fakultete Maribor. Maribor: Ekonomsko-poslovna fakulteta, Katedra za organizacijo in informatiko, 2004. 46 f., ilustr. [COBISS.SI-ID 7671836]. 21. STERNAD, Simona, ŠPIČKA, Heri, BOBEK, Samo. Opis programov družine Office 97. Predmet informatika : interno gradivo za študente EPF Maribor : (univerzitetni program). Maribor: Ekonomsko-poslovna fakulteta, Katedra za organizacijo in informatiko, 2004. 120 f., ilustr. [COBISS.SI-ID 7585308]. 22. ŠPIČKA, Heri, STERNAD, Simona, BOBEK, Samo. Opis programov družine Office 97. Predmet poslovna informatika : interno gradivo za študente EPF Maribor : (univerzitetni program). Maribor: Ekonomsko-poslovna fakulteta, Katedra za organizacijo in informatiko, 2004. 120 f., ilustr. [COBISS.SI-ID 7585564]. 23. BOBEK, Samo, STERNAD, Simona. Prosojnice predavanj pri predmetu Informatika : interno gradivo za študente EPF Maribor : (univerzitetni program). Maribor: Ekonomsko-poslovna fakulteta, Katedra za organizacijo in informatiko, 2004. 127 f., ilustr. [COBISS.SI-ID 7585820]. 24. STERNAD, Simona, BOBEK, Samo. Urejevalnik besedil Microsoft Word 2003 za predmeta Informatika in Poslovna informatika : interno gradivo za študente Ekonomsko-poslovne fakultete Maribor. Maribor: Ekonomsko-poslovna fakulteta, Katedra za organizacijo in informatiko, 2004. 60 f., ilustr. [COBISS.SI-ID 7690268]. 25. STERNAD, Simona, BOBEK, Samo. Vaje za predmet Informatika : interno gradivo za študente EPF Maribor : (univerzitetni program). Maribor: Ekonomsko-poslovna fakulteta, Katedra za organizacijo in informatiko, 2004. 118 f., ilustr. [COBISS.SI-ID 7586076]. 26. STERNAD, Simona, BOBEK, Samo. Internet in storitve interneta : za predmeta Informatika in Poslovna informatika : interno gradivo za študente Ekonomsko-poslovne fakultete Maribor. Maribor: Ekonomsko-poslovna fakulteta, Katedra za organizacijo in informatiko, 2005. 112 str., ilustr. [COBISS.SI-ID 7898396].
171
Diplomsko delo 27. STERNAD, Simona. Multimedija v izobraževanju : analiza multimedijskih gradnikov znotraj programskih jezikov v Logo, Visual Basic, Delphi in Visual Cafe : diplomsko delo, (Pedagoška fakulteta, Maribor, Matematika). Maribor: [S. Sternad], 1998. 124 f., ilustr. [COBISS.SI-ID 7445768]. Končno poročilo o rezultatih raziskav 28. GERLIČ, Ivan, JAUŠOVEC, Norbert, SABADIN, Argio, KRAŠNA, Marjan, PAPOTNIK, Amand, DUH, Matjaž, BRATINA, Tomaž, ČRETNIK, Borut, OBREHT, Tone, STERNAD, Simona. Didaktični vidiki uporabe računalnika in sodobne informacijske tehnologije v izobraževalnem sistemu Slovenije : poročilo o strateškem projektu RO za leto 2000, (Računalniško opismenjevanje). Maribor: Univerza v Mariboru, Pedagoška fakulteta, Center za računalništvo, informatiko in multimedije v izobraževanju, 2000. 48 f., ilustr. [COBISS.SI-ID 10442760]. Elaborat, predštudija, študija 29. KOROŠEC, Bojana, BEKŐ, Jani, DUH, Mojca, LOGOŽAR, Klavdij, SNOJ, Boris, STERNAD, Simona, TOMINC, Polona. Samoevalvacija dodiplomskega študija. Maribor: Ekonomsko-poslovna fakulteta, 2003. 41 f., tabele. [COBISS.SI-ID 7112732]. 6. Izvedena dela (dogodki) Prispevek na konferenci brez natisa 30. BOBEK, Samo, ŠPIČKA, Heri, STERNAD, Simona. A data-warehouse based ALM system : paper presented at the 13th International Conference on System Research, Informatics and Cybernetics, July 30 - August 4, 2001 in Baden-Baden, Germany. Baden-Baden, 2. avg. 2001. [COBISS.SI-ID 5823260]. Druga izvedena dela 31. GIACOMELLI, Mojca, OREL, Mojca, STERNAD, Simona, KOSAR, Patricija, SAJEVIC, Zdravko, ŽIVKOVIČ, Miha. Možnosti uporabe digitalnega fotoaparata : od ideje do izdelave plakata. Možnosti uporabe digitalne videokamere v izobraževanju : od ideje do izdelave video posnetka : delavnica na Mednarodni izobraževalni računalniški konferenci, MIRK 99, 19. maj - 21. maj 1999, Piran. Piran, maj 1999. [COBISS.SI-ID 5486364]. 7. Dodatna izobraževanja
December 2004 Pef, Maribor. Odprta koda. Junij, 2004 Bled, Slovenija. 17 eCommerce Conference. Junij, 2004 Microsoft, Ljubljana. Priprava delovnega okolja za učinkovito delo
(2 dnevni seminar). Junij, 2004 ARIS, Ljubljana. Predstavitev orodja ARIS.
172
April, 2004 EPF, Maribor. Delavnica prof. Beaty: Cases in economics. (1 dan). Marec, 2004 Oracle, Ljubljana. Oracle E-Business Suite aplikacije in novosti pri
razvoju. Marec, 2004 Microsoft, Maribor. Roadshow 2004.
December, 2003 Microsoft, Ljubljana. Office 2003 za IT strokovnjake. (2 dnevni seminar).
November, 2003 Microsoft, Ljubljana. Prva uradna predstavitev programa Microsoft Office 2003.
Oktober, 2003 Microsoft, Ljubljana. Aktivni imenik v Microsoft Windows Server 2003 (1 dnevni seminar).
Oktober, 2003 Ljubljana, INFOS 2003. Oktober, 2003 Univerza v Mariboru, ENQA AND THE AGENDA FOR
EUROPEAN QUALITY ASSURANCE AFTER BERLIN. September, 2003 Microsoft, Ljubljana. Uvodni pregled strežnika MS Windows
Server 2003 (1 dnevni seminar). Junij, 2003 Comtron, Maribor. Uvajanjev rešitev ERP TRON InterCenter. Junij 2003 TF, Maribor. Objektna tehnologija v Sloveniji, OTS 2003.
November, 2002 Microsoft, Ljubljana. Smernice za arhitekturo spletnih storitev XML (2 dnevni seminar).
Junij 2002 Filozofska fakulteta Ljubljana. Didaktika v visokem šolstvu (3 dnevna delavnica).
Marec 2002 FOV, Kranj. Izboljšanje konkurenčnosti v regiji z e-poslovanjem:e-praksa in ustvarjanje e-ekonomije – peto posvetovanje direktorjev.
januar 2002 IZUM, Maribor. “Specialna šola interneta za raziskovalce” (2 dnevni seminar).
Junij 2001 TF, Maribor. Objektna tehnologija v Sloveniji, OTS 2001. (konferenca).
februar 2001 Center za razvoj študija na daljavo, Univerza v Mariboru. Seminar z naslovom “Sodobni učni pripomočki in metode poučevanja”.
Junij 2000 TF, Maribor. Objektna tehnologija v Sloveniji, OTS 2000. (konfeneca).
Junij, 2000 Zavod republike Slovenije za šolstvo. Oblikovanje interaktivnega učnega gradiva za svetovni splet (2 dnevni seminar).
November, 1999 Zavod republike Slovenije za šolstvo. Računalništvo – Spletna stran.
Februar, 1999 Much. Izobraževanje pedagoških delavcev za novosti na področju programske opreme I – Predstavitve-izobraževalna gradiva-računalnik (3 dnevni seminar).
Februar, 1999 Much. Didaktika pouka računalništva in informatike.(2 dnevni seminar).
Januar, 1999 Much. Objektno programiranje in programski jezik Java – začetni. (3 dnevni seminar).
December, 1998 Much, Ljubljana. Upravljanje sistema Microsoft Windows NT strežnik (4 dnevni seminar).
December, 1998 Much, Ljubljana. Izobraževanje pedagoških delavcev za novosti na področju programske opreme III – Šolski kadrovski IS (1 dnevni
173
seminar). September, 1998 Zavod republike Slovenije za šolstvo. Informatika v srednji šoli. (3
dnevni seminar). 8. Komisije
2002 - 2005 Komisija za ocenjevanje kakovosti na EPF Maribor. 2002 - 2003 Članica skupine za prenovo spletnih strani EPF Maribor.
9. Dodatno
Julij 2005 Vodenje tečaja “Organizator MS Outlook 2003” v obsegu 15 ur za zaposlene na EPF Maribor.
Pomlad 2004 Vodenje tečaja Osnove Windows XP in Office XP v obsegu 30 ur za zaposlene na EPF Maribor.
Jeseni 2003 Postavitev intraneta za katedro za organizacijo in informatiko (http://epf-oi.uni-mb.si:9000).
Oktober, 2003 Vodenje sekcije strokovnih člankov na 3. konferenci študentov podiplomskega študija Ekonomsko-poslovne fakultete Maribor.
Maj 2003 Vodenje tečaja Osnove Windows NT in Office 97 v obsegu 30 ur za zaposlene na EPF Maribor.
Pomladi 2002 Soavtorica spletnega mesta Katalog znanja za predmeta Informatika in Poslovna informatika. (http://epf-oi.uni-mb.si/katalog/)
Jeseni 2001 Postavitev spletnega in ftp strežnika katedre za organizacijo in informatiko (http://epf-oi.uni-mb.si) ter postavitev foruma katedre (http://epf-oi.uni-mb.si/forum).
Jeseni 2001 - Snovalka in urednica spletnih strani katedre za organizacijo in informatiko.
Pomladi 2001 EPF, Maribor. Asistentka pri vodenju tečaja PowerPoint 97 za zaposlene na EPF.
Januar, 2000 Zavod republike Slovenije za šolstvo. Sodelovala z ZRSŠ pri izobraževanju pedagoških in drugih strokovnih delavcev v vzgoji in izobraževanju na področju računalniškega izobraževanja – 1- krat kot predavateljica.
December, 1999 Ministrstvo za šolstvo in šport. Opravljen strokovni izpit za nižje in srednje poklicno izobraževanje.
1999 - 2000 Mentorica dvema študentkama na pedagoški praksi 1999 -2000 Priprava na nastop in izvedba nastopov študentov Pef, Maribor,
smer Računalništvo z matematiko. 1999 - 2000 Zavod republike Slovenije za šolstvo. Informatika za srednje šole –
opisni kriteriji ocenjevanja. 1999 -2000 Zavod republike Slovenije za šolstvo. Projekt TIMKO -
sodelovalno učenje med predmeti v drugem letniku. 1999 -2000 Zavod republike Slovenije za šolstvo. Preverjanje in ocenjevanje
znanja pri predmetu Računalništvo in informatika. 1998 - 1999 Zavod republike Slovenije za šolstvo. Projekt PIPI – predhodno
izvajanje predmeta Informatika v srednji šoli. Oktober, 1998 Postavitev spletnega strežnika na III. gimnaziji v Mariboru.
