UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN

INFORMATIKO

MAGISTRSKA NALOGA

METODOLOGIJA ZA IZBIRO VRSTE INFORMACIJSKEGA SISTEMA

Avtor: Oder Nikolaj Mentor: prof. dr. Rozman Ivan Komentor: izr. prof. dr. Heričko Marjan Celje, maj 2008

1

Kazalo

Seznam slik............................................................................................................. 3 Seznam tabel .......................................................................................................... 3 Povzetek ................................................................................................................. 4 Summary................................................................................................................. 4 1 Uvod..................................................................................................................... 5

1.1 Namen in cilj raziskave.................................................................................. 5 1.2 Osnovne teze oziroma trditve raziskave........................................................ 6 1.3 Predpostavke in omejitve raziskave .............................................................. 6 1.4 Predvidene metode raziskovanja................................................................... 6 1.5 Osnovni pojmi................................................................................................ 7

2 Predstavitev možnosti pri izbiri vrste informacijskega sistema............................. 8 2.1 Upravljanje z viri v podjetju - ERP ................................................................. 8 2.2 Upravljanje preskrbovalne verige – SCM .................................................... 13 2.3 Upravljanje odnosov s strankami – CRM..................................................... 14 2.4 Upravljanje odnosov z dobavitelji – SRM .................................................... 15 2.5 Tipi informacijskih sistemov......................................................................... 15

2.5.1 Standarden celovit informacijski sistem ................................................ 17 2.5.2 Integracija najboljših rešitev (BoB)........................................................ 18 2.5.3 Razvoj informacijskega sistema po meri............................................... 19

3 Primerjava metodologij izbire informacijskih sistemov ....................................... 21 3.1 Izbor in ovrednotenje ponudnika: ERP ogrodje ........................................... 21 3.2 FACT analiza za ovrednotenje možnosti razvoja programske opreme........ 25 3.3 Ogrodje za predhodno izbiro ERP sistema.................................................. 28 3.4 Ogrodje za izbiro ERP paketov za majhna, srednja in velika podjetja ......... 30 3.5 Splošno ogrodje za izbiro ERP sistema....................................................... 31 3.6 Umestitev prilagojene metodologije izbire tipa informacijskega sistema ..... 31

4 Prilagojena metodologija izbire tipa informacijskega sistema ............................ 33 4.1 Priprava projekta ......................................................................................... 34 4.2 Definiranje variant........................................................................................ 34 4.3 Določitev vidikov in njihovih komponent ...................................................... 35

4.3.1 Tehnološki vidik .................................................................................... 35 4.3.2 Vsebinski vidik ...................................................................................... 35 4.3.3 Stroškovni vidik ..................................................................................... 36 4.3.4 Ostali vidiki............................................................................................ 36

4.4 Določitev uteži in ovrednotenje pomembnosti vidikov ................................. 36 4.4.1 Določitev tipa podjetja........................................................................... 36 4.4.2 Uteži glede na specifičnost poslovnih procesov.................................... 37

4.4.2.1 Tehnološki vidik.............................................................................. 37 4.4.2.2 Vsebinski vidik................................................................................ 38 4.4.2.3 Stroškovni vidik .............................................................................. 39 4.4.2.4 Ostali vidiki ..................................................................................... 39

4.4.3 Ovrednotenje pomembnosti vidikov ...................................................... 40 4.5 Izračun ocen variant .................................................................................... 40 4.6 SWOT matrika (S - prednosti, W - slabosti, O - priložnosti, T - nevarnosti) . 41 4.7 Končni izbor................................................................................................. 42

5 Apliciranje prilagojene metodologije na primeru podjetja Lisca d.d.................... 43 5.1 Predstavitev podjetja ................................................................................... 43 5.2 Predstavitev celovitih informacijskih sistemov ............................................. 43

2

5.2.1 SAP....................................................................................................... 44 5.2.2 Navision / Microsoft Dynamics NAV...................................................... 46 5.2.3 Oracle ................................................................................................... 48

5.3 Predstavitev razvojnih platform ................................................................... 49 5.3.1 Razvojne platforme ............................................................................... 50 5.3.2 IBM Rational Application Developer za WebSphere ............................. 51 5.3.3 Microsoft Visual Studio ......................................................................... 54

5.4 SOA (Service-Oriented Architecture)........................................................... 56 5.5 Povezovanje arhitektur Java EE in .NET..................................................... 59 5.6 Izbor ............................................................................................................ 59

5.6.1 Priprava projekta................................................................................... 60 5.6.2 Definiranje variant ................................................................................. 60 5.6.3 Določitev ocen vidikov in njihovih komponent ....................................... 61

5.6.3.1 Tehnološki vidik.............................................................................. 61 5.6.3.2 Vsebinski vidik................................................................................ 62 5.6.3.3 Stroškovni vidik .............................................................................. 62 5.6.3.4 Ostali vidiki ..................................................................................... 62

5.6.4 Določitev uteži in ovrednotenje pomembnosti vidikov........................... 63 5.6.4.1 Določitev tipa podjetja .................................................................... 63 5.6.4.2 Uteži glede na specifičnost poslovnih procesov ............................. 64 5.6.5.3 Ovrednotenje pomembnosti vidikov ............................................... 64

5.6.5 Skupna ocena....................................................................................... 64 5.6.6 SWOT matrika ...................................................................................... 67 5.6.7 Končni izbor .......................................................................................... 69

6 Zaključek............................................................................................................ 70 7 Slovar izrazov .................................................................................................... 72 8 Literatura in viri .................................................................................................. 75

8.1 Literatura ..................................................................................................... 75 8.2 Viri ............................................................................................................... 76

3

Seznam slik

Slika 1. Koncept ERP (Davenport 1998)..................................................................... 9 Slika 2: Položaj največjih ponudnikov ERP sistemov (Spies 2003) .......................... 12 Slika 3: Integracija ključnih poslovnih procesov (Lambert et al. 1998)...................... 13 Slika 4: Komponente CRM (Gray, Byun 2001) ......................................................... 15 Slika 5: FACT analiza (povz. po Kyte 2007) ............................................................. 26 Slika 6: Glavne faze življenjskega cikla ERP sistemov (povz. po Stefanou 2001).... 29 Slika 7: Splošni model procesa izbire ERP sistema (povz. po Bernroider in Koch

2002) ................................................................................................................. 30 Slika 8: Združeni vidiki predstavljenih metodologij (Kyte 2007, Lebinski 2001,

Stefanou 2001, Wei in Wang 2004)................................................................... 32 Slika 9: Shema prilagojene metodologije.................................................................. 34 Slika 10: Uporaba tehnologij Java EE in .NET (Hoppermann 2005)......................... 50 Slika 11: Primerjava uporabe tehnologij v razvojnih projektih (Wilkoff 2004)............ 51 Slika 12: IBM Rational Application Developer za WebSphere (povz. po Wahli et al.

2007) ................................................................................................................. 52 Slika 13: SOA Meta Model (The Linthicum Group 2007).......................................... 57 Slika 14: Arhitektura storitvenega vodila (ESB) (IBM 2007)...................................... 58

Seznam tabel

Tabela I: Integracija opravil s tehnologijo MRP, MRP II IN ERP (Chung in Snyder 2000) ................................................................................................................. 10

Tabela II: Največji ponudniki ERP sistemov (AMR Research 2005)......................... 11 Tabela III: Primerjava različnih tipov informacijskih sistemov (povz. po Murthi 2002)16 Tabela IV: Tabela uteži – tehnološki vidik................................................................. 37 Tabela V: Tabela uteži – vsebinski vidik ................................................................... 38 Tabela VI: Tabela uteži – stroškovni vidik................................................................. 39 Tabela VII: Tabela uteži – ostali vidiki ...................................................................... 39 Tabela VIII: SWOT matrika....................................................................................... 41 Tabela IX: Primerjava arhitektur Java EE in .NET (Estes, Maxime 2003) ................ 59 Tabela X: Tabela ocen – tehnološki vidik ................................................................. 61 Tabela XI: Tabela ocen – vsebinski vidik.................................................................. 62 Tabela XII: Tabela ocen – stroškovni vidik ............................................................... 62 Tabela XIII: Tabela ocen – tehnološki vidik .............................................................. 62 Tabela XIV: Specifični procesi .................................................................................. 63 Tabela XV: Tabela uteži ........................................................................................... 64 Tabela XVI: Skupna ocena (tip S3/K2) ..................................................................... 64 Tabela XVII: Skupna ocena (tip S1/K1) .................................................................... 65 Tabela XVIII: Korigirana tabela uteži ........................................................................ 66 Tabela XIX: Skupna ocena – korigirane uteži........................................................... 66 Tabela XX: SWOT matrika – varianta A ................................................................... 67 Tabela XXI: SWOT matrika – varianta B .................................................................. 68 Tabela XXII: SWOT matrika – varianta C ................................................................. 68

4

Povzetek

V magistrski nalogi so analizirane in raziskane različne možnosti, ki jih imamo pri izbiri primernega tipa informacijskega sistema. Prvi del naloge vsebuje predstavitev celovitih informacijskih sistemov. Predstavljene so obstoječe metodologije za izbor primernega informacijskega sistema. Teoretično je razvita prilagojena metodologija, ki je lahko pripomoček pri izbiri prave rešitve. Drugi del naloge vsebuje predstavitev metodologije na konkretnem primeru. V zaključku so predstavljene ugotovitve in predlogi za izvedbo projekta izbire primernega tipa informacijskega sistema.

Summary

While choosing a suitable type of information system, different possibilities are analyzed and researched in the dissertation. First part contains presentation of enterprise-wide information systems. Existing methodologies for the appropriate information system selection are presented. Modified methodology, which can be very helpful while choosing the right solution, is developed theoretically. Usage of the methodology on real case is presented in the second part. Findings and proposals for realization of the project – choosing the suitable type of information system are introduced in conclusion.

5

1 Uvod

V podjetjih se med poslovanjem odvija veliko bolj ali manj kompleksnih poslovnih procesov. Teh procesov je navadno toliko, da potrebujemo informacijski sistem, ki omogoča pregled nad procesi in njihovo obvladovanje. Idealen informacijski sistem bi moral vsebovati sliko celotnega dogajanja v podjetju, to pa pomeni podporo vsem poslovnim procesom, ki se odvijajo v podjetju. Nekateri poslovni procesi so unikatni v določenem podjetju. Pri unikatnih poslovnih procesih je zelo pomembno ločiti med procesi, ki so unikatni zaradi ustaljenega načina dela in bi jih lahko učinkovito nadomestili s standardnimi procesi (najboljše prakse, angl. »best practices«), in procesi, ki vsebujejo znanja in postopke, ki predstavljajo konkurenčno prednost podjetja, v katerem se odvijajo, in bi jih bilo nesmiselno nadomeščati s standardnimi procesi. Zelo pomembno je, da slednje podpremo z informacijskim sistemom točno takšne, kot so, kajti v nasprotnem primeru izgubljamo konkurenčno prednost. Tako v podjetjih z veliko specifičnimi poslovnimi procesi potrebujemo zelo fleksibilen in prilagodljiv informacijski sistem, v podjetjih z večinoma standardnimi poslovnimi procesi pa lahko le-te spremljamo s standardno informacijsko rešitvijo. Podjetja se tako soočajo z vprašanjem, kakšen informacijski sistem je najprimernejši za podporo njihovega poslovanja. Izbira primernega informacijskega sistema je ključna za doseganje tako operativnih kot strateških ciljev ter za kvalitetno podporo odločanju (Rosenthal, Salzman 1990). Glede na strateško naravo celovitih informacijskih sistemov in glede na njihov vpliv na organizacijo, tehnologijo in obnašanje v podjetjih je potreben zelo širok pogled pri izbiri in vpeljavi celovitih informacijskih sistemov v podjetje (Stefanou 2001). Stefanou (2001) ugotavlja, da je veliko znanstvene literature posvečene celovitim informacijskim sistemom, vendar pa je zelo malo pozornosti posvečene načinu izbire in primernosti izbrane informacijske rešitve. Pregled objavljenih del nam pokaže, da je večina raziskav na področju celovitih informacijskih sistemov posvečena fazi implementacije (Esteves, Pastor 2001). Tudi Sammon in Adam (2004) ugotavljata, da je pozornost raziskovalcev in vodstva osredotočena na določene faze projekta uvedbe celovitega informacijskega sistema, medtem ko so druge faze zanemarjene. Predvsem je premalo obdelano vprašanje izbire določene informacijske rešitve, premalo so analizirani razlogi, zakaj je izbrana določena varianta. V nalogi se bomo tako osredotočili na osnovno vprašanje, kako izbrati primeren tip informacijskega sistema.

1.1 Namen in cilj raziskave

V prvem delu magistrske naloge so predstavljena teoretična izhodišča, narejena je primerjava obstoječih metodologij, iz njih pa je izpeljana prilagojena metodologija, s pomočjo katere lahko ocenimo potrebe podjetja in se na podlagi teh odločimo, kakšen tip informacijskega sistema je za to podjetje najprimernejši. Metodologija zajema tri tipe informacijskih sistemov:

1. Standarden celovit informacijski sistem

6

2. Integracija najboljših rešitev – BoB (angl. »Best-of-Breed«) 3. Razvoj informacijskega sistema po meri

V drugem delu naloge je predstavljena metodologija, prikazana v kontekstu izbire tipa informacijskega sistema v podjetju Lisca d.d.. Zaključek naloge vsebuje ugotovitve in smernice pri izvedbi projekta izbire.

1.2 Osnovne teze oziroma trditve raziskave

Za odločitev o izbiri vrste informacijskega sistema je možno določiti odločitvene kriterije, iz katerih lahko sestavimo splošno uporabno metodologijo, ki je dovolj preprosta, da je primerna za uporabo v podjetjih v začetnih fazah izbire brez obširnih raziskav. Med variantami je dovolj pomembnih razlik, da daje metodologija uporabno informacijo, ki je lahko v pomoč pri sprejemanju odločitve.

1.3 Predpostavke in omejitve raziskave

Predpostavljamo, da zbrane, do sedaj opravljene, raziskave s področja implementacije različnih informacijskih sistemov predstavljajo dovolj kvaliteten vzorec, ki ga je možno posplošiti na vsa podjetja. Omejili se bomo na odločitev o izbiri standardnega celovitega informacijskega sistema, BoB ali razvoj sistema po meri s pomočjo kriterijev, ki so značilni za posamezni pristop. Ne bomo obravnavali drugih odločitev, povezanih z implementacijo za izbrani pristop, kot na primer izbira primernih programskih rešitev ali odločitev o načinu prehoda na celovit informacijski sistem. Metodologija bo namenjen podjetjem, katerih poslovanje je stabilno in katerih namen je predvsem uvesti računalniško podporo informacijskega sistema in ne zmanjševati stroške.

1.4 Predvidene metode raziskovanja

V prvi fazi bomo z metodo deskripcije in metodo kompilacije podrobno identificirali problem. Kjer bo to potrebno, bomo podatke o problemu, zbrane z raziskavami s komparativno metodo, združili ali razstavili tako, da bodo primerni za uporabo v metodologiji. Manjkajoče podatke o uporabi najsodobnejših arhitektur (npr. SOA) bomo zaradi aktualnosti končnega modela dopolnili z empirično raziskavo. Pripravili bomo strukturo metodologije. Definirali bomo vidike, njihove komponente ter njihovo pomembnost. Nepomembne komponente, podvojene komponente in komponente, ki nimajo vpliva na končno odločitev, bomo izločili. Definirali bomo uteži, ki bodo korigirale rezultat glede na količino specifičnih poslovnih procesov. Določili bomo nabor vrednosti posamezne komponente vidika. Izbrali bomo ustrezno metodo za obravnavanje vidikov.

7

Za vse tri alternative bomo definirali uteži s pomočjo podatkov, zbranih s kompilacijo v začetku raziskave. Zaradi ilustracije bomo ovrednotili in analizirali alternative na primeru podjetja Lisca.

1.5 Osnovni pojmi

Preden pričnemo z opisom komponent celovitih informacijskih rešitev, definirajmo nekaj osnovnih pojmov, ki so pomembni za razumevanje raziskave. Celovit informacijski sistem lahko opredelimo kot celovito povezano in na poslovnem modelu organizacije temelječo sestavo uporabniških programov, ki ob uporabi sodobne informacijske tehnologije zagotavlja vsem poslovnim procesom, tako same organizacije kot tudi z njo povezanih poslovnih partnerjev, optimalne možnosti načrtovanja, razporejanja virov in ustvarjanja dodane vrednosti. Tip oz. vrsta informacijskega sistema definira zgradbo in način pridobitve informacijskega sistema. Poslovni proces lahko definiramo kot nabor ene ali več procedur ali aktivnosti, ki skupaj realizirajo poslovne cilje, navadno v kontekstu organizacijske strukture, ki definira funkcionalne vloge in relacije med njimi. Najboljša praksa je tehnika ali metodologija, ki se je skozi izkušnje in raziskovanje izkazala, da zanesljivo vodi k določenemu rezultatu. BoB (angl. »Best-of-breed«) v kontekstu informacijskih sistemov pomeni uporabo najboljše specifične programske rešitve za vsako specifično področje ali zahtevo.

8

2 Predstavitev možnosti pri izbiri vrste informacijskega sistema

Preden predstavimo različne možnosti pri izbiri informacijskega sistema, moramo podrobneje predstaviti glavne komponente celovitih informacijskih sistemov:

- upravljanje z viri v podjetju - ERP (angl. »Enterprise Resource Planning«), - upravljanje preskrbovalne verige - SCM (angl. »Supply Chain Management«), - upravljanje odnosov s strankami - CRM (angl. »Customer Relationship

Management«), - upravljanje odnosov z dobavitelji - SRM (angl. »Supplier Relationship

Management«). ERP skupaj z dodatnimi rešitvami za povezavo z internetom, kot so npr. rešitve za upravljanje odnosov s strankami ali CRM in rešitve za upravljanje odnosov z dobavitelji ali SRM, tvori celovito informacijska rešitev. Pri AMR Research označujejo koncept s kratico ECM (angl. »Enterprise Commerce Management«) ali upravljanje podjetniškega trgovanja (Mullin 2001). Drugi avtorji vpeljejo koncept razširjeni ERP (angl. »Extended ERP«) (Chen 2001). Ugotovimo, da nekateri viri (Davenport 1998) vključujejo CRM in SCM v ERP, drugi (Mullin 2001) pa vpeljejo razširjen pojem, ki zajema komponente ERP, SRM in CRM v širšo celoto. V praksi se izkaže, da največji ponudniki celovitih informacijskih sistemov (SAP, Oracle) v zadnjem času ponujajo celovite rešitve, ki zajemajo komponente ERP, CRM, SCM in SRM. V nalogi bomo obravnavali ERP v ožjem smislu, brez komponent CRM, SCM in SRM. Z izrazom celovit informacijski sistem bomo obravnavali vse komponente poslovnega informacijskega sistema, torej ERP, CRM, SCM in SRM.

2.1 Upravljanje z viri v podjetju - ERP

ERP (»Enterprise Resource Planning«) sistemi so namenjeni upravljanju s poslovanjem in vsebujejo module podpornih funkcijskih področij, kot so planiranje, proizvodnja, prodaja, marketing, distribucija, računovodstvo, finance, upravljanje s človeškimi viri, upravljanje s projekti, upravljanje z zalogami, storitve in vzdrževanje, transport in e-poslovanje. Arhitektura programske opreme omogoča transparentno integracijo modulov, kar se odraža v konsistentnem toku informacij med vsemi funkcijskimi enotami v podjetju. American Production and Inventory Control Society (APICS 2001) je definirala ERP sisteme kot »metoda za učinkovito planiranje in upravljanje z vsemi viri, ki so potrebni za prevzem naročil kupcev ter izdelavo, distribucijo in obračunavanje naročenega blaga, izdelkov ali storitev v proizvodnih, distribucijskih ali storitvenih podjetjih«. Druga definicija se glasi: »ERP sistem je komercialni programski paket, ki omogoča neomejeno integracijo vseh informacij, ki tečejo v podjetju – informacije, ki se nanašajo na finance, računovodstvo, človeške vire, preskrbovalno verigo in kupca« (Davenport 1998).

9

Slika 1. Koncept ERP (Davenport 1998) Evolucija ERP sistemov:

- 1960-1970: ICP (angl. »Inventory Control Packages«) V tem času je večina podjetij uporabljala centralizirane računalniške sisteme predvsem za avtomatizacijo svojih sistemov upravljanja z imetjem. Ti sistemi so temeljili na programskih jezikih, kot so COBOL, ALGOL in FORTRAN.

- 1970-1980: MRP (angl. »Material Requirements Planning«) MRP sistemi so omogočali planiranje potreb po materialu oz. polizdelkih, glede na plan proizvodnje.

- 1980-1990: MRP II (angl. »Manufacturing Resources Planning«) MRP II je omogočal optimizacijo proizvodnih procesov s sinhronizacijo materialov in proizvodih zahtev.

- 1990-2000: ERP (angl. »Enterprise Resource Planning«) ERP sistemi temeljijo na MRP in MRP II in integrirajo naslednje poslovne procese: proizvodnjo, distribucijo, računovodstvo, finance, upravljanje s človeškimi viri, upravljanje s projekti, upravljanje z zalogami in imetjem, storitve in vzdrževanje, transport. Omogočajo dostopnost, transparentnost in konsistentnost vseh informacij, ki se pojavljajo v podjetju.

- 2000- … : Razširjen ERP (angl. »Extended ERP«) V zadnjem času je dodanih precej modulov in funkcij v klasične ERP sisteme: APS (angl. »Advanced Planning and Scheduling«), e-poslovanje, CRM (angl. »Customer Relationship Management«) in SCM (angl. »Supply Chain Management«).

D O B A V I T E L J I

K U P C I

Zunanji procesi (Front-Office)

Notranji procesi (Back-Office)

Centralna baza

podatkov

Upravljanje s človeškimi viri

Prodaja in distribucija

Servisne aplikacije

Finančne aplikacije

Aplikacije za proizvodnjo

Upravljanje z imetjem

Poročila na nivoju korporacije

10

Običajno so rešitve ERP sestavljene iz več med seboj integriranih modulov. Ta delitev daje podjetjem možnost, da implementirajo samo potrebne dele celotne rešitve. Tipična rešitev med drugimi vključuje module, ki jih prikazuje tabela I. Tabela I: Integracija opravil s tehnologijo MRP, MRP II IN ERP (Chung in Snyder

2000) Možna stopnja integracije Tehnološka povezanost MRP MRP II ERP Kosovnice Nizka Visoka Visoka Glavni plan Nizka Srednja Visoka Planiranje kapacitet Nizka Srednja Visoka Aktivnosti vrednostne verige Nizka Srednja Visoka Napovedovanje povpraševanja Nizka Nizka Visoka Metodologija razvoja izdelkov Nizka Nizka Visoka Upravljanje podatkov Nizka Srednja Visoka Odlagališče procesov Nizka Srednja Visoka Povezljivost IT Nizka Srednja Visoka Ključni moduli ERP sistemov (Davenport 1998):

- upravljanje računovodstva, - upravljanje s financami, - upravljanje proizvodnje, - upravljanje transporta, - upravljanje s prodajo in distribucijo, - upravljanje s človeškimi viri, - upravljanje preskrbovalne verige (SCM), - upravljanje odnosov s strankami (CRM), - e-poslovanje.

Rešitve ERP imajo naslednje lastnosti (O'Leary 2002):

- so gotove programske rešitve, ki delujejo v okolju odjemalec/strežnik, ne glede na to ali uporabljajo običajne ali spletne odjemalce;

- integrirajo večino poslovnih procesov v podjetju; - obdelajo večino transakcij v podjetju; - uporabljajo podatkovno bazo na ravni podjetja, v kateri je običajno vsak

podatek zapisan samo enkrat; - omogočajo dostop do podatkov v realnem času in - v nekaterih primerih omogočajo integracijo obdelave transakcij in aktivnosti

planiranja (npr. pri planiranju proizvodnje). V svoji osnovni obliki ERP ne podpira informacijskih sistemov za upravljanje – MIS (angl. »Management Information System«), čeprav zagotavlja za to potrebne zgoščene informacije in ne vključuje podpore za neposredno vodenje proizvodnih procesov – MES (angl. »Manufacturing Executive System«) ter neposrednega

11

zajemanja in vrednotenja podatkov iz proizvodnega procesa – SCADA (angl. »System Control and Data Acquisition«) (Ljubič 2001). ERP sistemi tečejo na različnih platformah (Unix, MS Windows, IBM AIX, HP-UX, Linux) in različnih podatkovnih bazah (MS SQL Server, Oracle, DB2) (Hossain et al. 2002). Na svetovnem trgu obstaja precej ponudnikov celovitih ERP sistemov. Največji so SAP, Oracle, PeopleSoft (prevzel ga je Oracle v 2005), J. D. Edwards (prevzel ga je PeopleSoft v 2003), Navision / Microsoft Dynamics (Spies 2003). Tabela II prikazuje njihove tržne deleže. Tabela II: Največji ponudniki ERP sistemov (AMR Research 2005)

Zap. št. Ime podjetja

Prihodki, 2003 ($M)

Prihodki, 2004 ($M)

Tržni delež 2003

Tržni delež 2004

Rast 2003 - 2004

1 SAP 7994 9372 39 % 40 % 17 % 2 PeopleSoft 2682 2880 13 % 12 % 7 % 3 Oracle 2470 2465 12 % 10 % -0 % 4 Sage Group 900 1243 4 % 5 % 38 %

5 Microsoft Business Solutions

683 775 3 % 3 % 14 %

6 SSA Global 471 700 2 % 3 % 46 % 7 Geac 431 445 2 % 2 % 3 % 8 Intentia 361 388 2 % 2 % 8 % 9 Infor Global Solutions 123 375 1 % 2 % 205 %

10 Lawson 341 357 2 % 2 % 5 % SKUPAJ (z ostalimi ERP ponudniki)

20711 23649 100 % 100 % 14 %

Slika 2 prikazuje položaj največjih ponudnikov ERP sistemov.

12

Slika 2: Položaj največjih ponudnikov ERP sistemov (Spies 2003) V Sloveniji je zaradi njene majhnosti situacija precej drugačna. Večine ponudnikov sploh ni prisotnih, namesto njih pa je veliko slovenskih programerskih hiš, ki ponujajo ERP rešitve za manjša in srednja podjetja. V Sloveniji tako pri rešitvah za večja podjetja prevladujejo naslednji ponudniki: SAP Slovenija (30,7 %, rešitev SAP), Kopa (16,8 %, lastna rešitev), ITS Intertrade (12,2 %, rešitev BaaN), MAOP (10,5 %, rešitev IFS in lastna rešitev), Perftech (9,6 %, lastna rešitev). Pri majhnih in srednjih podjetjih prevladuje rešitev Navision, ki ponuja cenovno relativno ugodno varianto, prav tako pa je čas uvedbe precej kratek (Oh 2000). Implementacija ERP sistema je zelo zahteven projekt, ki v praksi velikokrat ni uspešen. V letu 2001 je Standish Group naredila raziskavo implementacij ERP sistemov v ameriških podjetjih, ki imajo prihodke večje od 500 milijonov $. V raziskavi je zajetih okrog 30.000 projektov. Rezultati so naslednji (Standish Group 2001):

- 35 % je bilo prekinjenih projektov, - 55 % je preseglo proračun, - manj kot 10 % je bilo izvedenih v predvidenem času in v okviru proračuna.

Povprečni rezultati uvedbe ERP sistema:

- stroški: 178 % preseganje proračuna, - terminski plan: 230 % presežen,

13

- funkcionalnost: –59 % (z drugimi besedami, uveden sistem podpira samo 41 % funkcij, za katere je bil predviden).

2.2 Upravljanje preskrbovalne verige – SCM

Upravljanje preskrbovalne verige je integracija ključnih poslovnih procesov od končnega uporabnika do izhodiščnega dobavitelja, ki zagotavlja izdelke, storitve in informacije z določeno dodano vrednostjo za stranke in ostale udeležence procesa (Lambert et al. 1998).

Slika 3: Integracija ključnih poslovnih procesov (Lambert et al. 1998) Procesi v preskrbovalni verigi (Croxton et al. 2001):

- Upravljanje odnosov s strankami (CRM) Proces CRM predstavlja strukturo, kako razviti in vzdrževati odnose s strankami. V tem procesu vodstvo podjetja identificira ključne kupce, ki bodo obravnavani v okviru poslovne misije podjetja. Glavna cilja sta segmentacija kupcev glede na njihovo vrednost in povečevanje lojalnosti kupcev s ponudbo prilagojenih izdelkov in storitev, glede na posebne potrebe kupcev.

- Upravljanje s servisiranjem kupcev Upravljanje s servisiranjem kupce predstavlja sliko podjetja, ki ga vidijo kupci. Je ključna točka, kjer se izvaja administracija pogodb o storitvah in izdelkih, ki so nastale v procesu CRM. Servis kupcem omogoča vpogled v trenutno stanje naročila in kdaj bo izdelek ali storitev dobavljena.

- Upravljanje z zahtevami

14

Proces upravljanja z zahtevami usklajuje potrebe kupcev z zmogljivostjo preskrbovalne verige.

- Izpolnjevanje naročil Proces izpolnjevanja naročil zajema poleg vnosa naročil tudi aktivnosti, ki so potrebne za določitev potreb kupca.

- Upravljanje s proizvodnim tokom Upravljanje s proizvodnim procesom zajema vse aktivnosti, ki so potrebne za vzdrževanje, implementacijo in upravljanje s fleksibilnostjo proizvodnje v preskrbovalni verigi, prav tako pa mora poskrbeti za premike blaga med proizvodnimi enotami.

- Upravljanje odnosov z dobavitelji (SRM) Proces SRM predstavlja strukturo, kako razviti in vzdrževati odnose z dobavitelji. Kot napeljuje ime, je ta proces zrcalna slika procesa CRM. Tako kot v primeru CRM, SCM skrbi za optimalen odnos z majhno množico dobaviteljev, ki imajo za podjetje največjo vrednost.

- Razvoj izdelkov Proces razvoja predstavlja strukturo za razvoj izdelkov in storitev s strankami in dobavitelji ter njihovo plasiranje na trg.

- Upravljanje z vračili Upravljanje z vračili je proces, s katerim upravljamo z vsemi aktivnostmi, ki so povezane z vračili ter njihovim preprečevanjem med vsemi členi preskrbovalne verige.

Ključna pri upravljanju preskrbovalnih verig sta procesa upravljanja odnosov s strankami in dobavitelji, ki povezujeta in omogočata delovanje vseh glavnih procesov. Za vsakega dobavitelja je ključno merilo uspešnosti procesa CRM pozitivna sprememba donosnosti določenega kupca ali segmenta kupcev, za vsakega kupca pa je merilo uspešnosti procesa SRM pozitivna sprememba v donosnosti določenega dobavitelja (Croxton et al. 2001). Največji ponudniki rešitev SCM so SAP, i2 Technologies, Oracle (v 2005 prevzel PeopleSoft), PeopleSoft, Manhattan Assocates, IBS, Manugistics (AMR Research 2005A).

2.3 Upravljanje odnosov s strankami – CRM

CRM je poslovna strategija, ki je širša od samo povečevanja transakcijskega volumna. Njeni glavni cilji so povečanje donosnosti, prihodkov in zadovoljstva kupcev. Za dosego teh ciljev uporablja podjetje široko množico orodij, tehnologij in procedur, ki omogočajo kvaliteten odnos s kupcem in boljšo prodajo (Sweeney Group 2000, povz. po Gray, Byun 2001). Slika 4 prikazuje tri glavne komponente CRM: stranke, odnose in upravljanje. CRM skuša doseči integracijo v enotni integrirani pogled na kupce, poleg tega vpeljuje

15

pristop, pri katerem je kupec v središču CRM procesov (Roberts-Witt 2000, povz. po Gray, Byun 2001).

Slika 4: Komponente CRM (Gray, Byun 2001) Glavni razlogi za vpeljavo CRM rešitev so naslednji (Gray, Byun 2001):

- po Paretovem principu 20 % strank podjetja prinaša 80 % dobička. CRM nam omogoča identificirati teh 20 % strank ter z njimi vzpostaviti primeren odnos;

- raziskave, ki so jih naredili v Boston Consulting Group v letu 2000, so pokazale, da je približno 5x manj stroškov z vzdrževanjem obstoječega kupca kot z iskanjem novega. S pomočjo CRM lahko vzdržujemo bolj kvalitetne odnose z obstoječimi kupci;

- 5 % povečanja poslovanja s stalnimi kupci se odraža na 25 % povečanju dobička. CRM nam omogoča prilagajanje kupcem in tako možnost za povečanje prodaje.

Nekateri ponudniki CRM rešitev so J.D. Edwards, Oracle, SAP, Siebel, Applix, Talisma, eGain.

2.4 Upravljanje odnosov z dobavitelji – SRM

Upravljanje odnosov z dobavitelji je del preskrbovalne verige, ki skrbi za odnose med podjetjem in njegovimi dobavitelji. SRM definira poslovne strukture in procese, ki jih potrebuje podjetje za uspešno komunikacijo s svojimi dobavitelji. Poleg tega zagotavlja metode, procese in orodja za podporo različnih faz direktnega odnosa z dobavitelji, npr. identifikacija, ocenjevanje, kvalificiranje in po potrebi ukinitev odnosa (Eyholzer et al. 2002, povz. po Campelo, Stucky 2007) . Nekateri ponudniki SRM sistemov so SAP, i2 Technologies, Oracle, Ariba, FreeMarkets, Emptoris, Contracto (Eyholzer et al. 2002, povz. po Campelo, Stucky 2007).

2.5 Tipi informacijskih sistemov

V podjetjih imamo v grobem tri možnosti pri izbiri tipa informacijskega sistema. Prva možnost je nakup standardne celovite informacijske rešitve, ki z določeno mero pokriva večino poslovnih procesov podjetja. Druga možnost je nakup več med seboj povezanih neodvisnih najboljših programskih rešitev različnih ponudnikov (BoB).

16

Tretja možnost pa je razvoj informacijskega sistema po meri. V nalogi se bomo omejili na te tri možnosti, čeprav so v praksi možne poljubne kombinacije. Definicije različnih tipov informacijskih sistemov:

1. Standarden celovit informacijski sistem definiramo kot celovito povezano in na poslovnem modelu organizacije temelječo sestavo uporabniških programov, ki zagotavljajo podporo vsem poslovnim procesom organizacije. Celovito rešitev tvorijo komponente ERP, CRM, SCM ter SRM. Ponudnik vseh komponent je isti.

2. Integracija najboljših rešitev – BoB je, kot standarden celovit informacijski

sistem celovita rešitev, sestavljena iz komponent ERP, CRM, SCM in SRM. Ponudniki različnih komponent ali celo delov komponent (predvsem ERP) so različni.

3. Razvoj informacijskega sistema po meri pomeni razvoj prilagojenih komponent ERP, CRM, SCM in SRM po meri organizacije. Razvoj se lahko izvaja interno, v okviru organizacije ali eksterno, preko zunanjega izvajalca.

V tabeli III je prikazana primerjava različnih tipov informacijskih sistemov. Tabela III: Primerjava različnih tipov informacijskih sistemov (povz. po Murthi

2002)

Standarden celovit informacijski sistem

Integracija najboljših rešitev (BoB)

Razvoj informacijskega sistema po meri

Potencialne prednosti

- lahko je stroškovno najugodnejša rešitev;

- kvaliteta programske opreme je lahko boljša, če je rešitev razširjena;

- možnost enostavnejše migracije na novejše verzije produkta v prihodnosti.

- možna je večja prilagodljivost poslovnim potrebam;

- rešitev je navadno cenejša kot rešitev razvita po meri.

- lahko najbolje pokriva poslovne procese;

- omogoča največ kontrole nad rešitvijo;

- lahko jo prilagodimo tako, da najbolj ustreza poslovnim potrebam.

Potencialne nevarnosti

- ponudnik je lahko finančno nestabilen;

- produkt je lahko nezrel;

- lahko so potrebne zelo drage prilagoditve informacijskega

- ponudniki so lahko finančno nestabilni;

- tehnološka platforma je lahko nezrela;

- potencialni problemi pri iskanju kadrov s potrebnimi znanji;

- potencialni problemi

- tehnološka platforma je lahko nezrela;

- znanja za vzdrževanje platforme so lahko problematična;

- izboljšave in odpravljanje napak

17

sistema; - lahko so potrebne

spremembe poslovnih procesov.

z integracijo. je lahko zelo zamudno in drago.

Stroški

- stroški licenc informacijske rešitve;

- stroški infrastrukture; - stroški podpore,

izobraževanja in prilagoditev informacijskega sistema.

- stroški licenc informacijskih rešitev;

- stroški infrastrukture; - stroški podpore in

izobraževanja pri uporabi novih produktov.

- stroški infrastrukture; - stroški

izobraževanja kadrov za obvladovanje novih orodij, tehnologij in platform.

2.5.1 Standarden celovit informacijski sistem

Vpeljava standardnega celovitega informacijskega sistema v podjetje je kompleksen proces, ki ga podjetje izvede s pomočjo uvajalne ekipe ponudnika programske rešitve. Proces vpeljave zahteva zelo natančno analizo poslovnih procesov in v primeru neskladnosti z najboljšimi praksami, ki so zajete v programsko logiko, uskladitev le-teh. Uskladitev je možna s prilagajanjem poslovnega procesa ali pa s prilagoditvijo programske rešitve, če ocenimo, da je za nas specifičen poslovni proces konkurenčna prednost, ki jo želimo zadržati. Vendar moramo biti pri prilagoditvah zelo pazljivi, kajti večje spremembe so zapletene, nepraktične in zelo drage (Chen 2001). Zato je dobro slediti pravilu, da se prilagoditve izvajajo samo, kadar so neizogibne in kadar je možno jasno pokazati konkurenčno prednost prilagoditve (Somers in Nelson 2003). Na drugi strani pa je nevarno tudi prilagajanje poslovnih procesov standardni rešitvi, čeprav je večinoma to najboljša rešitev pri vpeljavi celovitega informacijskega sistema in takšen pristop uporablja večina podjetij pri vpeljavi (Chen 2001). Z vpeljavo celovitega informacijskega sistema podjetje pridobi ogromno znanja v obliki najboljših praks, ki so navadno implementirane v rešitvah. Poleg tega je bistvena pridobitev integracija podatkov, ki omogoča poenoten pogled na poslovanje podjetja, kar posledično vodi v boljšo komunikacijo med udeleženci v poslovnem procesu. Prednosti standardnega celovitega informacijskega sistema (Stefanou 2001):

- konsistentni integrirani procesi, - skladnost nadgradenj, - nižji stroški (pogojno, odvisno od ponudnika količine potrebnih prilagoditev), - enostavnejša implementacija, - lažje vzdrževanje.

18

Vendar pa se poleg vseh prednosti pojavljajo tudi težave, ki jih lahko strnemo v naslednje točke (Themistocleous et al. 2001):

- kompleksnost uvedbe rešitve; - težave pri tehnični integraciji; - težave pri nastavljanju rešitev; - projekti uvedbe prekoračujejo načrtovana sredstva in čas; - upiranje spremembam, organizacijske spremembe; - težave pri poslovnih strategijah in zagotavljanju konkurenčne prednosti.

Težave s standardnimi celovitimi rešitvami se kažejo v anketah, v eni izmed njih kar 30 odstotkov anketirancev označuje njihovo programsko rešitev kot neustrezno oz. nesposobno prilagajanja specifičnih poslovnim procesom (Kumar et al. 2002). Raziskava, narejena v proizvodnih podjetjih na Švedskem, kaže, da se po vpeljavi standardne rešitve stroški informacijske tehnologije ne zmanjšajo (Olhager in Selldin 2003).

2.5.2 Integracija najboljših rešitev (BoB)

Integracija najboljših rešitev zajema identifikacijo najboljših obstoječih rešitev na trgu po vsebinskih področjih, njihova implementacija in integracija. V proces integracije najboljših rešitev je vpletenih več različnih partnerjev, za vsako rešitev imamo lahko različnega partnerja. To precej poveča kompleksnost projekta, saj moramo koordinirati in usklajevati različne vidike in strategije različnih partnerjev. S številom različnih rešitev raste tudi kompleksnost integracije rešitev. Kompleksnost pomeni tudi več učenja za ekipo, ki skrbi za informacijski sistem, vendar pa se iz programerjev preusmerijo v poslovne analitike (Light et al. 2001). Raziskava podjetja Aberdeen Group (2006) odstira zanimivo dejstvo, da se v zadnjem času tudi ponudniki celovitih informacijskih sistemov (npr. SAP, Oracle) ravnajo po principu BoB, kajti v sklopu svojih celovitih rešitev navadno ponujajo ERP, kot osnovo, poleg tega pa so v njihovi ponudbi še razširitve, kot so CRM, SCM in SRM. Ugotovimo, da ločnica med celovitimi informacijskimi rešitvami in BoB rešitvami ni jasno začrtana (povz. po Jutras 2006). Njihova raziskava nam pokaže, da se pri nakupu ERP razširitev uporabniki obnašajo zelo različno. Manjša podjetja v večini primerov izvedejo nakup razširitve (CRM, SCM in SRM) pri istem ponudniku, kot ERP rešitev, večja pa v večini primerov izberejo specializiranega ponudnika (povz. po Jutras 2006). Prednosti BoB (Stefanou 2001):

- možnost funkcionalnih izboljšav, - fleksibilnost, - možna konkurenčna prednost, - možnost dopolnjevanja modulov (npr. CRM, SCM), - neodvisnost od samo enega ponudnika.

Slabosti BoB (O'Leary 2002):

19

- stroški iskanja primernih rešitev so višji; - uporabniški vmesniki različnih modulov se lahko razlikujejo, to lahko povzroči

dodatne stroške izobraževanja ali modifikacij programske opreme; - stroški povezovanja modulov so lahko visoki; - pri implementaciji mora sodelovati raznolika skupina, zato so lahko zahteve

slabo definirane; - pojavijo se lahko težave pri nadgrajevanju vmesnikov.

V glavnem težave BoB predstavlja zapletenost implementacije in prihodnji stroški lastništva ter vzdrževanja povezav med rešitvami (Light et al. 2001).

2.5.3 Razvoj informacijskega sistema po meri

Razvoj informacijskega sistema po meri pomeni razvoj unikatne programske rešitve, ki je popolnoma prilagojena poslovanju določenega podjetja. Pri izvedbi imamo v grobem dve možnosti: informacijsko rešitev lahko razvijemo interno, torej z močno ekipo informatike v podjetju ali pa eksterno, v sodelovanju s partnerjem, ki izvaja razvoj programske rešitve. Razvoj informacijskega sistema po meri omogoča podjetjem popolno prilagajanje informacijskega sistema poslovnim procesom v podjetju (Kumar 2004). S tem pristopom lahko tako zelo natančno podpremo trenutne potrebe podjetja. Podjetje ne potrebuje nobenega prilagajanja informacijskemu sistemu in le-ta lahko dosledno pokriva poslovne procese. To pride posebej do izraza pri specifičnih poslovnih procesih, ki predstavljajo tudi konkurenčno prednost podjetja. Podjetje ima popolno kontrolo nad svojim informacijskim sistemom in vse spremembe v poslovnih procesih se lahko transparentno odražajo v informacijskem sistemu. Spletne storitve in storitveno orientirana arhitektura nam na področju razvoja programske opreme omogočajo ogromno novih možnosti in tako tudi Gartner Group poroča o povečanem trendu razvoja informacijskih sistemov po meri v zadnjem času (povz. po Ledeen 2004, Nelson 2003). Aplikacije po meri se lahko gradijo z integracijo standardnih komponent. Proces gradnje aplikacij tako ne pomeni več programiranja modulov, ampak sestavljanje standardnih komponent. Vendar pa moramo biti pri vpeljavi tovrstnih rešitev zelo pazljivi, kajti z njimi je povezanih precej tveganj (Kumar 2004, Beck 2000):

- navadno ni jasno začrtane poti naprej; - obstaja velika nevarnost podpore ne-optimalnim poslovnim procesom,

namesto da bi vpeljali najboljše prakse (angl. »best practices«); - rešitve so navadno manj odporne na izzive prihodnosti, kajti navadno niso

zgrajene na odprtih arhitekturah; - obstaja velika nevarnost, da v prihodnosti porabimo bistveno več časa in

denarja, da vpeljemo in integriramo dodatno standardno rešitev, kot je npr. CRM ali SCM.

Svetovalno podjetje KPMG je v raziskavi ugotovilo, da je v Kanadi več kot polovica razvojnih projektov prekoračila načrtovana sredstva za več kot 30 odstotkov in skoraj

20

90 odstotkov projektov je za več kot 30 odstotkov prekoračilo predvideni čas razvoja (Whittaker 1999). Tveganje predstavlja tudi pomanjkanje standardov (davčni zakoni, računovodski standardi, industrijski standardi), če niso dosledno integrirani v informacijske rešitve po meri (Ledeen 2004). Podjetje Aberdeen Group (2006) je v svoji raziskavi ugotovilo, da je popolnoma čistih prilagojenih rešitev (brez katerega koli drugega paketa) razmeroma malo, manj kot 1 procent, vendar pa je okrog 12 procentov razvitih ERP rešitev po meri, ki imajo dodano še kakšno manjšo standardno rešitev (povz. po Jutras 2006). Ugotovimo, da, tako kot pri celovitih informacijskih rešitvah tudi pri rešitvah po meri, ni jasne ločnice med njimi in BoB rešitvami.

21

3 Primerjava metodologij izbire informacijskih sistemov

V zadnjem času imamo precej pestro ponudbo celovitih informacijskih rešitev, prav tako pa intenzivno napredujejo tehnologije, ki omogočajo bistveno večji nabor možnosti kot še pred nekaj leti. Tehnologija SOA omogoča praktično neomejene možnosti pri povezovanje različnih sistemov med seboj. Izbira primernega informacijskega sistema za podjetje je tako postala še bolj zahtevna in kompleksna naloga, kajti nismo več omejeni samo na eno rešitev, sodobne tehnologije nam omogoča poljubno sestavljanje sistemov med seboj (npr. ERP sistem enega dobavitelja in CRM sistem drugega dobavitelja). Gartner, vodilno podjetje na področju analiz trga in napovedovanju trendov v prihodnosti, je objavilo že precej analiz trga celovitih informacijskih sistemov, prav tako pa je pripravilo nekaj metodologij, ki podjetjem omogočajo sistematski pristop k izbiri primernega celovitega informacijskega sistema. Predstavili bomo dve metodologiji podjetja Gartner, ki sta po vsebini najbližje metodologiji, ki je predstavljena v raziskovalni nalogi in obenem predstavljata izhodišče za prilagojeno metodologijo:

1. Izbor in ovrednotenje ponudnika: ERP ogrodje (angl. »Vendor Selection and Evaluation: An ERP Framework«, Lebinski 2001).

2. FACT analiza za ovrednotenje možnosti razvoja programske opreme (angl. »Use FACT Analysis to Evaluate Software Deployment Options«, Kyte 2007).

Poleg tega bomo v grobem predstavili še nekaj drugih metodologij, ki se nanašajo na izbiro informacijskega sistema in nam bodo služile kot pripomoček za definicijo prilagojene metodologije:

1. Ogrodje za predhodno izbiro ERP (angl. »A framework for the ex-ante evaluation of ERP software«, Stefanou 2001).

2. Ogrodje za izbiro ERP paketov sistema za majhna, srednja in velika podjetja (angl. »A framework for the selection of ERP packages for small to medium and large organizations«, Bernroider, Koch 2002).

3. Splošno ogrodje za izbiro ERP sistema (angl. »A comprehensive framework for selecting an ERP system«, Wei, Wang 2004).

3.1 Izbor in ovrednotenje ponudnika: ERP ogrodje

Gartnerjeva metodologija (2001) za izbor in ovrednotenje ponudnika ponuja model, s katerim v prvi fazi identificiramo kriterije, ki so ključni pri izbiri ponudnika ERP rešitve, v drugi fazi pa na podlagi teh kriterijev izvedemo izbor. Uporabna je v projektih iskanja najboljšega ponudnika programske opreme (Lebinski 2001). Projektne ekipe, ki izbirajo izdelane ERP rešitve, morajo zelo natančno analizirati lastne potrebe in nato analizirati trg ponudnikov. Podjetja morajo znati ločiti med obljubami in dejansko izvedbo, poleg tega morajo znati oceniti, če bo ERP sistem prenesel obremenitve, ki jih generirajo uporabniki v njihovem podjetju. Projektne ekipe morajo prav tako zelo dobro oceniti tveganje, ki je povezano z določenim

22

ponudnikom. Vse to so zahtevne in kompleksne naloge, ki jih projektna ekipa lahko izvede samo s strukturirano metodologijo, ki zajema vse aspekte problematike. Metodologija ima dva koraka (Lebinski 2001):

1. Definiranje izbirnih kriterijev in določitev njihove teže glede na celotno strukturo.

2. Izbor:

o ocena internih potreb, o analiza ponudnikov, o pogajanje in izbira.

Podjetja se pri izbiri primernega ERP ponudnika srečujejo z naslednjimi izzivi:

Izzivi okolja

o pomanjkanje strukture in metodologije, o politični načrti in predhodno definiran rezultat, o paraliza analize – nezmožnost sprejetja odločitve, o pomanjkanje preverjenih informacij.

Organizacijski izzivi

o izbira ni osnovna kompetenca, o nerealna pričakovanja, o razpršena pozornost, o nedoločen obseg, o fokus na taktiki in ne strategiji, o politični načrti.

Izvedbeni izzivi

o identifikacija primernega selektivnega kriterija, o strukturiranje kriterija v primeren kontekst, o določanje relativne pomembnosti glede na celotno strukturo, o utemeljitev izbire preko celotne organizacije.

Ena izmed najpomembnejših točk procesa izbire je definiranje nujnih zahtev in prednostnih kriterijev, ki omogoča osredotočenje na najprimernejše ponudnike/produkte. Če upoštevamo, da je bilo v letu 2001 več kot 25 ponudnikov ERP rešitev, je jasno, da brez ostrih kriterijev pridemo do predolgih seznamov potencialnih ponudnikov. V idealni situaciji bi moral seznam potencialnih kandidatov vsebovati 5–6 zapisov. Po drugi strani pa obstaja bojazen, da s preostrimi zahtevami izločimo potencialno dobrega kandidata. V skrajnosti to vodi do kriterijev, ki so tako restriktivni, da jih nobeden od kandidatov ne izpolnjuje. Ločiti moramo torej med zahtevami, ki so res neobhodne, in zahtevami, ki jih je dobro imeti (angl. »nice to have«).

23

V procesu izbire si pomagamo z orodji, kot je prečiščena hierarhična analiza (angl. »Refined Hierarchical Analysis (RHA)«1). Prvi korak v strukturirani selektivni metodologiji za izbor ERP ponudnika je identifikacija in določitev teže kriterijev, ki bodo sestavljali proces selekcije. To zahteva strukturo, ki je podobna organizacijski strukturi. Na prvem mestu je cilj: izbira najboljšega ERP ponudnika, pod ciljem pa so glavni kriteriji s svojo težo, ki jo imajo glede na celotno strukturo (Lebinski 2001):

Cilj: Izbira najboljšega ERP ponudnika

o Funkcionalnost (22 %) Funkcionalnost v bistvu pomeni, kaj v tem trenutku pokriva določena rešitev. Definira sposobnost dinamičnega in časovno učinkovitega spremljanja, upravljanja in pregledovanja informacij. V naboru funkcionalnosti ERP sistema so zajete proizvodnja, distribucija, logistika, finance in upravljanje s človeškimi viri. Sestavljajo jo naslednje komponente:

� proizvodnja (35 %), � finance (26,5 %), � distribucija in logistika (26,5 %), � upravljanje s človeškimi viri (12 %).

o Tehnološka arhitektura (17 %)

Tehnološka arhitektura zajema prenosljivost in povezljivost, kvaliteto grafičnega vmesnika, skalabilnost produkta. Sestavljena je iz naslednjih komponent:

� operacijski sistem, podatkovna baza (43 %), � grafični uporabniški vmesnik (8,66 %), � arhitektura sistema (15,15 %), � razvojno okolje (12,99 %), � uporabljeni modeli (8,66 %), � orodja za migracijo (11,54 %).

o Investicija (12 %)

Investicija je strošek nabave, implementacije in integracije produkta ter seveda stroški vzdrževanja in nadgradenj. Sestavljena je iz naslednjih komponent:

� strošek osnovne investicije (43,75 %), � stroški vzdrževanja (56,25 %), � količnik povratka investicije (ROI) (0 %).

o Servis in podpora (19 %)

1 Metoda omogoča hierarhično dekompozicijo problema z veliko spremenljivkami/kriteriji. Kriteriji so grupirani v homogene skupine pod določenim nadrejenim kriterijem. Tako dobimo pregledno drevesno strukturo kriterijev in viden je vpliv vsakega izmed njih na celoto (Lebinski 2001).

24

Servis in podpora pomeni, kako kvaliteten odnos uporabnik-ponudnik bomo lahko zgradili. Pomembna je tudi stabilnost ponudnika. Sestavljen je iz naslednjih komponent:

� podpora (55 %), � kvaliteta storitev (45 %).

o Sposobnost nadaljnjega razvoja (17 %)

Sposobnost nadaljnjega razvoja zajema kvalitativno analizo in standardne »Wall Street Metrics«2. Vsebuje tri kategorije:

� finančni vidik (30 %), � organizacijski vidik (39 %), � tržni vidik (31 %).

o Vizija (13 %)

Vizija zajema analizo strategije, ki jo ima ponudnik za nadaljnji razvoj poslovnih aplikacij. Sestavljena je iz naslednjih komponent:

� vizija produkta (40 %), � vizija podpore (31 %), � vizija organizacije (29 %).

o Demo s skripti (0 %)

Demonstracija je namenjena prikazu funkcionalnosti produkta na konkretnih podatkih in primerih.

Metodologija izbora ponuja sistematski pristop k izbiri primernega ERP ponudnika, kar omogoča zmanjšanje časa in stroškov v procesu izbire, prav tako pa objektivnejšo odločitev. Sestavljena je iz treh faz:

1. Ocena internih potreb

a. Sestava projektne ekipe b. Identifikacija potreb:

� neobhodne/obvezne, � ocenjene, � želene (»nice to have«).

c. Definicija zahtev d. Dolg seznam ponudnikov – začetna selekcija e. Priprava povpraševanja po ponudbi/informacijah (RFP/RFI)

2. Analiza ponudnika

a. Ocena odzivov b. Analiza neobhodnih/obveznih potreb

2 metrike, ki prikazujejo finančno sliko podjetja v določenem četrtletju, npr. povprečni prihodki/uporabnika (Teradata Center 2002).

25

c. Kratek seznam ponudnikov – nadaljnja selekcija d. Podrobna analiza ponudnika in povpraševanje po ponudbi e. Demo predstavitve f. Izbira finalistov

3. Pogajanja in izbira

a. Priprava pogojev in pogodb b. Priprava strategije pogajanja c. Pogajanje o pogodbah d. Izbira zmagovalca e. Podpis pogodbe

3.2 FACT analiza za ovrednotenje možnosti razvoja programske opreme

FACT analiza podjetja Gartner (2007) nam na podlagi izdelanega modela kriterijev omogoča izbiro primerne variante pri razvoju programske opreme. Uporabna je pri pripravah novih projektov, povezanih s programsko opremo in pri večjih nadgradnjah (Kyte 2007). Ocenjevanje alternativ pri razvoju programske opreme zajema primerjavo in analizo vhodnih podatkov in zahtev različnih področij. Predstavljena raziskava ponuja strukturirano ogrodje za izdelavo uravnotežene ocene. Izhodišča (Kyte 2007):

1. Finančni vidik (Finance) Vsaka alternativa mora biti ocenjena s konsistentnim modelom skupnih stroškov lastništva (TCO). Model mora vsebovati stroške infrastrukture, stroške končnih uporabnikov, stroške licenc, vzdrževanj in nadgradenj.

2. Agilnost (Agility)

Zmožnost vključitve sprememb, ki so pogojene s poslovanjem, mora biti jasno definirana za vsako alternativo.

3. Kontrola (Control)

Za vsako alternativo moramo definirati nadzorno strukturo. Vsebovati mora investicijo, ki je potrebna za primeren nivo upravljanja z aplikacijami, upravljanje s ponudniki in upravljanje s tveganjem.

4. Tehnologija (Technology)

Tehnološka komponenta vsake alternative mora biti pazljivo definirana. Za vsako komponento mora biti določena skladnost z arhitekturnimi standardi podjetja ter definicija življenjskega cikla komponente med življenjskim ciklom programske opreme.

26

Slika 5: FACT analiza (povz. po Kyte 2007) Nabor variant pri izbiri razvoja programske opreme se širi in zajema:

- programski paket, sestavljen po definiciji; - programski paket, narejen po meri uporabnika; - programski paket kot storitev (SaaS); - programski paket, ki je nameščen drugje in ga samo koristimo; - zunanje izvajanje poslovnih procesov.

Vendar to niso samo enostavne klasifikacije, vsaka ima namreč veliko variant in opcij. Na primer: programski paket, narejen po meri uporabnika, ima lahko naslednje variante:

- programski paket, narejen po meri uporabnika, razvit v podjetju, vzdrževan v podjetju;

- programski paket, narejen po meri uporabnika, razvit v podjetju, vzdrževan s strani partnerja;

- programski paket, narejen po meri uporabnika, razvit s strani partnerja, vzdrževan v podjetju;

- programski paket, narejen po meri uporabnika, razvit s strani partnerja, vzdrževan s strani partnerja.

Pri izbiri programske opreme s stališča razvoja sta možna dva pristopa:

1. Izbira razvojne opcije in potem izbira ponudnikov, ki podpirajo te razvojne opcije Takšen pristop je uporaben pri projektnih skupinah, katerim finančni ali arhitekturni vidik določa razvojno opcijo. Na primer: primanjkljaj denarja lahko pogojuje izbiro SaaS.

2. Upoštevanje razvojnih opcij pri splošnem procesu izbire. Takšen pristop je

primeren za projektne ekipe, ki imajo bolj odprte možnosti pri izbiri.

Finance (Finance)

- skupni stroški lastništva, - stroški infrastrukture, - stroški upravljanja, - tabela vseh stroškov.

Kontrola (Control)

- model upravljanja, - upravljanje z dobavitelji, - upravljanje s tveganjem, - upravljanje s kvaliteto.

Agilnost (Agility)

- scenarij konsistentnih sprememb,

- hitrost uvedbe sprememb, - strošek uvedbe sprememb.

Tehnologija (Technology)

- programska oprema, - življenjski cikel komponent, - vpliv na arhitekturo, - standardi.

27

Obstaja velika verjetnost, da bodo v prihodnosti bolj prisotne prve variante, torej da bodo razvojne opcije določene že pred oceno trga. Za celovito, strukturirano evaluacijo možnosti razvoja programske opreme je potrebno proučiti štiri različne, vendar med seboj povezane, domene: finančni vidik, agilnost, kontrolo in tehnologijo (Finance, Agility, Control, Technology), oz. FACT (Kyte 2007). Finančni vidik Jedro finančne ocene bi moral biti celotni strošek lastništva (TCO). Nivo podrobnosti finančnega vidika je odvisen od velikosti investicije in nevarnosti, vendar mora v vsakem primeru zajemati naslednje komponente:

- vpliv na glavni proračun, - vpliv na operativni proračun, - stroški infrastrukture (mrežna oprema, strežniki), - stroški šolanja uporabnikov, - operativni stroški uporabnikov, - stroški integracije, - stroški konfiguracije, - stroški prilagoditev, - ponovna uporaba investicije, - zmožnost ponovne uporabe, - potencialni prihranki.

Agilnost Karakteristike agilnosti vsake razvojne opcije moramo primerjati z zahtevami agilnosti celotne programske opreme. Projektne ekipe, ki izvajajo evaluacijo, bi morale definirati nivo agilnosti, ki ga mora dosegati določena varianta tako, da s specifičnimi primeri sprememb ocenijo odzivni čas in stroške vpeljave spremembe. V splošnem lahko zajema naslednje komponente:

- odzivnost pri podpori, - spreminjanje poslovnih pravil, - dodajanje novih uporabniških polj v sistem, - dodajanje novih pravil kontrole za polja v sistemu, - povezljivost v okviru podjetja, - povezljivost izven podjetja, - kreiranje novih ekranskih mask za specifične uporabnike, - spreminjanje privzetega delovnega toka, - odzivanje na spremembe zakonodaje, - dodajanje sprožilcev, s katerimi lahko sprožimo določene procedure pri

spreminjanju polj. Kontrola

28

Programsko opremo moramo upravljati z različnih nivojev. Vsaka varianta mora biti ovrednotena z vidika, koliko časa potrebujejo ključni uporabniki, da dosežejo pričakovani nivo kontrole. Investicija, ki je potrebna, da dosežemo pričakovani nivo kontrole, mora zajemati vsaj naslednje komponente:

- model upravljanja - identificirati ključne posameznike, ki bodo sodelovali pri strateških odločitvah glede življenjskega cikla programske opreme;

- poslovno upravljanje - identificirati, katere aktivnosti v poslovnem smislu so potrebne, da dosežemo prednosti, ki jih prinaša določena rešitev;

- upravljanje z dobavitelji - identificirati, kako bomo upravljali z odnosom s ponudnikom rešitve;

- upravljanje s tveganjem - definirati moramo formalno oceno tveganja z določeno varianto;

- upravljanje s kvaliteto - katera orodja, veščine in storitve bodo potrebni za upravljanje s kvaliteto rešitve;

- upravljanje s prednostmi - kako bomo nadzorovali planirane prednosti in kako jih bomo nadgrajevali;

- planiranje poslovne kontinuitete - kako bo določena rešitev vplivala na splošno tveganje v poslovnih operacijah.

Tehnologija Vsaka razvojna varianta nosi s seboj nabor tehnoloških zadev. Posebno pozornost je potrebno nameniti, kakšno obremenitev prinaša s seboj določena varianta. Na primer SaaS rešitev prinese s seboj veliko obremenitev z zunanjim omrežjem. Tako lahko zajema vsaj naslednje komponente:

- definicija programskega nabora (operacijski sistem, podatkovna baza, aplikacijski strežnik);

- plan pričakovanega življenjskega cikla za vsako komponento programskega nabora;

- kakršne koli performančne odvisnosti od infrastrukturnih storitev; - zmožnost integracije v realnem času; - zmožnost integracije batch postopkov; - vpliv na arhitekturo podjetja; - ujemanje s standardi; - potrebe po veščinah in njihova razpoložljivost; - razpoložljivost tehnoloških storitev; - orodja za operativno upravljanje; - orodja za spremljanje nivoja storitev; - vpliv na operativne urnike.

Z uporabo FACT analize lahko projektne skupine kreirajo svoje evalvacijske kriterije in s tem prilagodijo analizo svojim potrebam. Tako lahko pridobijo kvalitetne informacije in izbira primerne alternative postane transparentna in strukturirana.

3.3 Ogrodje za predhodno izbiro ERP sistema

Metodologija, ki jo je predstavil Stefanou (2001), omogoča oceno različnih možnosti in izbiro najboljše variante v procesu izbire primernega informacijskega sistema.

29

Temelji na življenjskem ciklu ERP sistemov, ki je pri večini avtorjev podoben življenjskemu ciklu razvoja programske opreme (Nah, Lau 2001, povz. po Sefanou 2001). Za vsako fazo življenjskega cikla ocenimo strateške in operativne vidike in na podlagi teh se odločimo za najboljšo alternativo.

Slika 6: Glavne faze življenjskega cikla ERP sistemov (povz. po Stefanou 2001) Stefanou (2001) razdeli faktorje, ki jih obravnavamo pri ocenjevanju, na strateške in operativne. Nekateri pomembnejši strateški faktorji (povz. po Stefanou 2001):

- prispevek ERP sistema k poslovni viziji in strategiji, - usklajenost poslovne in tehnološke strategije, - fleksibilnost in skalabilnost IT arhitekture, - fleksibilnost ERP rešitve, - integracija poslovnih procesov in informacij, - identifikacija nevarnosti, - vpliv ERP sistema na odločanje, - ocena ERP sistemov pri konkurenčnih podjetjih, - vpliv ERP sistema na poslovne mreže, - ocena skupnih stroškov lastništva ERP sistema.

Nekateri pomembnejši operativni faktorji (povz. po Stefanou 2001):

- vpliv ERP sistema na:

Poslovna vizija

Možnosti / omejitve

Izbira ERP sistema

Zahteve

Implementacija ERP sistema

Obratovanje, vzdrževanje,

evolucija ERP

sistema

Faza 1 Faza 2 Faza 3 Faza 4

Analiza

Ocena stroškov, prednosti, nevarnosti: STRATEŠKO – OPERATIVNO Ocena ROI (angl. »Return on Investment«)/vrednosti/poslovnih modelov (primerov) ERP sistema

30

o stroške transakcij, o čas izvedbe transakcij, o stopnjo integracije poslovnih procesov, o zadovoljstvo kupcev.

- ocena stroškov glede na:

o izobraževanje uporabnikov, o zunanje svetovalce, o dodatne aplikacije, o izpad sistema.

3.4 Ogrodje za izbiro ERP paketov za majhna, srednja in velika podjetja

Bernroider in Koch (2002) sta v svoji študiji predstavila ogrodje za proces izbire ERP sistema. Ogrodje temelji na splošno uporabnem modelu sprejemanja odločitev.

Slika 7: Splošni model procesa izbire ERP sistema (povz. po Bernroider in Koch 2002)

Proces izbire primernega ERP sistema se prične z definicijo problema in zastavljenih ciljev. V drugi fazi se sestavi komisija ali projektna ekipa, ki dovolj dobro pozna kompleksne tehnične in organizacijske vidike izbire in implementacije ERP sistemov. V splošnem je ta komisija ali projektna ekipa zadolžena za sprejem odločitve o izbiri

1. Identifikacija in formulacija problema

2. Sestava komisije / projektne ekipe

3. Zbiranje potrebnih informacij

4. Definicija alternativ

5. Ocena in primerjava alternativ

6. Izbor

31

ERP sistema. V tretji fazi se zberejo vse potrebne informacije, ki so potrebne za odločitev. V tej fazi je mogoče potrebno na novo definirati formulacijo problema. V četrti fazi definiramo alternative, glede na zbrane informacije v prejšnji fazi. V peti fazi analiziramo vse alternative na primerljiv način. Med analizo lahko ugotovimo, da nimamo dovolj informacij ali moramo poiskati celo dodatne alternative. V zadnji fazi sprejmemo odločitev o izbiri (povz. po Bernroider in Koch 2002).

3.5 Splošno ogrodje za izbiro ERP sistema

Wei in Wang (2004) v svoji študiji predstavita celovito in splošno ogrodje za izbiro ERP sistema. V ogrodju definirata hierarhijo atributov, ki jih lahko strnemo v tri skupine:

1. Projektni faktorji: tisti atributi, ki so povezani z upravljanjem projekta, npr. skupni strošek projekta, čas implementacije, prednosti in nevarnosti.

2. Faktorji programske opreme: zajemajo ujemanje s strateškimi usmeritvami,

funkcijski in tehnološki faktorji ERP sistema. Ujemanje s strateškimi usmeritvami zajema ujemanje vizije in ciljev ter skladnost z lokalnimi zahtevami okolja.

3. Faktorji dobavitelja ERP sistema: glavni atributi v tej skupini so sposobnost

in ugled dobavitelja. Sposobnost se meri z zmožnostjo implementacije in servisa, svetovanja in podpore pri uvajanju. Ugled dobavitelja pomeni dobro finančno stanje in dobre reference in ugled na trgu (Wei in Wang 2004).

3.6 Umestitev prilagojene metodologije izbire tipa informacijskega sistema

Metodologije, predstavljene v prejšnjih poglavjih, nam služijo kot osnovo za razvoj lastne prilagojene metodologije. Povzamemo ključne vidike vseh metodologij, glede na to, da se vidiki oz. kriteriji podvajajo, se osredotočimo na metodologiji podjetja Gartner (Lebinski 2001, Kyte 2007). Sam proces izbire povzamemo in prilagodimo po splošnem modelu, ki sta ga predstavila Bernroider in Koch (2002). Slika 8 prikazuje združene vidike predstavljenih metodologij:

32

Slika 8: Združeni vidiki predstavljenih metodologij (Kyte 2007, Lebinski 2001, Stefanou 2001, Wei in Wang 2004)

Predstavljene metodologije so zastavljene precej splošno, zato smo pri metodologiji, ki je predstavljena v raziskovalni nalogi, postavili zelo natančno definirano ogrodje, ki ima točno določene vhodne podatke, uteži, ki korigirajo rezultat glede na posebnosti v podjetju, pregledne vidike, končni rezultat pa je delno številčen in delno opisen. Vidike, ki jih lahko številčno opredelimo, obravnavamo v okviru številčnega ocenjevanja. Ostale vidike, ki jim težje določimo številčno vrednost in so bolj opisnega značaja, obravnavamo v okviru analize s SWOT matrikami. Rezultat številčnega ocenjevanja in analize s SWOT matrikami nam omogoča izbiro najboljše variante. Prednost prilagojene metodologije je v preprostosti. Tako lahko to metodologijo uporabimo na samem začetku procesa odločanja o možnih alternativah informacijskega sistema v podjetju.

Fleksibilnost rešitve

Sposobnost podpore novim zahtevam(dodajanje novih pravil, polj, ekranskih mask)

Sposobnost podpore spremembam(spremembe poslovnih pravil,spremembe ekranskih mask,sprememba delovnega toka,

spremembe zakonodaje)

Podpora poslovnim procesom(proizvodnja, finance,distribucija in logistika,upravljanje s človeškimi viri)

Življenjski cikel komponent

Orodja za migracijo, upravljanje Uporabljeni modeli,

standardi

Arhitektura. GUI

Razvojno orodje, programski jezik

Podatkovna baza

Operacijski sistem

Vpliv na poslovanje, odločanje Prednosti in nevarnosti

Kvaliteta dobavitelja programske opreme

Znanja (potrebna/obstoječa)

Integracija v podjetju in izven(vsebinska in tehnološka)

Vizija programske rešitve, skladnost z vizijo podjetja

Upravljanje (poslovno upravljanje,upravljanje s ponudniki,

upravljanje s tveganjem inkvaliteto, upravljanje s prednostmi)

Sposobnost nadaljnjega razvoja

Kvaliteta storitev

Podpora

Potencialni prihranki

Ponovna uporaba investicije

Vpliv na proračun

Vzdrževanje

Osnovna investicija (infrastruktura,šolanje uporabnikov,

integracija, konfiguracija,prilagoditve, svetovalci)

Ostalo

Stroški

Funkcionalnost(vsebina)

Tehnologija

Izbira

33

4 Prilagojena metodologija izbire tipa informacijskega sistema

Prilagojena metodologija je razvita kot sinteza obravnavanih metodologij v 3. poglavju. Sam proces izbire povzamemo in prilagodimo po ogrodju, ki sta ga predstavila Bernroider in Koch (2002). Proces izbire je tako sestavljen iz sedmih delov:

1. Priprava projekta Identificiramo problem in ga formuliramo. Sestavimo komisijo oz. projektno skupino, ki bo izvajala projekt. Zberemo potrebne informacije za izvedbo projekta.

2. Definiranje variant Določimo osnovne kriterije, ki jih morajo izpolnjevati programske rešitve. Iz širšega nabora variant na podlagi osnovnih kriterijev naredimo osnovni izbor in določimo potencialne variante, ki jih ocenjujemo kot primerne za izbrano podjetje.

3. Določitev vidikov in njihovih komponent Določimo vidike in komponente vidikov, ki jih bomo ocenjevali, ter njihovo pomembnost glede na celoto. Komisija prouči variante in poda ocene za vse komponente vidikov.

4. Določitev uteži in ovrednotenje pomembnosti vidikov Določimo tip podjetja - glede na količino specifičnih poslovnih procesov v primerjavi z referenčnimi modeli, določimo uteži ter pomembnosti vidikov glede na celoto.

5. Izračun ocen variant Za vsako varianto izračunamo ocene. Rezultat izračuna so primerjalne vrednosti, ki služijo kot prvi kriterij za končni izbor.

6. SWOT matrike Za vsako varianto oblikujemo SWOT matriko. SWOT matrike so namenjene obravnavi tistih faktorjev, ki jih težje številčno ocenimo. Matrike predstavljajo drugi kriterij za končni izbor.

7. Končni izbor Izvedemo končni izbor, glede na izračunane ocene in SWOT matrike.

34

Slika 9: Shema prilagojene metodologije

4.1 Priprava projekta

Definiramo problem in ga formuliramo, določimo cilje projekta. Definiramo projektno skupino, ki bo vodila in izvajala projekt. Projektno ekipo morajo sestavljati kompetentne osebe, ki pokrivajo vsa področja projekta, tako vsebinsko kot tehnološko. Projektna ekipa zbere potrebne informacije, ki so potrebne za izvedbo projekta.

4.2 Definiranje variant

V skladu s tipi informacijskih sistemov, ki smo jih predstavili v 2. poglavju, definiramo naslednje variante: - varianta A – Standarden celovit informacijski sistem, - varianta B – Integracija najboljših rešitev – BoB, - varianta C – Razvoj informacijskega sistema po meri. S pomočjo informacij zbranih v prvi fazi določimo seznam opcij v okviru vsake variante. Definiramo osnovne kriterije, ki jih morajo izpolnjevati informacijske rešitve.

Definiranje variant

Določitev vidikov in njihovih komponent

Določitev uteži in ovrednotenje pomembnosti vidikov

Izračun ocen variant Oblikovanje SWOT matrik

Končni izbor

Priprava projekta

35

S pomočjo teh kriterijev naredimo osnovno selekcijo in dobimo nabor potencialnih ustreznih opcij. V primeru, da imamo v okviru določene variante več ustreznih opcij, ki se prekrivajo, naredimo osnovno selekcijo tako, da poiščemo najboljšo opcijo. Tako dobimo za vsako varianto konkretne predstavnike variante.

4.3 Določitev vidikov in njihovih komponent

Definicija vidikov in njihovih komponent izhaja iz metodologij, ki smo jih predstavili v 3. poglavju. Preoblikovali smo vidike in jih zasnovali bolj procesno, združili nekatere komponente, del komponent bomo obravnavali v okviru številčno-ocenjevalne analize, del pa v okviru opisno-ocenjevalne analize – SWOT matrike. Za dva ločena sistema ocenjevanja smo se odločili, ker je določene komponente vidikov možno zelo natančno številčno določiti, npr. strošek licenc, druge pa je težje natančno številčno opredeliti, ker so bolj opisne narave, npr. vizija ali potencialni prihranki. Na podlagi predstavljenih metodologij v 3. poglavju smo se odločili za naslednje vidike, ki jih bomo obravnavali v številčni analizi: - tehnološki vidik – TV, - vsebinski vidik – VV, - stroškovni vidik – SV, - ostali vidiki – OV. Večji del komponent vidikov bomo zajeli v številčni analizi. Manjši del komponent vidikov bomo obravnavali s pomočjo SWOT matrik. Te komponente bomo definirali v poglavju 4.6.

4.3.1 Tehnološki vidik

Tehnološki vidik zajema komponente, ki so vezane na tehnologijo. Vsebuje komponente tehnološke arhitekture metodologije izbora in ovrednotenja ponudnika (Lebinski 2001) ter komponente tehnološkega vidika FACT analize (Kyte 2007): - razvojno orodje, programski jezik – TV1, - baza podatkov – TV2, - operacijski sistem – TV3, - varnost – TV4, - povezljivost / arhitektura – TV5.

4.3.2 Vsebinski vidik

Vsebinski vidik zajema komponente, ki so vezane na vsebino informacijskih sistemov. Vsebuje komponente funkcionalnosti metodologije izbora in ovrednotenja ponudnika (Lebinski 2001) ter komponente vidika agilnosti in kontrole FACT analize (Kyte 2007): - pokrivanje standardnih poslovnih procesov – VV1, - prilagodljivost specifičnim poslovnim procesom – VV2, - prilagodljivost pri spreminjanju poslovnih procesov – VV3, - zmožnost podpore novo-nastalih poslovnih procesom – VV4,

36

- zmožnost upravljanja s poslovnimi procesi – VV5, - pregled nad procesi in podatki – VV6.

4.3.3 Stroškovni vidik

Stroškovni vidik zajema komponente, ki so vezane na stroške. Vsebuje komponente investicije metodologije izbora in ovrednotenja ponudnika (Lebinski 2001) ter komponente finančnega vidika FACT analize (Kyte 2007): - stroški uvedbe (strojna oprema, licence programske opreme, uvajanje) – SV1, - stroški prilagoditev – SV2, - stroški vzdrževanja in nadgradenj (strojna oprema, programska oprema) – SV3.

4.3.4 Ostali vidiki

Ostali vidiki zajemajo komponente, ki so vezane na arhitekturo, servis in podporo. Vsebuje komponente servisa in podpore ter komponente tehnološke arhitekture metodologije izbora in ovrednotenja ponudnika (Lebinski 2001) ter komponente vidika agilnosti FACT analize (Kyte 2007): - integracija z okoljem – OV1, - reference – OV2, - podpora in pomoč – OV3, - fleksibilnost – OV4, - podpora iz različnih virov – OV5, - predznanja v podjetju – OV6.

4.4 Določitev uteži in ovrednotenje pomembnosti vidikov

Definiramo uteži in faktorje pomembnosti: - uteži, ki uravnavajo vidike glede na stopnjo specifičnosti poslovnih procesov; - ovrednotenje pomembnosti posameznih vidikov glede na celoto.

4.4.1 Določitev tipa podjetja

Določanje uteži je prvenstveno odvisno od ocene količine specifičnih poslovnih procesov v podjetju. Omejili se bomo na pet tipov podjetij: - tip S1 – 0 % specifičnih procesov, - tip S2 – 25 % specifičnih procesov, - tip S3 – 50 % specifičnih procesov, - tip S4 – 75 % specifičnih procesov, - tip S5 – 100 % specifičnih procesov. Poleg tega potrebujemo oceno, kako kompleksni so poslovni procesi in kako močno so prepleteni med seboj. V nalogi se bomo omejili na dva tipa podjetij: - tip K1 – manj kompleksni in precej neodvisni poslovni procesi,

37

- tip K2 – zelo kompleksni in močno prepleteni poslovni procesi.

4.4.2 Uteži glede na specifičnost poslovnih procesov

Uteži služijo uravnavanju komponent vidikov glede na tip podjetja. Če je utež večja od 1, pomeni, da ima komponenta vidika za ta tip podjetja večjo težo od povprečne; če pa je manjša od 1, pa pomeni, da ima komponenta vidika za ta tip podjetja manjšo težo od povprečne. Za vse vidike sestavimo tabele uteži.

4.4.2.1 Tehnološki vidik

Uteži komponent tehnološkega vidika definiramo sledeče:

1. Pomembnost programskega jezika narašča s količino specifičnih poslovnih procesov, kajti večje posebnosti so povezane z večjo količino modifikacij in prilagoditev informacijskega sistema. Pri podjetju z večinoma standardnimi poslovnimi procesi ima razvojno orodje/programski jezik zelo majhno pomembnost.

2. Pomembnost podatkovne baze raste glede na večje posebnosti, vendar manj kot pomembnost programskega jezika.

3. Pomembnost operacijskega sistema raste glede na posebnosti, vendar manj kot pomembnost podatkovne baze.

4. Varnost je enako pomembna za vse tipe podjetij. 5. Pomembnost povezljivosti/arhitekture raste glede na posebnosti v podjetju,

bolj kot pomembnost komponent operacijskega sistema in baze podatkov v primeru zelo kompleksnih in povezanih poslovnih procesov.

Tabela IV: Tabela uteži – tehnološki vidik Razvojno orodje / programski jezik – TV1

Uteži za TV1 S1 S2 S3 S4 S5 K1 0,2 0,6 1 1,4 1,8 K2 0,2 0,7 1,2 1,7 2,1

Baza podatkov – TV2

Uteži za TV2 S1 S2 S3 S4 S5 K1 0,9 1 1 1,1 1,1 K2 1 1,1 1,2 1,3 1,4

Operacijski sistem – TV3

Uteži za TV3 S1 S2 S3 S4 S5 K1 0,9 0,9 1 1 1,1 K2 1 1 1,1 1,1 1,2

Varnost – TV4

Uteži za TV4 S1 S2 S3 S4 S5 K1 1 1 1 1 1 K2 1 1 1 1 1

Povezljivost / arhitektura – TV5

38

Uteži za TV5 S1 S2 S3 S4 S5 K1 0,9 0,9 1 1 1,1 K2 1 1,2 1,4 1,6 1,8

4.4.2.2 Vsebinski vidik

Uteži komponent vsebinskega vidika definiramo tako:

1. Pomembnost komponente pokrivanje standardnih poslovnih procesov upada z večanjem posebnosti v podjetju.

2. Pomembnost komponente prilagodljivosti specifičnim poslovnim procesov zelo močno narašča s količino posebnosti v podjetju. Za podjetja s standardnimi poslovnimi procesi nima nobene teže.

3. Pomembnost komponente prilagodljivost pri spreminjanju poslovnih procesov narašča s količino posebnosti v podjetju, vendar je odstopanje bistveno manjše od pomembnosti prejšnje komponente.

4. Pomembnost komponente zmožnost podpore novonastalim poslovnim procesom narašča z enako mero kot pomembnost prejšnje komponente, sorazmerno s količino posebnosti.

5. Pomembnost komponente zmožnost upravljanja s poslovnimi procesi narašča s količino posebnosti v podjetju in to hitreje kot prejšnja komponenta.

6. Pomembnost komponente pregled nad procesi in podatki narašča s količino posebnosti v podjetju enako kot pomembnost prejšnje komponente.

Tabela V: Tabela uteži – vsebinski vidik Pokrivanje standardnih poslovnih procesov – VV1

Uteži za VV1 S1 S2 S3 S4 S5 K1 1,6 1,3 1 0,8 0,6 K2 1,6 1,3 1 0,8 0,6

Prilagodljivost specifičnim poslovnim procesom – VV2

Uteži za VV2 S1 S2 S3 S4 S5 K1 0 0,5 1 1,5 2 K2 0 1 2 3 4

Prilagodljivost pri spreminjanju poslovnih procesov – VV3

Uteži za VV3 S1 S2 S3 S4 S5 K1 0,9 0,9 1 1 1,1 K2 1 1 1,1 1,1 1,2

Zmožnost podpore novo-nastalih poslovnih procesom – VV4

Uteži za VV4 S1 S2 S3 S4 S5 K1 0,9 1 1 1,1 1,1 K2 1 1,1 1,1 1,2 1,2

Zmožnost upravljanja s poslovnimi procesi – VV5

Uteži za VV5 S1 S2 S3 S4 S5 K1 0,8 0,9 1 1,1 1,2 K2 0,8 1 1,2 1,4 1,6

Pregled nad procesi in podatki – VV6

39

Uteži za VV6 S1 S2 S3 S4 S5 K1 0,8 0,9 1 1,1 1,2 K2 0,8 1 1,2 1,4 1,6

4.4.2.3 Stroškovni vidik

Uteži komponent stroškovnega vidika definiramo sledeče:

1. Pomembnost stroškov uvedbe je za vse tipe podjetij enaka. 2. Pomembnost stroškov prilagoditev se veča s količino posebnosti v podjetju,

kajti podjetja z več posebnostmi bodo potrebovala več prilagoditev. 3. Pomembnost stroškov vzdrževanja je enaka za vse tipe podjetij.

Tabela VI: Tabela uteži – stroškovni vidik Stroški uvedbe (strojna oprema, licence programske opreme, uvajanje) – SV1

Uteži za SV1 S1 S2 S3 S4 S5 K1 1 1 1 1 1 K2 1 1 1 1 1

Stroški prilagoditev – SV2

Uteži za SV2 S1 S2 S3 S4 S5 K1 0,6 0,8 1 1,2 1,4 K2 0,7 1 1,3 1,6 1,9

Stroški vzdrževanja in nadgradenj (strojna oprema, programska oprema) – SV3

Uteži za SV3 S1 S2 S3 S4 S5 K1 1 1 1 1 1 K2 1 1 1 1 1

4.4.2.4 Ostali vidiki

Uteži komponent ostalih vidikov definiramo sledeče:

1. Pomembnost integracije z okoljem narašča s količino posebnosti v podjetju, kajti več posebnosti povečuje potrebo po integraciji.

2. Pomembnost referenc je za vse tipe podjetij enaka. 3. Pomembnost podpore in pomoči se veča s količino posebnosti v podjetju in

sicer z enako mero kot pomembnost integracije. 4. Pomembnost fleksibilnosti se veča s količino posebnosti v podjetju in sicer z

enako mero kot pomembnost integracije. 5. Pomembnost podpore iz različnih virov se veča s količino posebnosti v

podjetju in sicer z manjšo mero kot pomembnost integracije. 6. Pomembnost predznanj v podjetju se veča s količino posebnosti v podjetju in

sicer z enako mero kot pomembnost integracije. Tabela VII: Tabela uteži – ostali vidiki Integracija z okoljem – OV1

40

Uteži za OV1 S1 S2 S3 S4 S5 K1 0,8 0,9 1 1,1 1,2 K2 1 1,1 1,2 1,3 1,4

Reference – OV2

Uteži za OV2 S1 S2 S3 S4 S5 K1 1 1 1 1 1 K2 1 1 1 1 1

Podpora in pomoč – OV3

Uteži za OV3 S1 S2 S3 S4 S5 K1 0,8 0,9 1 1,1 1,2 K2 1 1,1 1,2 1,3 1,4

Fleksibilnost – OV4

Uteži za OV4 S1 S2 S3 S4 S5 K1 0,8 0,9 1 1,1 1,2 K2 1 1,1 1,2 1,3 1,4

Podpora iz različnih virov – OV5

Uteži za OV5 S1 S2 S3 S4 S5 K1 0,9 0,9 1 1 1,1 K2 1 1 1,1 1,1 1,2

Predznanja v podjetju – OV6

Uteži za OV6 S1 S2 S3 S4 S5 K1 0,8 0,9 1 1,1 1,2 K2 1 1,1 1,2 1,3 1,4

4.4.3 Ovrednotenje pomembnosti vidikov

V splošnem lahko ovrednotimo pomembnost vidikov tako: - tehnološki vidik (20 %) – 20, - vsebinski vidik (40 %) – 40, - stroškovni vidik (30 %) – 30, - ostali vidiki (10 %) – 10. Seveda pa dopuščamo možnost, da se v določenem podjetju korigirajo vrednosti pomembnosti vidikov.

4.5 Izračun ocen variant

Za definiranje ocen variant sestavimo v podjetju projektno ekipo, ki je sestavljena iz kompetentnih nosilcev vseh poslovnih področij v podjetju . Glede na podane ocene, uteži in vrednosti pomembnosti vidikov lahko izračunamo ocene posameznih variant. Celoten postopek izračuna ocen:

1. Za vsako varianto ocenimo vsako komponento vidika z oceno od 1 do 10. 2. Določimo uteži glede na tip podjetja. Uteži normiramo.

41

3. Za vsako varianto vsako komponento vidika pomnožimo z ustrezno utežjo. 4. Seštejemo ocene komponent vidikov in seštevek pomnožimo z vrednostjo

pomembnosti vidika. To vrednost potem pomnožimo s korekcijskim faktorjem, ki ga določimo glede na število komponent vidika (povprečno število komponent je 5, in vidik s 5 komponentami ima faktor 1,00000; vidik s 3 komponentami pa ima faktor 1,66667).

Enačba za izračun ocen variant:

TovKFovUovOovTsvKFsvUsvOsv

TvvKFvvUvvOvvTtvKFtvUtvOtvR

j

j

ijj

j

ij

j

j

ijj

j

iji

i

******

******

6..13..1

6..15..13,2,1

+

+

+

=

∑∑

∑∑

==

===

V enačbi smo uporabili naslednje oznake: - i : številka variante, - j : številka komponente vidika, - Oxvij : ocena komponente vidika (x je spremenljivka za 't', 'v', 's' in 'o'), - Uxvj : normirana utež komponente vidika, glede na tip podjetja, - KFxv : korekcijski faktor vidika, - Txv : pomembnost (ponder) vidika.

4.6 SWOT matrika (S - prednosti, W - slabosti, O - priložnosti, T - nevarnosti)

Za vsako od variant pripravimo SWOT matriko, v kateri so zajete vse prednosti, slabosti, priložnosti in nevarnosti določene variante. Tabela VIII: SWOT matrika S – prednosti Prikažemo vse prednosti, ki jih ima rešitev. SEDANJOST

W – slabosti Prikažemo vse slabosti, ki jih ima rešitev. SEDANJOST

O – priložnosti Prikažemo vse priložnosti, ki se pojavijo z rešitvijo.

T – nevarnosti Prikažemo vse nevarnosti, ki so povezane z rešitvijo.

42

PRIHODNOST

PRIHODNOST

S pomočjo SWOT matrik analiziramo naslednje komponente vidikov. Zopet izhajamo iz metodologij, predstavljenih v 3. poglavju (Kyte 2007, Lebinski 2001, Stefanou 2001, Wei in Wang 2004):

- vizija, ki je povezana z določenim tipom informacijskega sistema, skladnost z vizijo podjetja (pomembnost komponente je enaka za vse tipe podjetij);

- potencialni prihranki (pomembnost komponente je enaka za vse tipe podjetij); - ponovna uporaba investicije (pomembnost komponente je enaka za vse tipe

podjetij); - kvaliteta dobavitelja programske opreme (pomembnost komponente je enaka

za vse tipe podjetij); - vpliv na poslovanje, odločanje (pomembnost komponente je enaka za vse tipe

podjetij); - upravljanje z rešitvijo (pomembnost komponente se veča s količino posebnosti

v podjetju); - pričakovan življenjski cikel komponent (pomembnost komponente se veča s

količino posebnosti v podjetju); - možnosti pri nadaljnjem razvoju (pomembnost komponente se veča s količino

posebnosti v podjetju); - vse ostale prednosti, slabosti, priložnosti in nevarnosti.

4.7 Končni izbor

Na podlagi izračuna vrednosti vseh variant in opisnega prikaza vseh prednosti, slabosti, priložnosti in nevarnosti vsake rešitve izvedemo končni izbor najboljše variante. Poudarili bi, da predstavljajo ocene in SWOT matrike strukturiran vpogled v variante. Tako predstavljajo dobro izhodišče za končno odločitev, le-ta pa mora biti pretehtana tudi s človeško-izkustvenega vidika, kajti s spremembo informacijskega sistema podjetja spremenimo informacijsko infrastrukturo, ki posledično vodi v spremembe na vseh ravneh. Odločitev glede izbire mora torej zajemati tudi vidike vseh direktnih in indirektnih vplivov spremembe na poslovanje podjetja v najširšem smislu.

43

5 Apliciranje prilagojene metodologije na primeru podjetja Lisca d.d.

5.1 Predstavitev podjetja

Tekstilno-konfekcijska industrija velja za eno najbolj zahtevnih, to pa se odraža tudi na zelo kompleksnem informacijskem sistemu podjetja, ki je v grobem sestavljen iz treh delov:

- centralni informacijski sistem, - sistem BCR za spremljanje proizvodnje, - CAD/CAM sistem Lectra.

Centralni informacijski sistem teče na IBM Mainframe-u z9 BC. Operacijska sistema sta z/VM in Linux, podatkovna baza pa je DB2. Programska oprema je razvita s programskim orodjem VisualAge. Zajema pa podporo vsem ključnim poslovnim procesom v podjetju: nabava surovin in gotovih izdelkov, planiranje proizvodnje, planiranje, spremljanje in izvajanje prodajnih aktivnosti, skladiščno poslovanje ter finančno računovodstvo. Poleg tega imamo v podjetju ločen sistem BCR za spremljanje proizvodnje, ki teče na Linux platformi in podatkovni bazi Informix. Ločen CAD/CAM sistem služi za razvoj novih izdelkov, poleg tega pa omogoča optimiranje in izvedbo krojenja. Sistem teče na platformi Windows in Linux ter podatkovni bazi Oracle. Centralni informacijski sistem razvijamo sami s skupino programerjev, sistema BCR in Lectra pa sta kupljena in sta vzdrževana s strani zunanjih izvajalcev. Programska oprema v podjetju je torej zelo heterogena in zahtevna, kar se tiče vzdrževanja in nadgradenj. Že pred nekaj leti smo naredili analizo trga programske opreme in proučili možnost zamenjave obstoječega sistema s standardno rešitvijo. Analiza je pokazala, da je trg programske opreme za tekstilno-konfekcijsko industrijo še v povojih in je precej težko najti rešitev, ki bi vsaj v grobem pokrila poslovne procese našega podjetja. Preden pa se lotimo procesa izbora, bomo podrobneje analizirali največje ponudnike celovitih informacijskih rešitev ter največje ponudnike razvojnih platform. Predstavili bomo tudi tehnologije, ki omogočajo povezovanje tako informacijskih rešitev, kot razvojnih platform.

5.2 Predstavitev celovitih informacijskih sistemov

Največji ponudnik celovitih informacijskih sistemov tako v svetovnem merilu kot v Sloveniji je SAP (tabela II). Podjetju SAP sledi Oracle, ki je z nakupom PeopleSoft-a in Siebel Systems v 2005 postal eden največjih ponudnikov celovitih informacijskih rešitev (tabela II, Oracle 2007). Zelo močno prisoten v Sloveniji pa je tudi Navision/Microsoft Dynamics (Oh 2000), ki je pogosto ugodna rešitev za slovenska podjetja zaradi njihove relativne majhnosti.

44

5.2.1 SAP

Leta 1972 so štirje bivši IBM-ovi programerji v Mannheimu v Nemčiji ustanovili podjetje Systems, Applications and Products in Data Processing. Njihova vizija je bila razviti standarden programski paket za procesiranje poslovanja v realnem času. Eno leto pozneje so zaključili prvo verzijo R/1. Leta 1992 je bila izdana verzija R/3 z grafičnim vmesnikom, uporabo relacijske podatkovne baze in arhitekturo strežnik – odjemalec (SAP 2007). SAP poslovni paket (angl. »SAP Business Suite«) zajema naslednje pakete (SAP 2007):

- SAP ERP (angl. »Enterprise Resource Planning«), - SAP CRM (angl. »Customer Relationship Management«), - SAP SCM (angl. »Supply Chain Management«), - SAP SRM (angl. »Supplier Relationship Management«), - SAP PLM (angl. »Product Lifecycle Management«).

SAP ERP pokriva naslednja poslovna področja:

Analitika Analitika je namenjena vpogledu v poslovanje. Zgrajena je po principu samopostrežbe in temelji na vlogah. Omogoča strateško upravljanje, finančno analitiko, analitiko operacij ter analitiko delovne sile.

Finančno poslovanje Finančno poslovanje omogoča izvajanje finančnih aktivnosti ter kreiranje poročil. Sestavljeno je iz upravljanja finančne preskrbovalne verige, finančnega računovodstva, upravljalnega računovodstva ter korporacijskega nadzora.

Upravljanje s človeškim kapitalom Upravljanje s človeškim kapitalom je namenjeno maksimalnemu izkoriščanju potenciala delovne sile. Omogoča upravljanje s talenti, upravljanje s procesi delovne sile ter razvoj delovne sile.

Preskrba in logistika Preskrba in logistika omogočata procese preskrbe, upravljanje z zalogami in inventarjem, vhodno in izhodno logistiko ter upravljanje s transportom.

Razvoj produktov in proizvodnja Integriran sklop razvoja in proizvodnje omogoča zelo hitro pot od razvoja produkta do njegove postavitve na trg. Podpira planiranje proizvodnje, izvedbo proizvodnje, razvoj produktov ter upravljanje z življenjskim ciklom produktov.

Prodaja in servis Prodaja in servis omogočata upravljanje s prodajnimi naročili ter po-prodajne aktivnosti in servis.

Korporacijske storitve

45

Korporacijske storitve omogočajo upravljanje z nepremičninami, upravljanje s projekti, upravljanje s kvaliteto, upravljanje s potovanji, upravljanje z zdravjem, varnostjo itd.

SAP CRM pokriva naslednja poslovna področja:

Marketing Upravljanje s procesi marketinga in usmerjanje potreb kupcev, upravljanje z viri, vodenje projektov, promocije in analiza učinkov marketinga.

Prodaja Omogoča vzpostavljanje, rast in vzdrževanje donosnih odnosov s strankami z uporabo planiranja prodaje, napovedovanja trendov, upravljanje z območji, priložnostmi, naročili, cenami in pogodbami.

Servis Podporni servisi, ki omogočajo normalno delovanje procesov marketinga in prodaje. Upravljanje s pogodbami, reklamacijami, vračili, popravili, garancijami in analiza vseh teh aktivnosti.

SAP SCM pokriva naslednja poslovna področja:

Sodelovanje v preskrbovalni verigi

Upravljanje sodelovanja med vsemi udeleženci preskrbovalne verige, kupci, dobavitelji in proizvajalci.

Izvajanje preskrbovalne verige

Izvajanje procesa preskrbovale verige, izpolnjevanje naročil, transport, skladiščenje, proizvodnja in pregled nad vsemi procesi.

Planiranje preskrbovalne verige

Planiranje procesa preskrbovalne verige, napovedovanje prodaje in potreb, ocenjevanje obsega naročil, planiranje distribucije in celotne verige.

SAP SRM pokriva naslednja poslovna področja:

Upravljanje z nabavo

Upravljanje s procesi nabave, globalno spremljanje stroškov, upravljanje s skladnostjo procesov.

Iskanje virov preskrbe Iskanje virov preskrbe, spremljanje ponudb. Upravljanje z življenjskim ciklom pogodb Pregledovanje pogodb, pogajanja, izvajanje pogodb, spremljanje pogodb. Sodelovanje pri preskrbi Upravljanje s servisi preskrbe, direktna preskrba, planirana preskrba. Sodelovanje z dobavitelji

46

Interakcija preko spleta, direktna izmenjava dokumentov, mreža dobaviteljev. SAP PLM pokriva naslednja poslovna področja:

Planiranje portfelja

Planiranje portfelja in usklajevanje le-tega s poslovno strategijo. Portfelj predstavlja nabor produktov in storitev določenega podjetja.

Razvoj in proizvodnja Razvoj in proizvodnja produktov, dokumentacija, definiranje variant produktov. Servis Vzdrževanje uporabniških navodil, upravljanje s pritožbami, garancije.

SAP NetWeaver S stališča povezljivosti je zelo pomembna komponenta v SAP NetWeaver, integracijska platforma, ki je obenem tudi izvajalno ter razvojno okolje za SAP aplikacije. SAP NetWeaver nam omogoča uporabo SOA arhitekture in tako integracijo komponent v SAP s komponentami poljubnega informacijskega sistema, ki podpira SOA arhitekturo. SAP NetWeaver podpira tudi standarde Microsoft .NET in IBM WebSphere (SAP NetWeaver 2007). SAP je največji igralec na področju ERP za velika podjetja (AMR Research 2005). Integriran programski paket ima nadvse bogato vsebino in vsebuje znanja vseh podjetij, kjer je nameščen. Tako dobi podjetje, ki se odloči za nakup programske rešitve SAP, tudi ogromno znanja, kako optimalno izvajati določene poslovne procese. To lahko zelo koristi pri prenavljanju poslovnih procesov v podjetju. Programski paket obstaja v standardni obliki, so pa tudi rešitve za specifične industrije, npr. SAP AFS (Apperal and Footwear Solution) za tekstilno-konfekcijsko ter čevljarsko industrijo. Podprti operacijski sistemi so MS Windows, HP-UX, AIX, Solaris, Linux in OS/400, podatkovne baze pa MS SQL Server, SAP DB / MaxDB, IBM Informix, IBM DB2 in Oracle. Programski paket je razvit z razvojnim orodjem ABAP (SAP 2007). Programski paket je namenjen predvsem velikim podjetjem in korporacijam, zadnje čase pa se rešitev prilagaja tudi srednjim in manjšim podjetjem. Zaradi kompleksnosti programskega paketa je temu primeren tudi čas uvedbe, ki je po navadi večji od enega leta.

5.2.2 Navision / Microsoft Dynamics NAV

Navision Software A/S je bil ustanovljen leta 1984 na Danskem. Leta 2000 se je združil z danskim podjetjem Damgard. Prelomno je bilo leto 2002, ko je Navision

47

prevzel Microsoft. Microsoft je programski paket poimenoval Microsoft Dynamics NAV. Zadnja verzija je 5.0 (Microsoft Dynamics 2008). Microsoft Dynamics NAV pokriva naslednja poslovna področja:

Finančno poslovanje Finančno poslovanje predstavlja hrbtenico poslovne rešitve. Omogoča spremljanje in analiziranje vseh poslovnih informacij. Integracija omogoča upravljanje skladiščnega poslovanja, plačila, prejeme, zaloge, analitično računovodstvo, osnovna sredstva ter izvajanje finančnih transakcij z bankami. Finančne procese lahko upravljamo med različnimi valutami, lokacijami in podjetji.

Proizvodnja Integriran sklop proizvodnih aplikacij omogoča planiranje, upravljanje in izvedbo proizvodnih operacij med različnimi proizvodnimi enotami na različnih lokacijah. Podprti so delovni nalogi, materialni in časovni normativi, planiranje preskrbe ter planiranje potrebnih kapacitet.

Upravljanje preskrbovalne verige (SCM) Integrirana podpora nabavi, prodaji in skladiščnemu poslovanju omogoča upravljanje s celotnim procesom preskrbovalne verige. Podprte so različne vrste skladišč, ki so centralizirana ali pa so na več lokacijah, različne vrste naročil in planiranje zahtev.

Poslovna inteligenca in poročila Poročila, analize in dostop do informacij, ki so kritične za poslovanje, omogočajo uspešno upravljanje poslovnih procesov ter sprejemanje kritičnih odločitev. Omogočeno je upravljanje s sredstvi, kreiranje konsolidiranih poročil ter vpogled v trende in relacije med podatki.

Upravljanje odnosov s strankami (CRM) Upravljanje odnosov s strankami omogoča avtomatizacijo mnogih dnevnih opravil, ki jih izvajajo zaposleni v prodaji in marketingu. Omogoča spremljanje podatkov o kontaktih s strankami, njihovo zgodovino, kreiranje in izvajanje marketinških akcij. V servisnih službah je s spremljanjem njihove aktivnosti omogočeno upravljanje s človeškimi viri, kar omogoča optimizacijo prodajnega procesa.

Sodelovanje v delovnem prostoru Tovrstno sodelovanje omogoča zaposlenim boljšo medsebojno komunikacijo in deljenje informacij in podatkov. Zaposleni, ki sodelujejo na istem projektu, lahko enostavno sodelujejo. Možna je povezava z MS SharePoint Portal.

Konfiguriranje in razvoj MS Dynamics NAV ima vgrajena orodja za spreminjanje in prilagajanje programskega paketa spremembam v poslovnih procesih. Tako lahko ekipa programerjev in administratorjev sistema v podjetju, kjer je implementirana poslovna rešitev, spreminja in dopolnjuje funkcionalnost poslovne rešitve. Prav tako je možen dostop do standardnih orodij in tehnologij, ki jih uporabljajo razvijalci po svetu.

48

Upravljanje s človeškimi viri (HRM)

Ta modul omogoča organiziranje in upravljanje z informacijami o zaposlenih v podjetju. Možno je dodajanje zapiskov k podatkom o zaposlenih, spremljanje odsotnosti, kreiranje poročil.

Upravljanje s projekti Podpora aktivnostim, ki trajajo daljše časovno obdobje. Omogočen je nadzor nad stroški ter viri, upravljanje z viri, stroški ter predvidevanje razpoložljivosti.

Programski paket Navision/Microsoft Dynamics NAV je v času od nastanka postal vsebinsko zelo bogat in podpira večino poslovnih procesov, ki se odvijajo v sodobnih proizvodnih in drugih podjetjih. Poleg standardne rešitve obstajajo tudi rešitve za specifične industrije, kot je npr. Navision Pebblestone, ki je nadgrajen s potrebno funkcionalnostjo za podporo poslovnim procesom tekstilno-konfekcijske industrije. Podprti operacijski sistem je samo MS Windows, podatkovni baze pa Navision database in MS SQL Server. Programski paket je razvit z razvojnim orodjem C/SIDE (Microsoft Dynamics 2008). Programski paket Navision/Microsoft Dynamics NAV je primeren za majhna in srednja podjetja. V slovenskem prostoru to pomeni večino podjetij. Zaradi svoje fleksibilnosti je zelo primeren tudi za podporo poslovanja manjših povezanih družb (npr. centralno podjetje uporablja SAP ali lastno programsko rešitev, hčerinsko podjetje v drugi državi pa Navision/Microsoft Dynamics).

5.2.3 Oracle

Leta 1977 so Larry Ellison, Bob Miner in Ed Oates ustanovili podjetje Software Development Laboratories, ki je bil predhodnik podjetja Oracle. Leta 1978 so izdali podatkovno bazo Oracle v1 (Oracle 2007). Leta 1987 so poleg razvoja podatkovne baze Oracle pričeli tudi z razvojem programske opreme Oracle Applications. Leta 2000 so izdali Oracle e-business Suite, celovit informacijski sistem, leta 2005 pa so prevzeli še konkurenčno podjetje PeopleSoft (pred tem je leta 2003 PeopleSoft prevzel podjetje JD Edwards) in podjetje Siebel Systems. Oracle daje velik poudarek odprtim sistemom in operacijskemu sistemu Linux (Oracle 2007). Oracle tako na področju informacijskih rešitev ponuja naslednje produkte (Oracle 2008):

- Oracle e-business Suite Celovit informacijski sistem sestavljen iz naslednjih modulov:

o upravljanje z življenjskim ciklom imetja (proizvodnih obratov, opreme, zalog in strojev),

o upravljanje odnosov s kupci (CRM), o upravljanje z viri v podjetju (ERP), o preskrba,

49

o upravljanje z življenjskim ciklom produktov (PLM), o upravljanje preskrbovalne verige (SCM), o proizvodnja.

- PeopleSoft Enterprise

Celovit informacijski sistem sestavljen iz naslednjih modulov:

o upravljanje z življenjskim ciklom imetja (proizvodnih obratov, opreme, zalog in strojev),

o rešitve za izobraževalne ustanove, o upravljanje odnosov s kupci (CRM), o upravljanje z zmogljivostjo korporacij, o upravljanje s projekti, o upravljanje s financami, o upravljanje s človeškim kapitalom , o upravljanje odnosov z dobavitelji (SRM), o upravljanje preskrbovalne verige (SCM), o PeopleSoft orodja.

- Siebel

Informacijski sistem za upravljanje odnosov s kupci (CRM).

- JD Edwards Celovit informacijski sistem sestavljen iz naslednjih modulov:

o analitika, o upravljanje s kapitalom, o upravljanje odnosov s kupci (CRM), o upravljanje s financami, o moduli za proizvajalce hrane in pijač, o upravljanje s človeškim kapitalom, o proizvodnja, o upravljanje z naročili, o upravljanje s projekti, o moduli za upravljanje z nepremičninami in konstrukcijo hiš, o planiranje preskrbovalne verige, o izvedba preskrbovalne verige, o preskrba, o dodatna orodja.

Oracle je z nakupi pridobil zelo bogat nabor informacijskih rešitev, vendar se te rešitve vsebinsko prekrivajo, zato je Oracle pričel z gradnjo Oracle Fusion aplikacij. Le-te bodo poenotile najboljše rešitve v okviru podjetja Oracle v celovit informacijski sistem, zgrajen na odprtih tehnologijah (Oracle 2008).

5.3 Predstavitev razvojnih platform

Ne glede na izbiro tipa informacijskega sistema potrebujemo orodje, s katerim dopolnjujemo, povezujemo obstoječe rešitve ali pa gradimo nove. Izdelani celoviti

50

informacijski sistemi imajo navadno vgrajen tudi svoj programski jezik za razvoj in modifikacijo aplikacij (npr. SAP ima ABAP). Vendar pa se vsi usmerjajo proti odprtim tehnologijam, ki omogočajo povezovanje programske rešitve s tehnologijami Java EE in .NET.

5.3.1 Razvojne platforme

Na trgu programske opreme obstaja cela množica razvojnih orodij. Vendar sta glavna igralca samo dva: Microsoft Visual Studio s platformo Windows in .NET ter WebSphere z različnimi platformami (Windows, Linux, Unix, z/OS) in Java EE. Analitiki ugotavljajo, da je nesmiselno ugotavljati, katera rešitev je boljša oz. katera bo prevladala. Dejstvo je, da bosta v naslednjih nekaj letih na trgu prisotni obe rešitvi. Prva, za katero stoji Microsoft, je relativno enostavna in zmogljiva, druga, za katero stoji IBM, pa je odprta in fleksibilna. Gartner napoveduje, da bosta v letu 2008 imeli obe platformi približno enak tržni delež.

Slika 10: Uporaba tehnologij Java EE in .NET (Hoppermann 2005) Slika 10 kaže trend v evropskih finančnih podjetjih, ki se nagiba v prid tehnologije Java EE (Hoppermann 2005). Gartnerjeva raziskava kaže, da bosta v prihodnosti pridobivali platformi .NET in Java, ostale platforme pa bodo počasi izgubljale svoj delež (Driver 2003). Na sliki 11 pa vidimo, kakšna je porazdelitev platform glede na industrijo. Pri storitvah in telekomunikacijah ter v finančnih in bančnih ustanovah je v prednosti platforma Java EE. Pri ostalih pa je v prednosti .NET. Poudariti je treba, da gre tu za trg Severne Amerike (Wilkoff 2004).

51

Slika 11: Primerjava uporabe tehnologij v razvojnih projektih (Wilkoff 2004) Obe platformi podpirata spletne storitve, XML in ostale tehnologije, ki omogočajo povezovanje različnih sistemov med seboj. Tehnologija nam torej omogoča, da lahko glede na potrebe izberemo primerno rešitev in jo ustrezno integriramo z rešitvami, ki lahko tečejo na drugi platformi.

5.3.2 IBM Rational Application Developer za WebSphere

IBM Rational Application Developer za WebSphere temelji na platformi Eclipse. Platforma Eclipse je okolje odprte kode za kreiranje, integracijo in namestitev orodij za razvoj aplikacij za uporabo v širokem spektru računalniških tehnologij. Zagotavlja skupen nabor storitev in tako postavlja ogrodje, infrastrukturo in interaktivno delovno okolje, ki ga lahko uporabljajo razvijalci programske opreme za razvoj aplikacij in ostalih odvisnih elementov (Wahli et al. 2007). S platformo Eclipse je možna integracija orodij različnih proizvajalcev na delovnih postajah Microsoft Windows, Linux in QNX. Platforma Eclipse omogoča različne perspektive uporabniških vmesnikov za različne vloge uporabnikov. Perspektiva je predhodno definiran nabor pogledov (z možnostjo uporabniških nastavitev) na orodja in podatke, ki so dodani v okolje. Platforma Eclipse je razvita za:

- gradnjo IDE-jev (angl. »Integrated Development Enviroment«); - podporo različnim proizvajalcem orodij, vključno z neodvisnimi proizvajalci

programskih orodij, ki lahko s specifikacijo, kako se orodje vključi v okolje, delijo storitve in delovno okolje;

52

- podporo orodjem za kreiranje in manipulacijo z vsemi produkti za razvoj. Sem spadajo vsi produkti, ki so vsebovani v Java EE modelu, kot npr. HTML, tehnologija Java, JSP, EJB, XML, GIF;

- podporo integraciji več izvajalnih okolij za Javo. To omogoča razvoj aplikacij za različne ciljne platforme;

- podporo integraciji različnih testnih in produkcijskih okolij. Npr. WebSphere Application Server ali Apache Tomcat Server;

- podporo integraciji orodij in dostop do storitev, ki tečejo med različnimi platformami;

- podporo platformi Windows in Linux. Delovno okolje v IBM Rational Application Developer je IBM-ova verzija platforme Eclipse. IBM Rational Application Developer temelji na Javi – Java EE. Orodje omogoča razvoj spletnih aplikacij, spletnih storitev ter klasičnih aplikacij tipa odjemalec-strežnik v programskem jeziku Java. Poleg tega so v razvojno okolje integrirana tudi orodja za razvoj aplikacij na velikih računalniških sistemih (Mainframe) z orodji EGL (angl. »Enterprise Generation Language«). Orodje ima integrirano tudi orodje za upravljanje z verzijami programske kode CVS (angl. »Concurrent Versions System«), poleg tega pa je vgrajena podpora za UML (angl. »Unified Modelling Language«).

Slika 12: IBM Rational Application Developer za WebSphere (povz. po Wahli et

al. 2007)

53

Odprti standardi Odprti industrijski standardi zagotavljajo način, da predvidimo določen nivo funkcionalnosti in povezljivosti med različnimi proizvajalci programske opreme in storitev. IBM Rational Application Developer podpira naslednje odprte standarde:

- standardi spletnih storitev (angl. »Web services standards«), ki omogočajo integracijo poslovanja, npr. XML (angl. »Extensible Markup Language«), SOAP (Simple Object Access Protocol), WSDL (angl. »Web Service Description Language«), UDDI (angl. »Universal Description, Discovery and Integration«), ne glede na ciljno platformo in implementacijske tehnologije;

- komponentni standardi (angl. »Component standards«), npr. EJB (angl. »Enterprise JavaBeans«);

- standardi povezljivosti (angl. »Connectivity standards«), ki omogočajo asinhrone transakcije z uporabo JCA (angl. »Java Connectivity Architecture«) in JDBC (angl. »Java Database Connectivity«);

- sporočilni standardi (angl. »Message standards«), ki omogočajo zanesljiva sporočila in upravljanje z asinhronimi transakcijami z uporabo sporočilnih zrn (angl. »message-driven beans«), kot so JMS (angl. »Java Message Service«) in MQ (angl. »Message Queue«).

IBM prav tako podpira operacijski sistem Linux. Ponuja ga kot opcijo odprtega sistema na svojih platformah strojne opreme. Poleg tega IBM ponuja tudi razvojna okolja in aplikacije, ki tečejo na platformi Linux. Tako sta WebSphere Application Server in IBM Rational Application Developer na voljo za več distribucij platforme Linux. Java EE (angl. »Java Enterprise Edition«) Zelo poenostavljena definicija specifikacije Java EE je »nabor integriranih Java API-jev, ki omogočajo spletne aplikacije tipa odjemalec-strežnik« (Nilsson, Mauget 2003). Java EE je zasnovana tako, da podpira večnivojsko arhitekturo (angl. »multiple tiers«). V poenostavljenem primeru je to odjemalec, Java EE strežnik in podatkovni strežnik. WebSphere Application Servers WebSphere aplikacijski strežniki implementirajo Java platformo, specifikacijo Java EE. Predstavljajo okolje za namestitev, izvajanje in upravljanje Java EE aplikacij. Na voljo so v različnih konfiguracijah in tečejo na različnih platformah (UNIX, Microsoft Windows, IBM z/OS). Aplikacijski strežniki so na voljo v petih različicah, od osnovne - Express do najzmogljivejše – Enterprise. Vidiki v IBM Rational Application Developer Delovno okolje v IBM Rational Application Developer je zgrajeno na principu vidikov. Tako imamo za vsako aktivnost (npr. programiranje v Javi, načrtovanje z UML, razhroščevanje) definiran vidik, ki pomeni prilagojeno delovno površino.

54

5.3.3 Microsoft Visual Studio

Microsoft Visual Studio zajema celoten nabor razvojnih orodij za razvoj ASP spletnih aplikacij, XML spletnih storitev, standardnih grafičnih aplikacij in mobilnih aplikacij. Visual Basic .NET, Visual C++ .NET, Visual C# .NET in Visual J# .NET uporabljajo isto integrirano razvojno ogrodje (IDE), kar omogoča skupno uporabo orodij pri kreiranju programskih rešitev v različnih programskih jezikih (Johnson, Skibo, Young 2003). Poleg tega vsi ti programski jeziki izkoriščajo .NET Framework, le-to pa omogoča dostop do tehnologij, ki poenostavljajo razvoj ASP spletnih aplikacij in XML spletnih storitev. Microsoft Visual Studio omogoča razvoj spletnih aplikacij, spletnih storitev, klasičnih aplikacij tipa strežnik-odjemalec z različnimi programskimi jeziki. Microsoft Visual Studio teče samo na MS Windows platformi. Visual J#, Visual C# Visual J# je namenjen razvijalcem, ki dobro poznajo sintakso programskega jezika Java. S tem razvojnim orodjem lahko razvijalci razvijajo aplikacije in storitve, ki tečejo na .NET Framework. Visual J# integrira sintakso programskega jezika Java v razvojno ogrodje Visual Studio .NET. Vendar pa Visual J# ni namenjen razvoju aplikacij, ki tečejo na Java Virtual Machine, kajti razvit je bil neodvisno s strani Microsofta. Visual C# je, podobno kot Visual C#, razvit neodvisno s strani Microsofta. Je nekakšen hibrid med C, C++ in Javo. Namenjen je razvoju aplikacij, XML spletnih storitev, distribuiranih komponent ter seveda klasičnih odjemalskih aplikacij. Aplikacije za pametne naprave (PDA) Razvojno ogrodje Microsoft Visual Studio vsebuje tudi orodja za razvoj aplikacij za pametne naprave (PDA), npr. Pocket PC. Z uporabo orodij in ogrodja .NET Compact Framework, ki je podmnožica ogrodja .NET Framework, lahko razvijamo aplikacije, ki jih lahko namestimo na pametne naprave in prenosne telefone. Web Forms Web forms so ASP.NET tehnologija, ki omogoča kreiranje programiranih spletnih strani. Spletne forme se obnašajo kot HTML in koda, ki omogoča različnim brskalnikom na različnih platformah pregledovanje teh strani. Z uporabo spletnih form lahko zelo enostavno oblikujemo spletne strani, podobno kot kreiramo klasične grafične forme v Visual Basic-u. Windows Forms Windows Forms so nova platforma za razvoj grafičnih dvo-nivojskih MS Windows aplikacij, ki temelji na ogrodju .NET Framework. To ogrodje vsebuje bogat nabor objektov, ki omogočajo razvoj bogatih Windows aplikacij. Poleg tega lahko Windows forme nastopajo kot uporabniški vmesnik pri več-nivojskih distribuiranih rešitvah.

55

XML spletne storitve XML spletne storitve so aplikacije, ki sprejemajo zahteve in podatke z uporabo XML preko protokola HTTP. XML spletne storitve niso vezani na nobeno komponentno tehnologijo in jih tako lahko dosegamo s katerega koli programskega jezika, komponentnega modela ali operacijskega sistema. S pomočjo WDSL (angl. »Web Service Description Language«) in protokola HTTP lahko tako uporabljamo XML spletne storitve, ki so nameščeni na enem izmed strežnikov v spletu (Johnson, Skibo, Young 2003). Uporaba XML spletnih storitev nam tako prihrani ogromno časa, saj lahko komponente aplikacij poiščemo v spletu in nato iz teh gradnikov sestavimo aplikacijo. Podpora za XML XML je metoda zapisa strukturiranih podatkov, ki v svoji strukturi nosi tudi opis te strukture. XML je podmnožica standarda SGML, ki je optimiziran za prenose podatkov po Internetu. Organizacija W3C definira XML standarde tako, da je struktura podatkov enoznačna in neodvisna od aplikacij in razvojnih orodij. Visual Studio .NET popolnoma podpira XML in omogoča enostavno kreiranje XML shem. .NET Framework .NET Framework je večjezično ogrodje za razvoj, namestitev in poganjanje XML spletnih storitev in aplikacij. Sestavljeno je iz treh delov:

1. Večjezično izvajalsko okolje (angl. »Common Language Runtime«) Večjezično izvajalsko okolje ima pomembno vlogo tako pri izvajanju kot pri razvoju komponent. Med izvajanjem komponent skrbi okolje za upravljanje s spominom, zaganjanjem in ugašanjem procesov in niti, upravljanjem z varnostjo, prav tako pa skrbi za vse interakcije z ostalimi komponentami. V času razvoja komponent pa služi avtomatizaciji postopkov in poenostavlja razvojna opravila.

2. Enotni programski objekti (angl. »Unified programming classes«) Ogrodje ponuja razvijalcem enoten objektno-orientiran, hierarhičen in razširljiv nabor knjižnic razredov (APIs). Te knjižnice lahko uporabljajo tako razvijalci v programskem jeziku C++ kot razvijalci v Visual Basic-u ali JScript-u. Tako je možno tudi dedovanje med različnimi programskimi jeziki, skupno razhroščevanje in skupno reševanje napak.

3. ASP.NET ASP.NET omogoča gradnjo ASP spletnih aplikacij. ASP.NET vsebuje množico kontrol, ki vsebujejo splošne HTML gradnike, kot so tekstovne škatle, padajoče menije, itd. Te kontrole tečejo na spletnem strežniku, vendar pošljejo uporabniški vmesnik brskalniku kot HTML. ASP.NET omogoča tudi podporne storitve, kot so upravljanje s stanjem seje, kar poenostavlja razvoj aplikacij. Z uporabo XML spletnih storitev lahko uporabniki razvijajo poslovno logiko in z uporabo ASP.NET infrastrukture ponudijo storitev v obliki SOAP.

56

5.4 SOA (Service-Oriented Architecture)

Predstavili smo arhitekturi .NET in Java EE, ki sta prevladujoči na trgu. Delita si približno enak tržni delež in glede na različna področja imata vsaka svoje prednosti uporabe (Slika 10). Povezovanje in integracija različnih arhitektur sta torej ključni za optimalen razvoj programske opreme. SOA je arhitektura, ki nam to povezovanje in integracijo omogoča. SOA je evolucijsko nadaljevanje distribuiranih sistemov in modularnega programiranja. Pri SOA arhitekturi gradimo aplikacije iz storitev. Storitve so relativno velike, samostojne funkcionalne enote. Navadno implementirajo funkcionalnosti, ki jih večina ljudi razume kot storitve, npr. izvedba naročila za nakup knjige ali nakup letalske vozovnice. Storitve ne vsebujejo vgrajenih klicev med seboj, namesto tega obstajajo protokoli, ki opisujejo, kako storitve komunicirajo med seboj. Takšna arhitektura omogoča načrtovalcu poslovnih procesov povezovanje storitev. Ta proces se imenuje orkestracija (angl. »Orchestration«). Orkestracija povezuje storitve v ne-hierarhičen sistem (Wiki 2007). V ozadju arhitekture SOA so metapodatki (angl. »Metadata«), ki opisujejo značilnosti storitev, prav tako pa podatki, ki jih poganjajo. SOA navadno uporablja XML za manipulacijo s podatki, WDSL za opis storitev in SOAP za komunikacijski protokol. Poudariti pa je potrebno, da SOA ni vezana na nobeno tehnologijo, torej jo lahko implementiramo tudi s tehnologijami, kot so RPC, DCOM ali CORBA. Glavni cilj SOA arhitekture je omogočiti razvijalcem, da uporabijo relativno velike kose funkcionalnosti–storitve in jih povežejo v aplikacije. Podjetja lahko tako povezujejo obstoječe aplikacije, razvite s starejšimi programskimi jeziki (COBOL, PL/1 ali Fortran) in sodobne programske jezike (Java). Tako lahko na primer razvijemo predstavitveni del aplikacije v Javi, v grafičnem okolju, poslovno logiko pa lahko procesira storitev, ki je razvita v COBOL-u. Na ta način lahko podjetja ohranijo ogromno vrednost v obliki razvite programske kode, to pa ne predstavlja nobene omejitve pri izbiri platforme za razvoj novih aplikacij. Poleg tega je vedno večje število podjetij, ki ponujajo plačljive storitve na Internetu. Tako lahko podjetje zgradi aplikacijski sistem, ki temelji na SOA arhitekturi in del storitev izdela sam, drugi del pa predstavljajo plačljive storitve, ki jih ponujajo neodvisna podjetja.

57

Slika 13: SOA Meta Model (The Linthicum Group 2007) SOA principi Naslednji principi definirajo osnovna pravila pri razvoju, vzdrževanju in uporabi SOA arhitekture:

- ponovna uporaba, granulacija, modularnost, zmožnost sestavljanja, sestavljenost iz komponent, zmožnost povezovanja različnih sistemov;

- skladnost s standardi; - identifikacija in kategorizacija storitev.

Storitveno vodilo (ESB, angl. »Enterprise Service Bus«) Storitveno vodilo, odprt standard za prenos sporočil, ki je hrbtenica SOA arhitekture, in deluje kot posrednik sporočil z uporabo standardnih specifikacij za sporočila, kot so SOAP ali JMS (angl. »Java Messaging Service«) (IBM 2007).

58

Slika 14: Arhitektura storitvenega vodila (ESB) (IBM 2007) Način izvedbe SOA arhitekture s spletnimi storitvami Za implementacijo SOA arhitekture lahko uporabimo spletne storitve. Bistveno pri tej implementaciji je, da so funkcionalni gradniki dostopni preko standardnih internetnih protokolov in neodvisni od platform in programskih jezikov. Te storitve so lahko nove aplikacije ali pa so to stare aplikacije, ki so z ovojnico pripravljene za delo preko mreže/ Interneta (Wiki 2007). Vsak SOA gradnik se lahko pojavlja v oblike ene ali več vlog:

1. Ponudnik storitve Ponudnik storitve kreira spletno storitev in po možnosti objavi njen vmesnik v storitveni imenik. Vsak ponudnik mora oceniti, katere storitve bo objavil, kako bo uravnotežil razmerje med enostavno dostopnostjo in varnostjo in kako jih bo tržil.

2. Posrednik storitve Posrednik storitve, ki ga drugače imenujemo tudi storitveni imenik, je zadolžen, da je vmesnik spletne storitve na razpolago kateremu koli potencialnemu odjemalcu. Izdelovalec posrednika odloča o dometu posrednika. Javni posredniki so na razpolago preko Interneta, zasebni posredniki pa preko lokalnega omrežja nekega podjetja oz. Intraneta. Specifikacija UDDI definira, kako objavljati in iskati informacije glede spletnih storitev.

3. Odjemalec storitve

59

Odjemalci storitev iščejo zapise v imeniku posrednika in se potem povežejo s ponudnikom storitve z namenom uporabe določene spletne storitve.

5.5 Povezovanje arhitektur Java EE in .NET

V tabeli IX je prikazana primerjava tehnologij Java EE in .NET. Iz tabele je razvidno, da sta si tehnologiji precej podobni, razlikujeta se predvsem v načinu izvedbe. Tabela IX: Primerjava arhitektur Java EE in .NET (Estes, Maxime 2003)

Funkcija .NET Java EE Dostop do baze podatkov ADO.NET JDBC Web odjemalec ASP.NET JSP (Java Server Pages)

in Servlet-i Samostojni odjemalec Windows Forms AWT/Swing Distribuirane komponente .NET Remoting RMI/IDL XML System.Xml in .NET Paket JAX Sporočilne storitve MSMQ (Microsoft

Message Queuing) JSM (Java Messaging Service)

Podpora spletnim storitvam

Vgrajena direktno v .NET in Visual Studio

JWSDP (Java Web Services Developer Pack)

Spletne komponente/transakcije

COM+ EJB (Enterprise Java Beans)

Integracija Host Integration Server, BizTalk Server

Java EE Connector Architecture

Registracija komponent Active Directory JNDI (Java Naming and Directory Interface)

V praksi se podjetja srečujejo z vprašanjem, kako v okviru SOA arhitekture povezati med seboj ti dve tehnologiji. Rešitev je več:

1. Dvosmerno mostičenje (angl. »bridging«) Java EE/.NET V tej rešitvi uporabimo .NET Remoting protokola, ki je del .NET platforme, implementirati moramo samo vmesnik v Javi, ki omogoča .NET Remoting na strani Java EE.

2. MQ (angl. »Message Queuing«) Pri tej rešitvi Java aplikacije komunicirajo z .NET aplikacijami s pomočjo MQ strežnika (npr. WebSphere MQ Server).

3. Vmesniki spletnih storitev Spletne storitve so namenjeni povezovanju komponent in na ta način lahko Java EE storitve preko SOAP/HTTP protokola komunicirajo z .NET storitvami. Pristop temelji na uveljavljenih standardih in je zato najbolj priljubljen (Yee 2004).

5.6 Izbor

60

V projektu analize trga programske opreme, ki je bil izveden v letu 2003, smo v podjetju Lisca ugotovili, da imamo v poslovanju precej specifičnih poslovnih procesov, glede na referenčne modele programskih rešitev. Ugotovili smo tudi, da je odločitev o tipu informacijskega sistema močno povezana s količino specifičnih poslovnih procesov v podjetju. Vse te ugotovitve so nas pripeljale do vprašanja: Kakšen tip informacijskega sistema je najbolj primeren za podjetje Lisca, glede na specifičnost njenih poslovnih procesov? Z uporabo metodologije, predstavljene v 4. poglavju, bomo odgovorili na to vprašanje. Identificirali bomo najboljšo rešitev, neobremenjeni s trenutno informacijsko rešitvijo. Upoštevali bomo le kadrovsko situacijo in znanja, ki jih kadri posedujejo.

5.6.1 Priprava projekta

Definiramo projekt izbire tipa informacijskega sistema. Projekt ima definiran cilj: identifikacija najboljšega tipa informacijskega sistema za podjetje Lisca d.d. Sestavimo projektno ekipo, ki vodi in izvaja projekt. Projektno ekipo sestavljajo ključni nosilci poslovnih področij proizvodnje, logistike, prodaje, nabave, razvoja, financ in računovodstva ter informatike. Projektna ekipa analizira trg in identificira potencialne programske rešitve in orodja, ki so na voljo, ter zbere informacije, ki so relevantne v kontekstu projekta.

5.6.2 Definiranje variant

Prvi korak pri definiranju variant je določitev kriterijev, ki nam omogočajo omejiti selekcijo. V podjetju Lisca d.d. postavimo tri osnovne kriterije, ki jih morajo izpolnjevati programske rešitve:

1. Programska rešitev mora biti prilagojena tekstilno-konfekcijski industriji. 2. Programska rešitev mora imeti reference v Sloveniji, prilagojena mora biti

slovenski zakonodaji in zagotovljena mora biti podpora strankam na področju Slovenije.

3. V kontekstu celovite rešitve se v podjetju Lisca omejimo na ERP in CRM. Na podlagi osnovnih kriterijev naredimo selekcijo in dobimo naslednji nabor variant:

Varianta A: Standarden celovit informacijski sistem SAP AFS (angl. »Apperal and Footwear Solution«) ERP in SAP CRM. SAP AFS je različica produkta SAP ERP, ki je namenjena tekstilno-konfekcijski ter čevljarski industriji.

Operacijski sistem: MS Windows. Podatkovna baza: Oracle. Razvojno orodje: ABAP.

Varianta B: Integracija najboljših rešitev (BoB).

o ADD CRM je produkt za CRM (angl. »Customer Relationship Management«) slovenskega podjetja ADD. Operacijski sistem: MS Windows. Podatkovna baza: MS SQL Server. Razvojno orodje: MS Visual Studio .NET.

61

o BCR je produkt nemškega podjetja Winterthur in je namenjen

pokrivanju procesa spremljanja proizvodnje. Prilagojen je tekstilno konfekcijski industriji. Operacijski sistem: Linux. Podatkovna baza: Informix. Razvojno orodje: Genero Four J's.

o Navision Pebblestone, s katerim bi pokrivali procese nabave, prodaje, načrtovanja proizvodnje, skladiščnega poslovanja ter finančnega poslovanja. Rešitev je prilagojena tekstilno-konfekcijski industriji. Operacijski sistem: MS Windows. Podatkovna baza: MS SQL Server. Razvojno orodje: C/SIDE.

Varianta C: Razvoj informacijskega sistema po meri

Operacijski sistem: IBM z/VM, Linux. Podatkovna baza: IBM DB2. Razvojno orodje: IBM WebSphere (Java).

5.6.3 Določitev ocen vidikov in njihovih komponent

V podjetju Lisca smo sestavili projektno ekipo, ki je določila ocene vidikov. Projektna ekipa je bila sestavljena iz ključnih uporabnikov, ki so vsebinsko detajlno poznali poslovna področja (nabava in preskrba, prodaja, proizvodnja, finance in računovodstvo in razvoj).

5.6.3.1 Tehnološki vidik

Tabela X: Tabela ocen – tehnološki vidik Razvojno orodje / programski jezik – TV1

Varianta A Varianta B Varianta C Ocena 6 6 9

Baza podatkov – TV2

Varianta A Varianta B Varianta C Ocena 10 8 9

Operacijski sistem – TV3

Varianta A Varianta B Varianta C Ocena 7 7 8

Varnost – TV4

Varianta A Varianta B Varianta C Ocena 8 7 9

Povezljivost / arhitektura – TV5

Varianta A Varianta B Varianta C Ocena 9 8 7

62

5.6.3.2 Vsebinski vidik

Tabela XI: Tabela ocen – vsebinski vidik Pokrivanje standardnih poslovnih procesov – VV1

Varianta A Varianta B Varianta C Ocena 10 8 6

Prilagodljivost specifičnim poslovnim procesom – VV2

Varianta A Varianta B Varianta C Ocena 6 7 8

Prilagodljivost pri spreminjanju poslovnih procesov – VV3

Varianta A Varianta B Varianta C Ocena 6 7 8

Zmožnost podpore novo-nastalih poslovnih procesom – VV4

Varianta A Varianta B Varianta C Ocena 6 7 8

Zmožnost upravljanja s poslovnimi procesi – VV5

Varianta A Varianta B Varianta C Ocena 9 7 6

Pregled nad procesi in podatki – VV6

Varianta A Varianta B Varianta C Ocena 10 5 8

5.6.3.3 Stroškovni vidik

Tabela XII: Tabela ocen – stroškovni vidik Stroški uvedbe (strojna oprema, licence programske opreme, uvajanje) – SV1

Varianta A Varianta B Varianta C Ocena 5 7 9

Stroški prilagoditev – SV2

Varianta A Varianta B Varianta C Ocena 6 7 8

Stroški vzdrževanja in nadgradenj (strojna oprema, programska oprema) – SV3

Varianta A Varianta B Varianta C Ocena 5 8 6

5.6.3.4 Ostali vidiki

Tabela XIII: Tabela ocen – tehnološki vidik Integracija z okoljem – OV1

Varianta A Varianta B Varianta C

63

Ocena 9 7 6 Reference – OV2

Varianta A Varianta B Varianta C Ocena 10 8 1

Podpora in pomoč – OV3

Varianta A Varianta B Varianta C Ocena 10 8 5

Fleksibilnost – OV4

Varianta A Varianta B Varianta C Ocena 7 8 7

Podpora iz različnih virov – OV5

Varianta A Varianta B Varianta C Ocena 10 8 3

Predznanja v podjetju – OV6

Varianta A Varianta B Varianta C Ocena 1 4 9

5.6.4 Določitev uteži in ovrednotenje pomembnosti vidikov

5.6.4.1 Določitev tipa podjetja

V podjetju Lisca se odvija množica zelo kompleksnih poslovnih procesov, ki so med seboj močno prepleteni. Poleg tega se zaradi sprememb na trgu le-ti nenehno spreminjajo. Lisca črpa svojo konkurenčno prednost tudi iz poslovnih procesov, ki so specifični in so razviti s pomočjo dolgoletnih izkušenj. Seveda je v podjetju tudi nekaj specifičnih procesov, ki bi jih lahko nadomestili z uveljavljenimi standardnimi procesi, vendar bomo v kontekstu specifičnosti v nadaljevanju obravnavali tiste specifične procese, za katere ocenjujemo, da jih ne bi bilo smiselno spreminjati. Poslovne procese Lisce smo v kontekstu posebnosti primerjali z referenčnimi modeli največjih ponudnikov informacijskih rešitev. Tabela XIV prikazuje specifičnosti procesov po področjih (svetla barva predstavlja delež specifičnih procesov, temna pa delež standardnih procesov): Tabela XIV: Specifični procesi 10 20 30 40 50 60 70 80 90 100 ponder skupaj proces trženja 0,2 10 proces razvoja izdelkov 0,2 12 proces nabave materiala 0,15 4,5 proces preskrbe izdelkov 0,15 7,5 proizvodni proces 0,1 4 proces logistike 0,1 5 proces financiranja 0,1 1 SKUPAJ 1 44

64

Iz tabele je razvidno, da spada Lisca po količini specifičnih procesov v skupino S3. Procesi v podjetju so precej kompleksni in precej prepleteni med seboj, tako da lahko podjetje uvrstimo v skupino K2.

5.6.4.2 Uteži glede na specifičnost poslovnih procesov

Glede na skupini S3 in K2 dobimo tabelo uteži: Tabela XV: Tabela uteži

Vidik Utež Normirane uteži TV1 1,20 5,06 TV2 1,20 5,06 TV3 1,10 4,64 TV4 1,00 4,22 TV5 1,40 5,91 VV1 1,00 4,22 VV2 2,00 8,44 VV3 1,10 4,64 VV4 1,10 4,64 VV5 1,20 5,06 VV6 1,20 5,06 SV1 1,00 4,22 SV2 1,30 5,49 SV3 1,00 4,22 OV1 1,20 5,06 OV2 1,00 4,22 OV3 1,20 5,06 OV4 1,20 5,06 OV5 1,10 4,64 OV6 1,20 5,06

SKUPAJ 100

5.6.5.3 Ovrednotenje pomembnosti vidikov

Pomembnost vidikov ovrednotimo po predlagani shemi: 20:40:30:10.

5.6.5 Skupna ocena

V tabeli XVI je prikazana skupna ocena za vsako varianto. Pri seštevku ocen variant so že upoštevane normirane uteži. Tabela XVI: Skupna ocena (tip S3/K2)

65

S3/K2 Varianta

A (z utežmi)

Varianta B (z

utežmi)

Varianta C (z

utežmi) Ponder Korekc.

faktor

Varianta A *

Ponder * Kor.faktor

Varianta B *

Ponder * Kor.faktor

Varianta C *

Ponder * Kor.faktor

Tehnološki vidik

200,42 180,17 207,59 20,00 1,00000 4008,44 3603,38 4151,90

Vsebinski vidik

244,73 218,57 237,97 40,00 0,83333 8157,52 7285,51 7932,49

Stroškovni vidik

75,11 101,69 107,17 30,00 1,66667 3755,27 5084,39 5358,65

Ostali vidiki

225,32 207,59 154,85 10,00 0,83333 1877,64 1729,96 1290,44

SKUPAJ 745,57 708,02 707,59 100,00 17798,87 17703,23 18733,47

Skupna ocena nam kaže, da je glede na tip podjetja S3/K2 in ocene vidikov najbolj primerna varianta C. Iz tabele XVI je razvidno, da sta tehnološka vidika variante A in variante C precej izenačena. Tehnološki vidik variante B malce zaostaja. Pri vsebinskem vidiku je v rahli prednosti varianta A, vendar pa močno zaostaja pri stroškovnem vidiku. Če se malce poigramo z utežmi, vidimo, da bi že pri podjetju tipa S4/K1 pri vsebinskem vidiku varianta C prehitela varianto A. Pri ostalih vidikih je v prednosti varianta A. Analiza seštevka vseh vidikov nam pokaže, da vsebinsko (predvsem s komponentami, ki se nanašajo na standardne procese in preglednostjo) z varianto A ne pridobimo toliko, kot izgubimo stroškovno. Še bolj detajlna analiza nam pokaže, da bi glede na ocene samo pri podjetju, ki ima manj kot 12,5 % specifičnih procesov (tip S1/K1 in S1/K2), kot najboljši izbor dobili varianto A. V tem primeru bi vsebinski vidik (predvsem s komponentami, ki se nanašajo na standardne procese in preglednost) nadoknadil razliko, ki jo dobimo pri stroškovnem vidiku. Primer za S1/K1 je razviden iz tabele XVII: Tabela XVII: Skupna ocena (tip S1/K1)

S1/K1 Varianta

A (z utežmi)

Varianta B (z

utežmi)

Varianta C (z

utežmi) Ponder Korekc.

faktor

Varianta A *

Ponder * Kor.faktor

Varianta B *

Ponder * Kor.faktor

Varianta C *

Ponder * Kor.faktor

Tehnološki vidik

196,39 174,10 195,18 20,00 1,00000 3927,71 3481,93 3903,61

Vsebinski vidik

253,01 210,84 212,05 40,00 0,83333 8433,73 7028,11 7068,27

Stroškovni vidik

81,93 115,66 119,28 30,00 1,66667 4096,39 5783,13 5963,86

66

Ostali vidiki

244,58 221,69 152,41 10,00 0,83333 2038,15 1847,39 1270,08

SKUPAJ 775,90 722,29 678,92 100,00 18495,98 18140,56 18205,82

Tudi v splošnem velja podobno pravilo: Ob normalnih tržnih pogojih je smotrna odločitev za nakup standardne celovite informacijske rešitve, če le-ta pokriva vsaj 80 % informacijskih potreb obravnavanega področja (Kovačič 2002). Izbira uteži je izkustvene narave in je, tako kot ocene, tudi ta podvržena subjektivnosti. Zato izvedemo še izračun osnovne variante z naključno korekcijo uteži +-20 %. Uporabili smo naključnostno funkcijo RAND, ki v omenjenem okviru korigira uteži. Korigirana tabela uteži: Tabela XVIII: Korigirana tabela uteži

Vidik Utež Normirane uteži TV1 1,42 5,90 TV2 1,41 5,86 TV3 1,26 5,23 TV4 1,06 4,40 TV5 1,28 5,32 VV1 1,11 4,61 VV2 2,24 9,30 VV3 0.94 3,90 VV4 1,10 4,57 VV5 1,27 5,27 VV6 1,00 4,15 SV1 0,88 3,65 SV2 1,14 4,73 SV3 0,80 3,32 OV1 1,24 5,15 OV2 0,83 3,45 OV3 1,08 4,49 OV4 1,32 5,48 OV5 1,26 5,23 OV6 1,44 5,98

SKUPAJ 100 Skupna ocena: Tabela XIX: Skupna ocena – korigirane uteži

67

S3/K2 Varianta

A (z utežmi)

Varianta B (z

utežmi)

Varianta C (z

utežmi) Ponder Korekc.

faktor

Varianta A *

Ponder * Kor.faktor

Varianta B *

Ponder * Kor.faktor

Varianta C *

Ponder * Kor.faktor

Tehnološki vidik

213,62 192,19 224,46 20,00 1,00000 4272,43 3843,85 4489,20

Vsebinski vidik

241,74 218,98 234,72 40,00 0,83333 8057,86 7299,28 7823,92

Stroškovni vidik

63,29 85,30 90,70 30,00 1,66667 3164,45 4264,95 4534,88

Ostali vidiki

222,34 209,14 164,66 10,00 0,83333 1852,85 1742,80 1372,16

SKUPAJ 740,99 705,61 714,53 100,00 17347,59 17150,89 18220,17

Iz tabele XIX je razvidno, da se rezultati sicer malenkost spremenijo, vendar vrstni red ocenjenih rešitev ostaja isti, prav tako relativna razlika med njimi. Spreminjanje naključnih vrednosti nam pokaže, da je vpliv spremenjenih uteži na končni rezultat relativno majhen, giblje se v okviru +-5 %. V približno 80 % dobimo enak vrstni red, približno 20 % variant pa je takšnih, da se vrstni red drugega in tretjega mesta zamenjata, prvo mesto pa v vseh primerih ostane enako. Iz tega lahko sklepamo, da obstaja zelo majhna verjetnost, da bi subjektivnost pri izbiri uteži vplivala na izbiro.

5.6.6 SWOT matrika

SWOT matrika za varianto A Tabela XX: SWOT matrika – varianta A S – prednosti - SAP ima največji nabor funkcionalnih

modulov in pokriva več kot 20 različnih industrij. Ima zelo bogate izkušnje;

- SAP razvija kopico dodatkov ERP-u, npr. CRM, kar povečuje dodano vrednost produkta;

- SAP ima največjo razvojno ekipo in največ vlaga v razvoj;

- SAP se razvija v smeri Interneta – mySAP.com.

W – slabosti - SAP ne podpira vseh industrij in

nekateri specializirani ponudniki ponujajo več za nižjo ceno;

- SAP implementacije pogosto presegajo načrtovan proračun zaradi kompleksnosti;

- navadno manjka 20 % funkcionalnosti v njihovih paketih (Hossain et al. 2002);

- pomanjkanje podpore za manjša in srednje velika podjetja.

O – priložnosti - trendi v smeri e-poslovanja; - Internetno orientirana rešitev skozi

implementacijo XML, ASP in Jave.

T – nevarnosti - težko prilagodljiva rešitev, kar je

nevarnost predvsem za srednja in manjša podjetja.

68

SWOT matrika za varianto B Tabela XXI: SWOT matrika – varianta B S – prednosti - rešitev je sestavljena iz manjših,

standardnih, vsebinsko bolj prilagojenih (in bogatejših) programskih paketov;

- fleksibilnost; - vsak programski paket je razvilo drugo

podjetje – večja varnost naložbe (razpršenost) in znanje ter izkušnje vseh teh podjetij.

W – slabosti - težja integracija celotnega sistema; - problematična koordinacija različnih

partnerjev – uvajalcev sistema; - problematično lociranje napak v

delovanju sistema na mejnih področjih (področja, kjer se dotikajo različne programske rešitve).

O – priložnosti - relativno enostavna zamenjava enega

izmed programskih paketov; - enostavno dodajanje / odvzemanje

programskih paketov iz nabora celotnega sistema.

T – nevarnosti - slaba integracija; - slaba preglednost sistema; - nezanesljivi podatki (različni iz različnih

virov).

SWOT matrika za varianto C Tabela XXII: SWOT matrika – varianta C S – prednosti - lastna razvojna ekipa omogoča hiter

odziv in kvalitetno podporo v podjetju; - dobro poznavanje poslovnih procesov s

strani programerske ekipe, ki »diha« s podjetjem.

W – slabosti - nestandardna rešitev; - omejena rešitev; - pogosto je potrebno vložiti ogromno

dela v nove funkcionalnosti, ki so standardnega tipa.

O – priložnosti - skladnost informatike z vizijo podjetja; - »mehak« reinženiring poslovnih

procesov– poslovne procese lahko optimiramo v smislu najboljših praks in jih korigiramo v smeri lastnih posebnosti;

- SOA arhitektura – integracija »legacy« aplikacij z novimi, Java aplikacijami;

- finančni prihranki v primeru uporabe odprto-kodnih platform (Java, Linux).

T – nevarnosti - zaprta rešitev; - zastarela rešitev, če ne sledimo

razvoju; - neučinkovitost programerske ekipe.

69

5.6.7 Končni izbor

Izračun uteženih ocen različnih variant nam sugerira varianto C – razvoj informacijskega sistema po meri. Poudariti pa je potrebno, da je iz izračuna razvidno, da se različne variante med seboj ne razlikujejo veliko in je zato potrebno še posebej natančno proučiti vse prednosti, slabosti, priložnosti in nevarnosti, ki jih prinaša vsaka varianta. Le-te so lepo razvidne iz SWOT matrik. Največja prednost variante A je seveda ogromno znanja, ki ga podjetje pridobi z vpeljavo takšne rešitve. Vendar pa je potrebno upoštevati dejstvo, da je v Sloveniji velika večina podjetij premajhnih za vpeljavo SAP-a, kajti že samo iz finančnega vidika lahko programski paket tako izčrpa podjetje, da ogrozi njegov obstoj. Varianta B ima precej prednosti s stališča fleksibilnosti in bolj finega prilagajanja določenemu področju. Vendar pa pri tej varianti obstaja velika nevarnost netransparentnosti sistema in nekonsistentnih podatkov. Velikokrat se namreč zgodi, da vsako podjetje jamči za svoj sistem in pripadajoč del podatkov, vendar pa lahko ti podatki, gledani iz drugega sistema z drugimi pogoji, izgledajo drugače. Varianta C omogoča pokrivanje zelo specifičnih poslovnih procesov, kar je nedvomno velika prednost podjetja, ki stavi na svoje znanje in svoj način izvajanja poslovnih procesov. Seveda pa je potrebna posebna pazljivost, da se specifični procesi ne izvajajo samo zaradi lepšega, ampak je v ozadju neka konkurenčna prednost. V podjetju Lisca smo pretehtali vse variante, upoštevali končni izračun vseh variant ter pripadajoče SWOT matrike in se odločili, da za naslednje srednjeročno obdobje izberemo varianto C – razvoj informacijskega sistema po meri. V podjetju imamo precej izkušenih programerjev, ki zelo dobro poznajo tudi poslovne procese, in to ocenjujemo kot veliko prednost. Za platformo strojne opreme smo izbrali IBM-ov Mainframe računalnik z9 BC, ki nudi zelo veliko stabilnost ter varnost sistema. Operacijski sistem je IBM z/VM, ki omogoča virtualizacijo, poleg tega pa je zelo varen in stabilen. Podatkovna baza je DB2, razvojno orodje pa WebSphere. Nabor strojne in programske opreme podpira sodobne tehnologije, veliko priložnost vidimo v SOA arhitekturi, ki omogoča zelo dobro integracijo starih (angl. »legacy«) aplikacij in novih aplikacij razvitih v Javi.

70

6 Zaključek

Podjetja se v današnjem času soočajo z velikimi izzivi in eden izmed njih je tudi izbira primernega programskega paketa, s katerim bodo lahko servisirala ter pospeševala svojo dejavnost. Zahteve so velike, prav tako pričakovanja in časi, ko so podjetja vlagala ogromne količine denarja v izboljšave na področju informacijske tehnologije, ki niso prinašale nobene dodane vrednosti, so nedvomno mimo. Prehajamo v zrelo obdobje informacijske tehnologije in tudi investicije v rešitve, ki so povezane z njo in morajo vračati vložek. Zelo jasno moramo torej vedeti, kakšne možnosti obstajajo in kakšne prednosti oz. slabosti prinašajo. V nalogi smo predstavili možnosti pri izbiri tipa informacijskega sistema, predstavili smo dve metodologiji podjetja Gartner, prva se uporablja pri izbiri primernega ponudnika informacijskih rešitev, druga pa pri izbiri primerne alternative razvoja programske opreme. Obe metodologiji sta bili osnova za razvoj prilagojene metodologije, ki je uporabna pri izbiri primernega tipa informacijskega sistema. Dodatno smo predstavili še nekaj metodologij, ki prav tako služijo kot pripomoček za razvoj prilagojene metodologije, predvsem metodologija Bernroiderja in Kocha, ki je osnova za strukturo prilagojene metodologije. Razvito metodologijo smo uporabili na praktičnem primeru podjetja Lisca. Metodologija, predstavljena v nalogi, omogoča sistematski pristop k izbiri primernega programskega paketa. Zastavljena je splošno, njena struktura pa omogoča hitro pot do končne ocene. Končno oceno dobimo iz dveh elementov. Prvi je številčen rezultat izračuna ocen, z njim je zajeta večina faktorjev, ki so številčno določljivi, drugi pa je opisni v obliki SWOT matrik in zajema faktorje, ki jih težko definiramo s številko. Ugotovitve in predlogi za izvedbo projekta izbire primernega tipa informacijskega sistema:

- v podjetjih z večinoma standardnimi poslovnimi procesi je navadno najboljša rešitev standarden celovit informacijski sistem (tabeli XVI in XVII, Kovačič 2002);

- v podjetjih z večinoma specifičnimi poslovnimi procesi je navadno najboljša rešitev razvoj informacijskega sistema po meri ali integracija najboljših rešitev (tabeli XVI in XVII, Kovačič 2002);

- pri izvedbi projekta izbire tipa informacijskega sistema moramo zelo jasno vedeti, kakšne so trenutne zahteve v podjetju in v kateri smeri teče razvoj;

- zelo dobro moramo poznati poslovne procese v širšem smislu, da lahko umestimo specifičnost procesov v podjetju, kjer izvajamo izbiro;

- zelo dobro moramo poznati možne variante izvedbe, tako tehnološko kot vsebinsko in stroškovno;

- zelo pozorni moramo biti na vse direktne in posredne vplive, ki jih prinaša določena varianta, tako v sedanjosti kot v prihodnosti;

- primerjalne številčne vrednosti, ki so rezultat metodologije, moramo obravnavati kot delni rezultat za ustvarjanje globalne slike pozicij variant. Ta rezultat nam ob upoštevanju SWOT matrik omogoča končno odločitev.

71

V nalogi smo želeli pokazati, da je izbira primernega programskega paketa za podjetje zelo zahtevna in kompleksna naloga, kajti trg programske opreme je v zadnjem času precej dozorel, poleg tega pa nam sodobne tehnologije omogočajo nove alternative. S predstavljeno metodologijo smo pokazali način, kako lahko skozi določene kriterije ocenimo, kakšna rešitev je najprimernejša za naše podjetje. Pred leti, ko so bili standardni celoviti informacijski sistemi v največjem vzponu, je bila zelo močno prisotna miselnost, da je najboljša varianta za vsako podjetje vpeljava standardnega celovitega informacijskega sistema. V nalogi je prikazano, da ima podjetje tudi druge možnosti, kajti tehnologija doživlja razcvet v smislu integracije in povezovanja različnih platform. Prav tako so izreden razvoj doživela razvojna orodja, ki omogočajo hiter, dinamičen in kontroliran razvoj programske opreme. Na razpolago imamo torej vsaj tri dokaj enakovredne variante: nakup standardnega celovitega informacijskega sistema, razvoj sistema po meri ali integracijo najboljših rešitev (BoB). Glede na posebnosti poslovanja določenega podjetja lahko s pomočjo predstavljenih metodologij izberemo najprimernejšo rešitev, ki nam omogoča dinamično spremljanje poslovnih procesov in dolgoročno podporo poslovanju in poslovni strategiji v času, ko so spremembe edina stalnica.

72

7 Slovar izrazov

Angleški izraz Slovenski izraz Opis

ERP (Enterprise Resource Planning)

Integrirana informacijska rešitev

Celovit informacijski sistem, ki omogoča planiranje virov in upravljanje z njimi

SCM (Supply Chain Management)

Upravljanje preskrbovalne verige

Upravljanje preskrbovalne verige

CRM (Customer Relationship Management)

Upravljanje odnosov s strankami

Upravljanje odnosov s strankami

SRM (Supplier Relationship Management)

Upravljanje odnosov z dobavitelji

Upravljanje odnosov z dobavitelji

PLM (Product Lifecycle Management)

Upravljanje z življenjskim ciklom produktov

Upravljanje z življenjskim ciklom produktov

Information technology Informacijska tehnologija Tehnologija, ki omogoča zbiranje, obdelavo, shranjevanje, razpošiljanje in uporabo podatkov ter informacij

System development metodology

Metodologija razvoja informacijskih sistemov

Postopen način razvoja informacijskega sistema, ki vključuje uporabo različnih tehnik in orodij, celovit v smislu korakov življenjskega cikla razvoja

Platform Platforma/Računalniško okolje

Izvedba računalnika glede na vgrajeno strojno in sistemsko programsko opremo

Database Podatkovna baza Urejena zbirka medsebojno povezanih podatkov, shranjena na nosilcu podatkov

Application Aplikacija oz. uporabniški program

Računalniški program, ki je namenjen določenemu opravilu, npr. aplikacija za vnos naročil

Legacy application Stare aplikacije iz predhodnega sistema

Podedovane aplikacije, razvite s programskimi jeziki in tehnologijami na platformah, ki smo jih uporabljali pred obstoječo rešitvijo

BoB (Best-of-Breed) Najboljše rešitve Uporaba najboljše specifične programske

73

rešitve za vsako specifično področje ali zahtevo

SaaS (Software as a Service)

Programska oprema kot storitev

Model razvoja programske opreme, kjer so aplikacije dosegljive uporabnikom kot storitve preko Interneta

SWOT matrix (S – Strengths, W – Weaknesses, O – Opportunities, T – Threats)

SWOT matrika Matrika, s katero prikažemo prednosti (S), slabosti (W), priložnosti (O) in nevarnosti (T)

SOA (Service-oriented Arhitecture)

Storitveno orientirana arhitektura

Arhitektura, ki omogoča povezovanje različnih komponent – storitev iz različnih platform

XML (Extensible Markup Language)

XML XML je metoda zapisa strukturiranih podatkov, ki v svoji strukturi nosi tudi opis te strukture. XML je podmnožica standarda SGML

WDSL (Web Services Description Language)

Jezik za opis spletnih storitev

WDSL je jezik, ki bazira na XML in se uporablja za opis spletnih storitev

SOAP (Simple Object Access Protocol)

Enostavni protokol za dostop do objektov

SOAP je protokol za izmenjavo podatkov v obliki XML z uporabo protokola HTTP/HTTPS ali SMTP

UDDI (Universal Description, Discovery and Integration)

Univerzalni opis, iskanje (raziskovanje) in integracija

Register, temelječ na XML, ki omogoča objavljanje opisov storitev (WDSL) ter njihovo iskanje

CORBA (Common Object Request Broker Architecture)

CORBA CORBA je standard, ki ga je definirala OMG (Object Management Group) in omogoča programskim komponentam različnih programskih jezikov in platform skupno delovanje in interakcijo

ESB (Enterprise Service Bus)

Storitveno vodilo Odprt standard za prenos sporočil, ki omogoča povezljivost večjih aplikacij in komponent preko standardnih vmesnikov

JMS (Java Message Service)

JMS JMS je sporočilni standard, ki omogoča Java in Java EE komponentam kreiranje,

74

pošiljanje, sprejemanje in branje sporočil

MQ (Message Queuing) Sporočilne vrste Sporočilni sistem, ki omogoča asinhron prenos sporočil

EJB (Enterprise Java Beans)

Strežniška Java zrna Java zrna, ki omogočajo interakcijo in integracijo v velikih, distribuiranih sistemih in Internetu

Java EE (Java Enterprise Edition)

Platforma Java, edicija za velike, distribuirane sisteme

Platforma Java, edicija za velike, distribuirane sisteme

75

8 Literatura in viri

8.1 Literatura

1. Beck K.: Extreme Programming Explained: Embrace Change, Upper Saddle River, Addison-Wesley, 2000.

2. Bernroider E. W. N., Koch S.: A framework for the selection of ERP packages for small to medium and large organizations. V: Hossain L., Patrick J. D., Rashid M. A.: Enterprise Resource Planning: Global Opportunities and Challenges, Idea Group Publishing, Hershey, US, 2002.

3. Chen I. J.: Planning for ERP systems: Analysis and future trend, Business Process Management Journal, 7(5), 2001.

4. Chung S. H., Snyder C. A.: ERP adoption: a technological evolution approach. International Journal of Agile Management Systems Vol. 2, No. 1: 24-32, 2000.

5. Croxton Keely L., Garcia-Dastugue Sebastian J., Lambert Douglas M., Rogers Dale S.: The Supply Chain Management Processes, The International Journal of Logistics Management, Vol.12, No.2, 2001.

6. Davenport T.H., Putting the enterprise into the enterprise system, Harvard Business Review, 1998.

7. Esteves J., Pastor J.: Enterprise Resource Planning Systems Research: An Annotated Bibliography, Communications of the Association of Information Systems, 7(8), 2001.

8. Eyholzer K., Kuhlmann W., Münger T.: Wirtschaftlichkeitsaspekte eines partnerschaftlichen Lieferantenmanagements, HMD - Praxis der Wirtschafts-informatik, 39(228), 2002.

9. Hossain Liaquat, Patrick Jon David, Rashid M.A.: Enterprise Resource Planning: Global Opportunities and Challenges, Idea Group Publishing, Hershey, US, 2002.

10. Johnson Brian, Skibo Craig, Young Marc: Inside MS Visual Studo .NET, Microsoft Press, 2003.

11. Jutras Cindy: Best Practices in Extending ERP, Aberdeen Group, Inc. Boston, Massachusetts, 2006.

12. Kovačič Andrej et al.: Prenova in informatizacija poslovanja, Ekonomska fakulteta, Ljubljana, 2002.

13. Kumar V., Maheshwari B., Kumar U.: Enterprise resource planning systems adoption process: a survey of Canadian organizations, International Journal of Production Research Vol. 40, 2002.

14. Kyte Andy: Use FACT Analysis to Evaluate Software Deployment Options, Gartner, 2007.

15. Lambert Douglas M., Cooper Martha C., Pagh Janus D.: Supply Chain Management: Implementation Issues and Research Opportunities, The International Journal of Logistics Management, Vol.9, No.2, 1998.

16. Lebinski Jim: Vendor Selection and Evaluation: An ERP Framework, Gartner, 2001.

17. Light B., Holland P. C., Wills K.: ERP and best of breed: a comparative analysis. Business Process Management Journal Vol. 7, 2001.

76

18. Ljubič Tone: MRP / CRP, MRP II, ERP … in kaj potem?. 20. znanstveno posvetovanje o razvoju organizacijskih ved: Management in globalizacija, 1. knjiga. Moderna organizacija, Kranj, 2001.

19. Mullin Rick: ECM: Where ERP Meets the Web, Chemical Week Vol. 163, Issue 17:31, 2001.

20. Nah Fui-Hoon F., Lau Lee-Shang J.: Critical factors for successful implementation of enterprise systems, Business Process Management Journal 7, 2001.

21. Nelson S.: A Build Mentality Is Re-emerging in Business Applications, Gartner Groups, Strategic Planning, SPA-20-7537, Research Note, 2003.

22. Nilsson Dale R., Mauget Louis E.: Building J2EE Applications with IBM Websphere, Wiley Publishing, Inc., 2003.

23. Oh A: The Integrated Enterprise Resource Management Software Application Market in Slovenia, 1999-2004, IDC, 2000.

24. Olhager J., Selldin E.: Enterprise resource planning survey of Swedish manufacturing firms, European Journal of Operational Research 146, 2003.

25. O'Leary D. E.: Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk, Cambridge University Press, New York, 2002.

26. Roberts-Witt Sarah L.: It’s the Customer, Stupid! PC Magazine, June 27, 2000.

27. Rosenthal SR, Salzman H: Hard choices about software: the pitfalls of procurement, Sloan Management Review, 1990.

28. Sammon D., Adam F.: Chapter 4: ERP Software Selection- Widening the Current Debate. V: Adam F., Sammon D., The Enterprise Resource Planning Decade: Lessons Learned and Issues for the Future, Idea Group Publishing, Hershey, US, 2004.

29. Spies Ruediger: Midmarket Enterprise Resource Planning – Europe, Connecticut: Meta Group, METAspectrum 30.4., 2003.

30. Somers T. M., Nelson K. G.: The impact of strategy and integration mechanisms on enterprise system value: Empirical evidence from manufacturing firms, European Journal of Operational Research 146, 2003.

31. The Standish Group International, Inc., CHAOS Chronicles, 2001. 32. Themistocleous M., Irani Z., OKeffe R. M., Paul R.: ERP Problems and

Application Integration Issues: An Empirical Survey, Proceedings of the 34th Hawaii International Conference on System Sciences – 2001, 2001.

33. Wei C. C., Wang M.-J. J.: A comprehensive framework for selecting an ERP system. International Journal of Project Management, Volume 22. pp 161-169, 2004.

34. Whittaker B.: What went wrong? Unsuccessful information technology Projects, Information Management and Computer Security Vol. 7, No. 1: 23-29, 1999.

8.2 Viri

1. Aberdeen Group: Best practices in Extending ERP, 2006, URL: http://files.cecollect.com/607/5291/Aberdeen%20ERP%20Report.pdf.

2. AMR Research: ERP vendors ranked by 2004 ERP revenue, 2005, URL: http://amrresearch.com/Content/View.asp?pmillid=18386.

77

3. AMR Research: SCM Market report, 2005A, URL: http://www.amrresearch.com/Content/View.asp?pmillid=18452.

4. APICS, American Production and Inventory Control Society, 2001, URL: http://www.apics.org.

5. Campelo F. Eulálio G., Stucky Wolffried: The Supplier Relationship Management Market Trends, 2007, URL: http://www.waset.org/pwaset/v22/v22-20.pdf.

6. Driver Mark: J2EE and .NET Will Vie for EBusiness Development Efforts, Gartner, 2003, URL: http://www.gartner.com/DisplayDocument?doc_cd=114609.

7. Estes Byron Taylor, Maxime Oriel: J2EE vs. .NET: The choice depends on your needs, Computerworld, 2003, URL: http://www.computerworld.com/developmenttopics/development/story/0,10801,84155,00.html.

8. Gray P., Byun J.: Customer Relationship Management, University of California, Irvine, 2001, URL: http://www.crito.uci.edu/publications/pdf/crm.pdf.

9. Hoppermann Jost: European Financial Services: J2EE Is Rising, 2005, URL: http://www.forrester.com/Research/Document/0,7211,35168,00.html.

10. IBM: SOA Framework, 2007, URL: http://www.ibm.com/developerworks/web/library/wa-soaesb/.

11. Kumar P.: Choosing the right ERP Solution, ZDNet, 2004, URL: http://www.zdnetasia.com/smb/specialreports/0,39045280,39169389-1,00.htm.

12. Ledeen Kenneth S.: Make v. Buy: A Decision Paradigm, 2004, URL: http://www.nevo.com/our-knowledge/whitepapers/BuildVsBuy.pdf.

13. Microsoft Dynamcis NAV Product Overview, 2008, URL: http://www.microsoft.com/dynamics/nav/product/overview.mspx.

14. Microsoft Studio .NET, 2007, URL: http://msdn2.microsoft.com/en-us/library/fx6bk1f4(vs.71).aspx.

15. Murthi Sanjay: Build Versus Buy - Making the Right Decision, 2002, URL: http://www.developer.com/mgmt/article.php/1488331.

16. Oracle, 2008, URL: http://www.oracle.com. 17. Oracle: Defying Conventional Wisdom, 2007, URL:

http://www.oracle.com/oramag/profit/07-may/p27anniv_timeline.pdf 18. SAP NetWeaver, 2007, URL:

http://help.sap.com/saphelp_nw04/helpdata/en/30/c4461ff69d5a438f1286e344b545fa/frameset.htm.

19. SAP, 2007, URL: http://www.sap.com/index.epx. 20. Stefanou CJ: A framework for the ex-ante evaluation of ERP software, 2001,

URL: http://web.njit.edu/~jerry/OM/OM-ERP-Papers/ERP-framework.pdf. 21. Sweeney Group: What is CRM?, 2000, URL:

http://www.sweeneygroup.com/crm.htm. 22. Teradata Center for CRM at Duke University, Cell2Cell: The Churn Game,

2002, URL: http://www.fuqua.duke.edu/centers/ccrm/datasets/cell/Cell2Cell_Case.pdf.

23. The Linthicum Group: SOA Meta Model, 2007, URL: weblog.infoworld.com/realworldsoa/archives/Full%20Contact%20SOA.ppt.

24. The Standish Group, 2007, URL: http://www.standishgroup.com. 25. Wahli Ueli, Cui Henry, Fleming Craig, Mehta Maan, Rohr Marco, Ugurlu Pinar,

Gan Patrick, Gonzalez Celso, Farrell Daniel M., Heerdegen Andreas: Rational

78

Application Developer V7 Programming Guide, IBM RedBooks, 2007: URL: http://www.redbooks.ibm.com/redbooks/pdfs/sg247501.pdf.

26. Wikipedia, 2007, URL: http://en.wikipedia.org/wiki. 27. Wilkoff Nicholas: The State Of Technology Adoption, Forrester Research,

2004, URL: http://www.forrester.com/Research/Document/Excerpt/0,7211,34266,00.html.

28. Yee Andre: Making J2EE and .NET Work and Play Well Together in SOAs, 2004, URL: http://www.ebizq.net/topics/soa/features/3594.html?page=1.