132
UNIVERZA V MARIBORU EKONOMSKO-POSLOVNA FAKULTETA MARIBOR MAGISTRSKO DELO ANALIZA KRITIýNIH DEJAVNIKOV USPEHA UVAJANJA SAP V MEDNARODNEM TRGOVINSKEM PODJETJU ANALYSIS CRITICAL SUCCESS FACTORS IMPLEMENTING SAP INTO AN INTERNATIONAL TRADING COMPANY Kandidat: Sebastjan Mavriþ Študent rednega študija Študijski program 2. stopnje »Ekonomske in poslovne vede« Študijska usmeritev: Management informatike in elektronskega poslovanja Mentor: dr. Samo Bobek Maribor, april 2012

MAGISTRSKO DELO ANALIZA KRITIý NIH DEJAVNIKOV USPEHA ... · konkurenþnih prednosti. Prilagajanje poslovnih modelov, organizacijskih struktur in prevzemanje tehnoloških rešitev

  • Upload
    others

  • View
    7

  • Download
    0

Embed Size (px)

Citation preview

  • UNIVERZA V MARIBORU

    EKONOMSKO-POSLOVNA FAKULTETA MARIBOR

    MAGISTRSKO DELO

    ANALIZA KRITI NIH DEJAVNIKOV USPEHAUVAJANJA SAP V MEDNARODNEM

    TRGOVINSKEM PODJETJU

    ANALYSIS CRITICAL SUCCESS FACTORSIMPLEMENTING SAP INTO AN INTERNATIONAL

    TRADING COMPANY

    Kandidat: Sebastjan Mavri

    Študent rednega študija

    Študijski program 2. stopnje »Ekonomske in poslovne vede«

    Študijska usmeritev: Management informatike in elektronskega poslovanja

    Mentor: dr. Samo Bobek

    Maribor, april 2012

  • Zahvala

    Za strokovno pomo in predloge se zahvaljujem mentorju dr. Samu Bobku in višjipredavateljici dr. Simoni Sternad, za strokovno pomo pri analizi raziskave pa DanijeluNavodniku.

  • 1

    KAZALO VSEBINE

    1 UVOD ........................................................................................................................61.1 Opredelitev podro ja in opis problema .................................................................61.2 Namen in cilji raziskave; raziskovalne hipoteze ...................................................71.3 Predvidene metode raziskave in na rt raziskave ...................................................81.4 Predpostavke in omejitve raziskave ......................................................................9

    2 CELOVITE INFORMACIJSKE REŠITVE .............................................................. 102.1 Opredelitev celovitih informacijskih rešitev ....................................................... 102.2 Razvoj celovitih informacijskih rešitev .............................................................. 112.3 Uvajanje celovitih informacijskih rešitev ........................................................... 12

    2.3.1 Izbira ter nakup celovitih informacijskih rešitev .......................................... 122.3.2 Uvajanje ERP rešitev v organizacijo ........................................................... 162.3.3 Pristopi k uvajanju celovitih informacijskih rešitev ..................................... 20

    2.3.3.1 Big - bang pristop ................................................................................ 202.3.3.2 Vzporedni pristop ................................................................................ 202.3.3.3 Fazni pristop ........................................................................................ 212.3.3.4 Procesni pristop ................................................................................... 212.3.3.5 Hibridni pristop ................................................................................... 21

    2.4 Življenjski cikel celovitih informacijskih rešitev ................................................ 222.5 Mejniki uvajanja ................................................................................................ 26

    2.5.1 CPM ........................................................................................................... 262.5.2 Ganttov diagram ......................................................................................... 27

    2.6 Dejavniki uspešnih in neuspešnih uvedb celovitih informacijskih rešitev ........... 272.7 Ekonomika celovitih informacijskih rešitev ....................................................... 30

    3 CELOVITA INFORMACIJSKA REŠITEV SAP ..................................................... 333.1 Predstavitev informacijskega sistema in zna ilnosti ........................................... 333.2 Arhitektura R/3 sistema ..................................................................................... 333.3 Modularnost....................................................................................................... 353.4 Uvajanje celovite informacijske rešitve SAP ...................................................... 36

    3.4.1 Projektni tim uvedbe SAP ........................................................................... 383.5 Metodologija ASAP ........................................................................................... 42

    3.5.1 1. faza: Priprava projekta ............................................................................ 443.5.2 2. faza: Poslovni na rt ................................................................................. 453.5.3 3. faza: Realizacija ...................................................................................... 453.5.4 4. faza: Kon ne priprave ............................................................................. 47

  • 2

    3.5.5 5. faza: Preklop v živo in podpora ............................................................... 484 KRITI NI DEJAVNIKI USPEHA UVAJANJA ERP REŠITEV .............................. 49

    4.1.1 Jasni cilji, strategija in obseg uvajanja rešitve ............................................. 514.1.2 Vklju itev in podpora uprave ...................................................................... 524.1.3 Organizacija projektnega tima in njegove kompetence ................................ 534.1.4 Vklju itev in sodelovanje uporabnikov ....................................................... 534.1.5 Komunikacija med projektnim timom in ostalimi v podjetju ....................... 544.1.6 Izobraževanje kon nih uporabnikov ............................................................ 544.1.7 Prenova poslovnih procesov ........................................................................ 554.1.8 Vklju evanje zunanjih izvajalcev ................................................................ 564.1.9 Aktivna vloga sponzorja projekta ................................................................ 574.1.10 Menedžment sprememb .............................................................................. 574.1.11 Uporaba principov projektnega menedžmenta ............................................. 584.1.12 Zagotavljanje kakovosti .............................................................................. 58

    5 ANALIZA KRITI NIH DEJAVNIKOV USPEHA UVAJANJA SAP VMEDNARODNEM TRGOVSKEM PODJETJU.............................................................. 60

    5.1 Raziskovalni model kriti nih dejavnikov uspeha ................................................ 605.1.1 Potek raziskave ........................................................................................... 615.1.2 Priprava anketnega vprašalnika in intervjuja ............................................... 615.1.3 Pridobivanje podatkov in vzorec raziskave .................................................. 635.1.4 Obdelava podatkov ..................................................................................... 63

    5.2 Analiza rezultatov raziskave .............................................................................. 635.2.1 Splošni del raziskave .................................................................................. 63

    5.3 Analiza kriti nih dejavnikov uspeha uvedbe SAP............................................... 695.3.1 Cilji in hipoteze raziskave ........................................................................... 705.3.2 Opisna statistika .......................................................................................... 705.3.3 Analiza kriti nih dejavnikov uspeha glede na rang ...................................... 755.3.4 Analiza kriti nih dejavnikov uspeha pred in po uvedbi................................ 79

    5.3.4.1 Diferen na analiza KDU pred/po uvedbi SAP ...................................... 795.3.4.2 Povezanost in odvisnost KDU pred in po uvedbi SAP .......................... 80

    5.3.4.2.1 Analiza odvisnosti KDU uprava pred uvedbo SAP ...................................... 82

    5.3.4.2.2 Analiza odvisnosti KDU direktor divizije pred uvedbo ................................ 84

    5.3.4.2.3 Analiza odvisnosti KDU vodja službe pred uvedbo..................................... 85

    5.3.4.2.4 Analiza odvisnosti KDU uprava po uvedbi ................................................. 85

    5.3.4.2.5 Analiza odvisnosti KDU direktor divizije po uvedbi .................................... 86

  • 3

    5.3.4.2.6 Analiza odvisnosti KDU vodja službe po uvedbi ......................................... 86

    5.3.5 Primerjava empiri ne raziskave s teoreti no ................................................ 875.3.6 Kriti ne ugotovitve raziskave ...................................................................... 89

    6 SKLEP ..................................................................................................................... 91LITERATURA ................................................................................................................ 92KAZALO TABEL .............................................................................................................1KAZALO GRAFIKONOV ................................................................................................2KAZALO SLIK .................................................................................................................2KAZALO FORMUL..........................................................................................................2KAZALO ENA B.............................................................................................................2PRILOGA 1 .......................................................................................................................3PRILOGA 2 .......................................................................................................................4PRILOGA 3 ..................................................................................................................... 11PRILOGA 4 ..................................................................................................................... 15PRILOGA 5 ..................................................................................................................... 20PRILOGA 6 ..................................................................................................................... 26PRILOGA 7 ..................................................................................................................... 30DELOVNI ŽIVLJENJEPIS ............................................................................................. 34

  • 4

    POVZETEK

    Danes se organizacije soo ajo z vedno bolj nepredvidljivimi tržnimi pogoji, vse ve jokonkurenco ter z vedno zahtevnejšimi kon nimi odjemalci. Prisiljeni so spremenititradicionalne poslovne prakse, zniževati stroške poslovanja, saj jim le to omogo a krepitevkonkuren nih prednosti. Prilagajanje poslovnih modelov, organizacijskih struktur inprevzemanje tehnoloških rešitev je le nekaj vidikov kljubovanja trenutnim poslovnimtrendom. Celovite informacijske rešitve predstavljajo tehnološko platformo doseganja tehciljev. Organizacije se odlo ajo za uvedbo celovitih informacijskih rešitev iznajrazli nejših razlogov. Želijo prenoviti obstoje e informacijske sisteme, poenostavitiposlovanje, prilagoditi oziroma integrirati poslovne procese, standardizirati informacije inpodatke, ali pa se le želijo prilagoditi svetovnim trendom. Uspešnost uvedbe celovitihinformacijskih rešitev je pogojena in odvisna od mnogih dejavnikov. Organizacije najprejdolo ijo vzroke in potrebe po prenovi informacijskega sistema. Opredelijo jasne cilje,vizijo in strategijo, ki jo bodo zasledovali pri projektu uvedbe. Velik odstotek neuspešnihuvedb pripisujemo predvsem nejasnim, slabo za rtanim, nedodelanim, slabo zastavljenimprojektnim izhodiš em. Definiranje jasnega obsega, asa uvedbe ter pripadajo ih virovprojekta pogojuje dejavnike uspešnih in neuspešnih uvedb informacijskih projektov. Danesponudniki rešitev ponujajo metodologije uvajanja, ki so zasnovane na principu najboljšihpraks. Metodologija definira jasne omejitve uvajanja, razdeli sistem uvajanja na logi nezaporedne aktivnosti ter dolo a odgovornosti, kar posledi no vpliva na zagotavljanjekakovosti projekta. Življenjski cikli celovitih informacijskih rešitev so razdeljeni nalogi ne dejavnosti oziroma faze. Vsaki fazi pripadajo dejavniki, ki pomembno vplivajo nauspešen zaklju ek posamezne faze in življenjskega cikla uvedbe.

    V magistrskem delu želimo prikazati, kateri so tisti kriti ni dejavniki uspeha uvajanjacelovitih informacijskih rešitev, ki pomembno vplivajo na u inkovito uvedbo. Opravilibomo analizo kriti nih dejavnikov uspeha uvajanja celovite informacijske rešitve SAP.Dejavnike bomo analizirali iz dveh vidikov; pred in po uvedbi SAP z vidika treh razli nihravni menedžmenta ter na primeru celotne organizacije.

    Klju ne besede

    Celovite informacijske rešitve, rešitve ERP, informacijski sistem, kriti ni dejavniki uspehauvajanja celovitih informacijskih rešitev, celovita informacijska rešitev SAP.

  • 5

    ABSTRACT

    Today, organizations are faced with an increasingly unpredictable market conditions,increased competition and increasingly demanding end customers. They feel compelled tochange their traditional business practices, reduce operational costs because only thisallows them to enhance competitive advantage. Adapting business models, organizationalstructures and take on the technological solutions are only a few aspects of the currentbusiness trend of defiance. Comprehensive IT solutions represent the technology platformto achieve these goals. Determining reasons for organizations when deciding to implementa comprehensive IT solutions are numerous. Either they want to renew the existinginformation systems, simplify operations, adjust business processes, integrate businessprocesses, standardize information and data or they just want to adapt to world trends. Asuccessful implementation of integrated ERP solutions depends on many factors.Organizations have to determine the causes and the need for modernization of thecorporate system. Define clear objectives, vision and strategy which will be pursued in theproject introduction. Unsuccessful ERP implementations are mainly caused by copied,notably vague, poorly outlined, incomplete, poor project objectives. Defining a clear scope,time and associated resources at the beginning of the project, determines the differencebetween a successful and unsuccessful ERP implementation. Nowadays, solution providersoffer structured methodologies for ERP implementation projects, that are based on theprinciple of best practices. An ERP methodology defines clear limitation introduction todistributed system logical sequence of activities and sets out the responsibilities which inturn affects the quality of the project. ERP life cycles are divided into logical phases andactivities. Belonging to each stage of the factors that significantly affect the successfulcompletionof each phase and the introduction of life-cycle.

    In the master's work, we conducted an analysis of what are and which kind of criticalsuccess significantly affect an ERP implementation. Analysis was based on critical successfactors of implementing an enterprise resource planning solution SAP. Factors wereanalyzed from two aspects, before and after the implementation of SAP in terms of threedifferent management levels and from the aspect of an entire organization.

  • 6

    1 UVOD

    1.1 Opredelitev podro ja in opis problema

    Danes se številna podjetja sprašujejo, ali je smiselno obdržati tradicionalne organizacijskeoblike in s tem v svojih okvirih ohraniti razvojne, tehnološke, proizvodne inadministrativne procese s pripadajo imi viri. Informacijske rešitve postajajo eno izmedglavnih orodij organizacij in menedžmenta pri izvajanju procesnih sprememb inzagotavljanju tržne uspešnosti. Stalne tehnološke spremembe omogo ajo izboljševanjeposlovnih procesov, delovnih sredstev, metod dela ter posledi no znižanje stroškovposlovanja. Celota teh dejavnikov vpliva na donosnost poslovnih odlo itev, ki se kaže vkakovostnih izdelkih in storitvah, zagotavljanju prihrankov ter zadovoljevanju potreb vsehudeležencev poslovnega sistema. Našteto zahteva nenehno prilaganje novonastalimposlovnim zahtevam z vidika poslovnih procesov kot prilagajanja informacijsketehnologije.

    Organizacije se za aktualne poslovne potrebe odlo ajo za prenovo informacijskih sistemovoziroma za uvedbo celovitih informacijskih rešitev (angl. Enterprise Resource Planning -ERP; v nadaljevanju rešitve ERP), ki podpirajo celoten ali ve ji del poslovnega procesa.Razlogi za tovrstne odlo itve izvirajo iz nezadostne integracije obstoje egainformacijskega sistema, zastarelosti ali nezmožnosti zadoš anja edalje ve jim poslovnimzahtevam. Uvedba celovite informacijske rešitve organizaciji omogo a vzpostavitevtehnološko dovršenega integriranega poslovno informacijskega sistema. Le-ta predstavljaosnovo za prenovo in poenotenje poslovnih procesov, centralizirano upravljanje,nadziranje in vzdrževanje informacijskega sistema. Omogo a integracijo s preostalimiinformacijskimi rešitvami, izboljšuje pretok poslovne dokumentacije, popolno sledljivostpodatkov ter izdelavo lastnih dograditev informacijskega sistema. Predstavlja osnovni virzniževanja stroškov in osnovo za uvedbo CRM, BI ter osnovo za spremljanjeuravnoteženih kazalnikov uspeha.

    Uvedba celovitih informacijskih rešitev v poslovno okolje je kompleksen in sistemati enproces. Uvedbo spremlja kopica dejavnikov, ki odlo ilno vplivajo na uspešno realizacijozastavljenega informacijskega projekta. Kriti ni dejavniki uspeha (v nadaljevanju KDU)uvajanja informacijskih rešitev so torej tisti dejavniki, ki odlo ilno vplivajo na uspešnostprojekta ter uresni itev zastavljenih poslovnih in informacijskih ciljev.

    V literaturi je navedeno mnogo kriti nih dejavnikov uspeha, ki bodo predstavljali izhodiš eraziskave magistrskega dela. Pripisovanje pomembnosti posameznih KDU uvajanja SAP nimogo e objektivno predstaviti brez celovite analize v okviru življenjskega cikla ERPrešitve. KDU pogosto povezujemo z uspehom oziroma neuspehom uvedbe celoviteinformacijske rešitve. Predstavili bomo pomembnost kriti nih dejavnikov v okviruinformacijskega projekta ter povezana problemska stanja. Skušali bomo prikazatisoodvisnost posameznih KDU ter predstaviti rezultate analize uvajanja celoviteinformacijske rešitve SAP z vidika treh razli nih ravni menedžmenta v mednarodnemtrgovskem podjetju.

  • 7

    1.2 Namen in cilji raziskave; raziskovalne hipoteze

    V magistrskem delu želimo raziskati podro je uvajanja celovitih informacijskih rešitev teranalizirati pomembnost kriti nih dejavnikov uspeha, ki vplivajo na uspešno realizacijozastavljenega projekta. V prvem delu naloge izhajamo iz teoreti nih izhodiš celovitihinformacijskih rešitev, ki so pomembna za nadaljnjo razumevanje obravnavane tematike.Kronološko bomo prikazali razvoj celovitih informacijskih rešitev ter podali teoreti naizhodiš a, ki se navezujejo na izbiro in nakup informacijskih rešitev. Nato bomo opredelilipristope uvajanja ter pripadajo e metodologije uvajanja ERP rešitev.

    V drugem delu magistrskega dela bomo predstavili celovito informacijsko rešitev SAP.Raz lenili bomo na in uvajanja ERP rešitev v organizacijo ter predstavili procesnousmerjeno strategijo uvajanja s poudarkom na ASAP metodologiji.

    Uvedba ERP rešitev je kompleksen in interdisciplinaren projekt, ki zahteva procesni instrateški pristop z upoštevanjem pogojev uvajanja, ki omogo ajo uspešno in u inkovitouvedbo rešitve. Tako bomo v empiri nemu delu magistrske naloge opredelili kriti nedejavnike uspeha uvajanja SAP rešitve. S teoreti nimi izhodiš i KDU bomo prikazaliodvisnost oziroma neodvisnost posameznih KDU v procesu uvedbe rešitve SAP. Izdelalibomo raziskovalni model, na podlagi katerega bomo opravili analizo KDU uvajanja SAP zvidika treh razli nih ravni menedžmenta, in sicer:

    Upravljavske ravni oziroma uprave družbe (angl. Top Management, vnadaljevanju: uprava družbe);Organizacijske ravni, ki jo predstavljajo direktorji divizij (angl. MidlleManagement, v nadaljevanju: direktorji divizij);Organizacijske ravni, ki jo predstavljajo vodje služb in klju ni uporabniki (angl.First Line Management, v nadaljevanju: klju ni uporabniki).

    Cilji teoreti nega dela magistrske naloge:

    Preveriti teoreti na izhodiš a celovitih informacijskih rešitev.Analizirati in primerjati pristope uvajanja ERP rešitev.Preveriti vlogo in pomen strateškega menedžmenta ERP rešitev.Analizirati metodologijo uvajanja rešitve SAP.

    Cilji empiri nega dela magistrske naloge:

    Preveriti teoreti na izhodiš a KDU.Prikazati soodvisnost KDU uvajanja SAP.Prikazati strateški pomen KDU uvajanja SAP.Pripraviti analizo KDU uvajanja SAP z vidika treh razli nih ravni menedžmenta vdružbi.

  • 8

    Hipoteze, ki jih bomo v magistrskem delu preverjali:

    H1: Obstaja odvisnost med posameznimi KDU med tremi ravnmi menedžmenta (upravadružbe, direktorji divizij, klju ni uporabniki) pred in po uvedbi SAP.

    H2: Obstajajo zna ilne razlike rangiranja pomembnosti KDU uvajanja pred in po uvedbiSAP med tremi razli nimi ravnmi menedžmenta (uprava družbe, direktorji divizij, klju niuporabniki) ter z vidika celotne organizacije.

    H3: V primeru obstoja razlik iz H2, le-te negativno vplivajo na uvedbo rešitve SAP vpredvidnem obsegu in asu ter s predvidenimi viri.

    H4: V primeru obstoja razlik iz H2, le-te pozitivno vplivajo na uvedbo rešitve SAP vpredvidnem obsegu in asu ter s predvidenimi viri.

    1.3 Predvidene metode raziskave in na rt raziskave

    Pri raziskovanju za potrebe magistrskega dela se bomo osredoto ili na pristopdeskriptivnega in analiti nega raziskovanja. Pri tem bomo pretežno uporabljali tujestrokovne vire ter literaturo, lanke v strokovnih podatkovnih zbirkah in seveda internogradivo ter spoznanja v mednarodnem trgovskem podjetju. S pomo jo raziskovalnih metodbomo pretehtali dognana teoreti na spoznanja, ki jih bomo pozneje, s pomo jo analiti neraziskave ter lastne raziskave, v praksi primerjali.

    V teoreti nem delu magistrskega dela gre za poslovno ekonomsko raziskavo, saj taobravnava posamezne funkcije podjetja, v empiri nem delu pa obravnavamomikroekonomsko raziskavo, kjer se bomo ukvarjali s prou evanjem temeljnih ekonomskihsubjektov. Raziskava je stati ne narave, saj ugotavlja odvisnost med ekonomskimi pojavi vdolo enem trenutku.

    Deskriptivni pristop bomo uporabili v teoreti nem delu raziskave.

    M1 - uporabili bomo metodo kompilacije, kjer bomo povzemali stališ a in sklepe razli nihavtorjev s podro ja celovitih informacijskih rešitev (njihovega razvoja, odlo itev o izbiri,nakupa, uvedbah). S pomo jo te metode bomo v nadaljevanju prišli do lastnih sklepov,stališ ter spoznanj s podro ja kriti nih dejavnikov uspeha uvajanja ERP rešitev.

    M2 - metoda deskripcije, kjer bomo lai no opisovali vpliv ERP rešitev na izboljševanjeposlovnih procesov, vplivanje na donosnost, integriranost s preostalimi informacijskisistemi, centraliziranost upravljanja, nadziranja ter vzdrževanja informacijskih sistemov.

    M3 - komparativna metoda, kjer bomo primerjali razli ne pristope in metode uvajanja EPRrešitev.

    Analiti ni pristop bomo uporabili v empiri nemu delu raziskave. Potekal bo v treh fazah,in sicer v prvi s pomo jo deduktivnega sklepanja, v drugi fazi s pomo jo induktivnegasklepanja ter v tretji s ponovnim deduktivnim sklepanjem. V ta namen bomo pripravili

  • 9

    anketni vprašalnik, izvedli anketo ter v analizi primerno komentirali rezultate. Z analizoKDU uvajanja SAP med tremi razli nimi ravnmi menedžmenta (uprava družbe, direktorjidivizij, klju ni uporabniki) bomo kvalitativno in kvantitativno interpretirali dobljenerezultate, kar nas bo privedlo v oblikovanje novih trditev in hipotez, ki izhajajo iz prejšnjihtrditev, hipotez ali teorij.

    Potek izvedbe raziskave bo potekal v naslednjih fazah:

    1. Opredelitev raziskovalnega problema.2. Iskanje znanstvenih lankov in strokovne literature.3. Pisanje teoreti nega dela.4. Pisanje empiri nega dela.5. Zbiranje podatkov preko primarnih virov.

    S pomo jo vprašalnika (odprta in zaprta vprašanja).

    6. Zbiranje podatkov preko sekundarnih virov.

    S pomo jo predhodnih raziskav.

    7. Obdelava rezultatov (Microsoft Office Excel, SPSS) in preverjanje hipotez.8. Priprava raziskovalnega poro ila.

    1.4 Predpostavke in omejitve raziskave

    Predpostavke:

    V prvem delu magistrske naloge bomo preverjali teoreti na izhodiš a ERP rešitev.Raziskava je opredeljena na to no dolo eno ERP, torej rešitev SAP.Predpostavljamo, da KDU vplivajo na u inkovitost in uspešnost uvedbe SAP.Predpostavljamo, da želi organizacija uvesti SAP v predvidenem obsegu in asu ters predvidenimi viri.Rezultate analize KDU bomo preverjali v okviru organizacije, ki je predmetobravnave.

    Omejitve:

    Splošno omejitev raziskave predstavlja dejstvo, da so podatki, ki bi lahko boljepojasnili dolo ena dejstva, poslovna skrivnost organizacije.Raziskava ne bo temeljila na prikazu prakti ne uvedbe rešitve SAP v organizacijo.V raziskavi ne bomo izvajali analize vpliva KDU med posameznimi moduli SAP.

  • 10

    2 CELOVITE INFORMACIJSKE REŠITVE

    2.1 Opredelitev celovitih informacijskih rešitev

    Pucihar et al. (2011, 320) definira celovite informacijske rešitve kot (angl. Enterpriseresource planning systems) rešitve, ki zagotavljajo integracijo vseh informacijskih tokov inposlovnih procesov na ravni celotne organizacije na podro jih financ, loveških virov,proizvodnje, logistike, prodaje, distribucije in nabave. ERP sistemom pripisujetanajpomembnejšo vlogo v razvoju in uporabi informacijske tehnologije na ravniorganizacije, saj omogo ajo racionalizacijo in poenostavitev poslovanja ter integracijoposlovnih procesov.

    Valacich in Schneider (2010, 345) pravita, da so ERP rešitve informacijski sistemi, kiomogo ajo integracijo informacij na vseh poslovnih podro jih oziroma na ravni celotneorganizacije. Omogo ajo shranjevanje podatkov, informacij v enotni centralni podatkovnibazi, dostopni vsem uporabnikom rešitve. Tako je omogo ena izmenjava in vpogled vinformacije preko uporabniškega vmesnika, ne glede na to, kje se informacije nahajajo, alikdo uporablja posamezne aplikacije rešitve.

    Bergman et al. (2010, 457) pravi, da je ERP sistem standardizirana rešitev, ki omogo astandardizacijo podatkov za organizacijo oziroma sistem. Zmanjšuje variabilnost podatkovin informacij, hkrati pa pove uje izmenjavo podatkov z uporabo podatkovnega rudarjenjain ra unalniško organizacijskih modelov in poslovne inteligence.

    O’Leary (2000, 27) pravi, da so ERP sistemi ra unalniško podprti sistemi, ki podpirajointegrirane transakcije organizacije in omogo ajo planiranje, proizvodnjo terzadovoljevanje strankinih potreb v realnem asu. ERP rešitve so gotove programske rešitvenamenjene arhitekturi odjemalec/strežnik, integrirajo ve ino poslovnih procesov tertransakcij, uporabljajo enotno podatkovno bazo, omogo ajo uporabo in dostop dopodatkov v realnem asu

    Lenart et al. (2010, 477) pravi, da so ERP rešitve integriran niz programov, ki podpirajotemeljne poslovne procese organizacije. ERP rešitev omogo a izmenjevanje podatkov nacelotni ravni organizacije. Informacije sistema služijo kot osnova za zmanjševanje sredstevter omogo ajo podporo poslovnih procesov.

    Bobek in Sternad (2008b, 10) navajata, da so ERP rešitve gotove programske rešitve,izdelane za arhitekturo odjemalec/strežnik. V njih je združena velika ve ina poslovnihprocesov in obdelujejo ve ino transakcij v organizaciji. Uporabljajo podatkovno bazo naravni organizacije, v kateri je vsak podatek zapisan samo enkrat. Omogo ajo dostop dorealnih podatkov. V nekaterih primerih omogo ajo tudi obdelavo transakcij in planiranjeaktivnosti.

    Mashari (2001, 176) definira ERP rešitve kot integrirane ve dimenzionalne informacijskesisteme, ki temeljijo na poslovnih modelih za na rtovanje, kontroling, upravljanje virov teroptimiziranje celotne dobavne verige. ERP rešitve temeljijo na uporabi najnovejšeinformacijske tehnologije, ki ustvarja dodano vrednost za vse sodelujo e.

  • 11

    Bryson et al. (2008, 500) navaja, da so ERP rešitve komercialni programski paketi, kiomogo ajo integracijo transakcijsko usmerjenih podatkov in poslovnih procesov. So vrstainformacijskih sistemov, ki omogo ajo integracijo klju nih procesov organizacije,upravljanje z informacijami in njihovo obdelavo.

    2.2 Razvoj celovitih informacijskih rešitev

    Prvi informacijski sistemi so se pojavili v letu 1960. Imenovali so se sistemi zaobvladovanje transakcij podjetij (angl. transaction processing systems). Združevali soobra unske funkcije in funkcije shranjevanja podatkov. Zmožni so bili produciratinaslednje funkcije: nabavna poro ila, pla evanje dobaviteljev, pla evanje zaposlenih,pregled zalog ipd. Nato so se pojavili menedžmentski informacijski sistemi (angl.Management information systems). Poro ila menedžmenta so že bila zasnovana na osnovimatemati nih modelov. Poro ila so predvidevala nabavne potrebe, optimizacijoproizvodnih virov ter distribucijo proizvodov do kon nih porabnikov. Današnjimenedžment informacijski sistemi (angl. Management information systems - MIS) služijosamo kot podpora menedžmentu pri odlo anju. V svojih za etkih pa so beležili, kaj se jedogajalo v podjetju.

    V proizvodni industriji so se nato pojavili sistemi za na rtovanje materialov (angl. materialrequirements planning systems - MRP). Omogo ali so na rtovanje, lociranje materialov vskladiš u, planiranje proizvodnje, prav tako nabave materialov in poslovanja. Na spodnjisliki je prikazano delovanje MRP sistemov. Poleg funkcije na rtovanja materiala so vidnetudi preostale, ki jih je sistem omogo al. Orodja sistema so podpirala usklajevanje inplaniranje prioritet in kapacitet. Povratne informacije sistema so lahko potekale (glej sliko1) do izvedbe operacij ter po vsej arhitekturi sistema do planiranja proizvodnje.

    Slika 1: Prikaz delovanja MRP sistemov (zaprta zanka).

    Vir: prirejeno po (Kremzar in Wallace 2001, 9)

  • 12

    MRPII sistemi (angl. manufacturing resources planning systems) so bili logi ni naslednikMRP sistemov. Sistemi za na rtovanje proizvodnih resursov so združevali funkcije tokamateriala od dobaviteljev skozi proizvodni proces (ter pripadajo im podprocesom) dokon nega proizvoda in kon nih odjemalcev. Klju na razlika med MRP in MPRII sistemi jebila zmožnost povezati poslovne funkcije, ki jih funkcionalnost MRP sistemov niomogo ala (McLeod in Schell 2001,305). Bobek in Sternad (2008b, 6) pravita, da zarazliko od MRP rešitev MRP rešitve II vsebujejo funkcionalnosti, ki omogo ajona rtovanje proizvodnih kapacitet in zbiranje informacij o stanju proizvodnega procesa teruvajajo principe povratnih zank za opozarjanje na neustrezne zmogljivosti proizvodnihresursov. Nato so bile razvite celovite informacijske rešitve (angl. Enterprise resourceplanning systems). Asemi, et al.(2010, 2) navaja, da so bile ERP rešitve razvite iz MRPIIrešitev (manufacturing resource planning II) sistemov, ki so bili osredoto eni predvsem naproizvodnjo. Medtem ko so današnje ERP rešitve namenjene razli nim vejam industrije dostoritev, distribucije do proizvodnje.

    Razvoj celovitih informacijskih rešitev lahko kronološko prikažemo v naslednjih fazah(McLeod in Schell 2001, 305):

    1. Sistemi za obvladovanje transakcij podjetij (angl. transaction processing systems).2. Menedžerski informacijski sistemi (angl. Management information systems MIS).3. Sistemi za na rtovanje materialov (angl. material requirements planning systems

    MRP).4. Sistemi za na rtovanje proizvodnih resursov (angl. manufacturing resources

    planning systems MRP II).5. Celovite informacijske rešitve - ERP.

    2.3 Uvajanje celovitih informacijskih rešitev

    Uvajanje celovitih informacijskih rešitev smo razdelili v tri ve je sklope:

    1. Izbira in nakup ERP rešitve.2. Uvedba ERP rešitev v organizacijo.3. Pristopi k uvajanju ERP rešitev.

    2.3.1 Izbira ter nakup celovitih informacijskih rešitev

    Življenjski cikel EPR rešitev sestoji iz razli nih faz. Bradford (2008, 69) navaja prvi dvefazi, kjer organizacije definirajo razloge in opredelijo zahteve za uvedbo rešitve, natoizberejo ponudnika in primerno rešitev. Kot morebitne razloge za prenovo informacijskegasistema navaja:

    Zastarelost obstoje ega informacijskega sistema.Operativni stroški. Delovanje in vzdrževanje starejših informacijskih sistemovpredstavlja prevelik finan ni zalogaj. Problemi izhajajo iz zastarele strojne opreme,

    inkovitosti oziroma neu inkovitosti poslovnih procesov in pomanjkanjaavtomatizacije.

  • 13

    Podporo informacijskih sistemov. Ponudniki rešitev ukinjajo tehni no podporostarejšim verzijam informacijskih sistemov, nadgradnjo rešitev in podro jevarovanja.Skladnost z gospodarskimi standardi. Gospodarstvo nenehno sili organizacije ktehnološkemu napredku in razvoju. Sektorji kot so ban ništvo, medicina, farmacijain avtomobilska industrija morajo vlagati v informacijsko tehnologijo z vidikanjihove konkuren nosti in obstoja na trgu.Prenovo oziroma zamenjava poslovnih modelov. Informacijski sistem, uveden preddesetimi leti ali ve , danes ne ustreza poslovnim zahtevam elektronskegaposlovanja.

    V procesu izbire ERP rešitve so zelo pomembne prednosti, ki jih bo le-ta z uvedboprinesla. Generalna ocena organizacij je, da bodo koristi uvedene rešitve presegle z njopovezane stroške. O ekonomiki celovitih informacijskih rešitev bomo spregovorili vnadaljnjih poglavjih. Razloge, ki podpirajo uvedbo ERP rešitev, lahko strnemo v štiriskupine (Bradford, 2008, 75). Prav tako O’Leary (2000, 89) navaja, da lahko poslovnerazloge za ustrezno izbiro ERP rešitve razdelimo v štiri skupine: tehnološke, iz vidikaprenove poslovnih procesov, strateške in konkuren ne.

    Tehnološki razlogi so ve ja ažurnost in to nost podatkov, ve ji nadzor nadzalogami organizacije, obvladovanje stroškov dela, ve ja hitrost obdelavepodatkov, izboljšana komunikacija s strankami in znotraj dobavne verige.Konkuren ni razlogi temeljijo na predpostavki, da so celovite informacijskerešitve grajene na principu najboljših praks. Organizacije so mnogokrat z vidikaobstoja organizacije na trgu primorane sprejeti odlo itev o prenovi informacijskegasistema.Strateški razlogi. Uvedba ERP rešitev je strateški cilj organizacije, saj omogo anadaljnji razvoj in rast, spojitve, pripojitve, prevzeme in združitve organizacij,tržno segmentacijo in podpira globalizacijo.Poslovni procesi. Prenova poslovnih procesov omogo a doseganje merljivihrezultatov, ki so kvantitativne narave, in nemerljivih rezultatov kvalitativne narave.Merljivi rezultati so predvsem znižanje stroškov, ve ji denarni tok, zmanjšanještevila zaposlenih, hitrejši odziv razmeram na trgu in hitrejši distribucijski tokovi.Med kvalitativne spadajo ve je zadovoljstvo strank ter izboljšani odnosi sstrankami.

    Pucihar et al. (2011, 321) pravi, da tržiš e EPR rešitev za razli ne industrije ponuja velikorazli nih rešitev ter metodologij uvajanj, ki seveda niso primerne za vse organizacije.Valacich in Schneider (2010, 360) trdita, da so ERP rešitve gotove programske rešitve, ki vosnovi ustrezajo vsem industrijam t.i. angl. »one size fits all strategy«. Organizacije morajov procesu izbire in nakupa ERP rešitve upoštevati razli ne dejavnike in kriterije izbirerešitve. Slednji vplivajo na ustrezno izbiro in prilagajanje rešitve organizaciji. Tako sezmanjšajo morebitne napake in veliki stroški neuspelih uvedb.

    Kriterije oziroma merila, ki jih moramo upoštevati, ko se odlo amo za uvedbo ERP rešitve,lahko razdelimo v štiri skupine (Valacich in Schneider 2010, 360):

    merila, povezana z izboljšavami, ki jih ERP rešitev prinesla,

  • 14

    merila, povezana z merjenjem kakovosti sistema,merila, povezana z izbiro uvajalcev rešitve inmerila, povezana s funkcionalnostmi rešitve.

    Poleg pomembnosti zgoraj navedenih kriterijev so pomembne naslednje lastnostiorganizacije, ki vplivajo na izbiro rešitve:

    velikost organizacije,rast organizacije intrenutna informacijska tehnologija.

    Ko organizacije definirajo razloge in opredelijo zahteve za uvedbo ERP rešitve, sledi fazaizbire ponudnika in rešitve. V tej fazi se izbere najprimernejši ERP paket ali nabormodulov, ki najbolj odgovarjajo poslovnim potrebam organizacije.

    Proces izbire ERP rešitve je sestavljen iz naslednjih faz (Bradford 2008, 78 85):

    1. Analiza zahtev. O osnovi se mora tim za izbiro rešitve ERP strinjati, kakšno ERPrešitev želijo uvesti. Dolo ijo se potrebe organizacije po ERP rešitvi, jasno sedefinira cilje, obseg projekta in prednosti, ki jih uvedba rešitve prinaša. V tej fazimora projektni tim opredeliti funkcionalnosti, ki jih omogo a obstoje ainformacijska rešitev. Dolo iti morajo poslovne procese, ki jih želijo z uvedboprenoviti. Vedeti morajo, ali bo uvedba nove rešitve omogo ala prenovo poslovnihprocesov in v kakšni meri. Analiza zahtev predstavlja osnovo za vse nadaljnje fazev procesu izbire rešitve ERP.

    2. Tržna raziskava ponudnikov ERP rešitev.3. Ožji nabor ponudnikov ERP rešitev (maksimalno 2 do 3 ponudniki). V tej fazi

    lahko z metodologijo gap-fit (angl. Gap-Fit Analysis) opravimo analizo, s kateroprimerjamo poslovne zahteve organizacije s funkcionalnostjo ERP rešitve.

    4. Ponudnike rešitev povabimo na preliminarni pogovor in sestanek. Ponudnik sesestane s sponzorjem projekta ter z direktorji organizacijskih enot. Namen jeponovno prediskutirati osnovne zna ilnosti in zahteve projekta.

    5. Demo dnevi. Ponudniki rešitev predstavijo demo verzijo rešitev s posnetki realnihposlovnih procesov. Ponudniki pripravijo predstavitev z naborom vsehfunkcionalnosti ERP rešitve in kriterijev izbora organizacije (glej tabelo 1).Rezultat faze je izbor ponudnika ERP rešitve, ki je prišel v ožji izbor.

    6. Metodologija uvajanja. Ponudnik rešitve in stranka morata uskladiti metodologijouvajanja rešitve, cilje, obseg, dolo iti mejnike, vire, asovni okvir ter dolžnosti invloge lanov projekta.

    7. Priprava predloga. V tej fazi se morata obe strani dogovoriti o obsegu projekta,pristopu uvajanja ter vlogah in odgovornostih lanov projekta. V organizaciji semorajo odlo iti, ali bodo uvedli celoten programski paket ali samo posameznemodule. Definirati morajo pristop uvajanja, pogoje nakupa rešitve s sklenitvijoenoletne ali ve letne pogodbe, dolo iti ceno letnih pristojb in, zagotavljanjatehni ne podpore ter morebitnih dograditev ERP rešitve. Predlog mora vsebovatiprojektni plan, kjer je dolo eno število in cena svetovalnih dni ter pla ilo prevoznihstroškov zunanjih izvajalcev. Jasno morajo biti definirane potrebe po ustreznistrojni ter programski opremi in drugih posebnostih informacijskega sistema.

  • 15

    8. Reference ponudnika rešitve. Ponudniki rešitev imajo pripravljene referen nespletne strani, dokumentacijo v pisni in elektronski obliki. Projektni tim skušapridobiti mnenja in izkušnje referen nih organizacij, ki so uvedle enako ERPrešitev. Primerjava naj poteka med organizacijami, ki so podobne v velikosti,izhajajo iz enakega industrijskega sektorja, uporabljajo podobno programsko instrojno opremo. Zanimati jih morajo stroški in as uvedbe, geografska bližinaponudnika rešitve, ocena ponudnikov rešitev kot implementacijski partner tersplošne izkušnje, problemska stanja in prednosti uvedbe rešitve.

    9. Pogajanja ter odlo itev izbiri rešitve. V zadnji fazi izbire rešitve potekajopogajanja med sponzorjem projekta ter predstavnikom ponudnika rešitve.Predstavniki pogajalcev organizacije morajo oceniti finan no stanje ponudnika,analizirati pogodbo ter razmisliti o nakupu, najemu ali možnosti outsourcingrešitve. Pogoji nakupa ali najema rešitve nimajo enakih pogajalskih izhodiš .Potrebno je dolo iti pogoje zagotavljanja tehni ne pomo i s strani ponudnikarešitve. Ob sklenitvi pogodbe za daljše asovno obdobje ponudniki ponujajopopuste v obliki rednega vzdrževanja ERP rešitve. Stroški poprodajnih aktivnosti inzagotavljanje nenehne podpore uporabnikom ( angl. on-line help, help desk, callcenter) lahko predstavljajo eno izmed dražjih stroškovnih komponent nakupa ERPrešitve. Doseganje terminskega plana uvajanja rešitve predstavlja pomembnokomponento pogajanj. V pogodbi so dolo eni penali ponudniku rešitve za primernedoseganja rokov in mejnikov uvedbe. Kon na pogajanja se zaklju ijo zdogovorom o ceni celotne storitve, podpiše se pogodba in proces uvedbe se lahkopri ne.

    Tabela 1: Kriteriji za izbiro ponudnika rešitve ERP.

    KRITERIJI ZA IZBIRO PONUDNIKA ERP REŠITVE Ponudnik A Ponudnik B Ponudnik CFunkcionalnost: proizvodnja x xFunkcionalnost: planiranje x x xFunkcionalnost: finance x xEnostavnost uporabe rešitve x xPrilagajanje rešitve x xIntegracija z obstoje imi IS x xSkladnost z obsegom organizacije x xStruktura cen

    as in stroški uvedbe x x xUvedba celotne rešitve ERP delna x xIntegracija z drugimi rešitvami x xKvaliteta, dostopnost, stroški podpore x x xPartnerstvo s ponudnikom rešitve x xRazumevanje poslovnih potreb organizacije xRazumevanje poslovnih procesov organizacije xPoslovna stabilnost xViri razvoja in raziskav xViri uvedbe in izobraževanja uporabnikov x xVir: prirejeno po Bradford (2008, 81)

  • 16

    2.3.2 Uvajanje ERP rešitev v organizacijo

    Valacich in Schneider (2010,346) trdita, da so ERP rešitve zasnovane v razli nih velikostihin oblikah ter da ponujajo edinstven niz funkcij in funkcionalnosti. Pri sprejemanjuodlo itev za uvedbo tovrstne rešitve se mora menedžment zavedati številnih posebnosti inodlo ujo ih dejavnikov. Med pomembnejše štejejo izbira ter nabor funkcionalnosti, ki jihrešitev ponuja, saj morajo le-te izpolnjevati tako poslovne kot zahteve strank indobaviteljev. Bancroft et al. (2001, 145) pravi, da je povpre en as implementacije ERPSAP rešitve v povpre ju od devet do dvanajst mesecev. Obstajajo organizacije, katerih ciljje zmanjšanje asovnega okvira implementacije na 4 do 6 mesecev. Vendar avtorjiopozarjajo, da je to mogo e dose i le ob uporabi »vanilla« verzije oziroma minimalnemuprilagajanju rešitve.

    Celovite informacijske rešitve so zasnovane po principu najboljših praks. Ve inaponudnikov ERP rešitev ima vgrajene poslovne procese najboljših praks v svoje rešitve inposamezne aplikacije. To predstavlja osnovo in napotke za prenovo poslovnih procesov.Odlo itev menedžmenta o izboru rešitve ERP bi morala med drugim temeljiti tudi navidiku uporabe najboljših praks. ERP rešitve, ki temeljijo na principu najboljših praks,omogo ajo hitrejšo in enostavnejšo uvedbo (Valacich in Schneider 2010, 357). Doberprimer je organizacija Computervision (ibid.,145), kjer so uspeli izvesti uspešnoimplementacijo SAP R/3 sistema v zgolj štirih in pol mesecih. Hitra namestitev rešitve jebila mogo a zaradi odlo itve sponzorja projekta, da so vse odlo itve v povezavi z uvedbosprejete v 48 urah. Obveza projektnega tima je bila, da sprejemajo vse odlo itve, povezanez uvedbo, skoraj na mestu, vendar dolo enih odlo itev ni bilo mogo e sprejeti takoj, sajniso bile v skladu s politiko organizacije.

    Lenart et al. (2010, 477) navaja, da manjše organizacije uvedejo ERP rešitve v skladu ssprejetim prora unom, medtem ko pri velikih organizacijah temu ni tako. Opravljali soraziskavo ocen stroškov uvedb ERP rešitev v Sloveniji in na Slovaškem. Generalnogledano je 68, 8% organizacij uvedlo rešitev v skladu s prora unom. V povpre ju so vseorganizacije presegle prvotni plan uvedbe (tako z vidika stroškov kot finan nih sredstevprojekta). V povpre ju pravi, so organizacije porabile 106% prvotno na rtovanih sredstev.Stroški uvedbe projektov ERP rešitve so odvisni od velikosti organizacije, obsegakonfiguracije rešitve, obsega uvedbe (Heemsta et al. 97).

    Za uvedbe ERP rešitev je zna ilno pravilo 80/20. 80% asa bo porabljenega na projektu, za20% opravil, 80% nezadovoljstva in splošno neodobravanje sprememb bo izhajalo iz 20%vidika oziroma pogleda na rešitev s strani kon nih uporabnikov ali managerjev, 80%sistemskih napak bo izviralo iz 20% testnih scenarijev (Shields 2001, 109). Mashari (2001,180) pravi, da je potrebno na uvedbo ERP rešitve gledati izklju no s poslovnega in neinformacijskega vidika. Potrebno je zmanjšati organizacijski odpor preko obrazložitverazlogov za spremembo v organizaciji in pridobljene koristi. Uvajanje celovitihinformacijskih rešitev po (Bradford 2008, 93) se sestoji iz naslednji razli nih faz. Vsakaizmed faz naslavlja razli ne udeležence in potrebna znanja. Projektni tim se na elomaodlo a med dvema pristopoma uvajanja, in sicer:

    pristop velikega poka ( angl. big-bang approach) infazni pristop (angl. phased approach).

  • 17

    Avtorji omenjajo tveganja povezana z uvedbo celovitih informacijskih rešitev. Vnadaljevanju naloge bomo sproti predstavljali tveganja in koristi uvedbe ERP. Gojal inSingla (2006, 62) dejavnike tveganja razvrš ata v naslednje skupine: splošni dejavnikitveganja uvajanja ERP rešitev, dejavniki uvedbe na osnovi razpoložljivega asa, virov terobsega uvedbe. Dejavniki povezani s asom t.i. migracije ERP rešitve, dejavniki tveganja,povezani s sodelovanjem uporabnikov na posameznih fazah projekta, dejavniki v faziplaniranja in analize zahtev, dejavniki v fazi dizajna, dejavniki v fazi zagona v živo terdejavniki, povezani z varnostjo. Kot druge dejavnike navajata operativne napake priizvajanju transakcij rešitve, napake programske opreme, velik delež prihodkov, namenjenraziskavi in razvoju, preveliko zanašanje na informacijsko tehnologijo in rabo interneta terposkuse kraje intelektualne lastnine. Na trgu se v zadnjem asu pojavlja vedno veaplikacij, ki presegajo klasi ne aplikacije, zajete v modulih ERP rešitev, CRM (angl.Customer Relationship Management), SCM (angl. Supply Chain Management).Organizacije so v preteklosti uvajale ERP rešitve ve let. Z novimi tržnimi pristopiprihajajo tudi novi na ini uvajanja teh aplikacij in ERP rešitev. Shields (2001, 23) pravi, dase vse ve organizacij poslužuje t.i. hitre uvedbe ERP rešitev. V nadaljevanju navajaklju ne dejavnike hitre uvedbe: sprejemati moramo hitre odlo itve, tehnološkainfrastruktura nam mora biti na razpolago tisti trenutek, ko pri nemo z uvedbo. Projektnitim mora biti majhen, sestavljen iz predstavnikov vseh organizacijskih ravni, projekta se nelotimo, dokler nismo prepri ani, da smo popolnoma pripravljeni in upoštevati moramona ela menedžmenta obsega. Izbrati moramo najboljšo ERP rešitev ali nabor aplikacij,izbrati prave zunanje izvajalce ter izvajati aktivnosti procesa vzporedno. Želimo namre ,da uvedba traja nekaj mesecev, ne pa nekaj let.

    Uvajanja ERP rešitev se lahko lotimo po:

    tradicionalni 5 fazni metodi alis strategijo hitre uvedbe, ki poteka v treh fazah z 12 aktivnostmi.

    Naloge so pri obeh pristopih bolj ali manj enake, razli no je upravljanje in organiziranjeposameznega na ina uvedbe. V okviru tradicionalnega pristopa uvedbe vsaka izmed fazobenem predstavlja mejnike projekta. Ob zaklju ku vsake faze se opravi analiza. Vprimeru, da so bili doseženi zastavljeni cilji in mejniki, nadaljujemo z naslednjo fazo.Prehod na naslednjo fazo ni mogo , e menedžment ugotovi, da mejniki niso bili doseženi.Slabosti takšnega pristopa se kažejo v tem, da so rezultati na projektu vidni v daljšemasovnem obdobju. Ponudniki rešitev ERP ponujajo svoje metodologije uvajanja, ki

    temeljijo na najboljših poslovnih praksah. Metodologije so strukturirani pristopi, kjer sofaze uvedbe jasno razdeljene na aktivnosti, te naprej na logi ne skupine projektnih nalog,katerih rezultate se da izmeriti. Naloge so naprej razdeljene na manjša opravila. V okvirutradicionalnih uvedb metodologije uvajanja ERP rešitev vsebujejo ve sto aktivnosti in vetiso nalog. Pristop hitre uvedbe pa zahteva izvajanja nalog in aktivnosti vzporedno. Slika3 prikazuje pristop hitre uvedbe ERP rešitev, ki poteka v treh ve jih fazah z 12aktivnostmi. Prav tako nazorno prikazuje paralelno izvajanje nalog v procesu hitre uvedbe.

    Slika 2: Tradicionalni pristop k uvajanju ERP rešitev.

    Vir: Shields (2001,34)

    Planiranje Analiza Design Razvoj Uvedba

  • 18

    Hitra uvedba

    Strategija hitre uvedbe je sestavljena iz treh faz, znotraj katerih poteka dvanajst aktivnosti.Na kratko bomo podali ve je zna ilnosti strategije hitre uvedbe ERP rešitev po posameznihaktivnostih; povzeto po (Shields, 2001, 49 65).

    1. Zaveza - aktivnost se pri ne pred dejanskim za etkom projekta (angl. projectkickoff). Definirati je potrebno cilje, pri akovanja in rezultate projekta. Izbrati jepotrebno projektne vodje, lanom projektne skupine je potrebno zagotoviti ustreznedelovne pogoje. Potrebno je dolo iti izhodiš a projektnega plana in izbrati lanecelotne projektne skupine.

    2. Za etek - pri ne se z za etnim sestankom projekta (angl. project kickoff meeting).Na sestanku so ponavadi prisotni top menedžment, izvršno - upravni odbor,sponzor projekta, projektni tim, direktorji funkcijskih podro ij, lani ponudnikarešitve ter lani zunanjih izvajalcev. Klju na dejavnost te faze je pri etekusposabljanja projektnega tima.

    3. Vodenje - vsebuje vse aktivnosti projektnih vodij, poveznih s planiranjem inupravljanjem sprememb projekta. Projektni vodje so zadolženi za nadzorovanje inizpolnjevanje obveznosti in nalog projektnega tima, za njihovo medsebojnokoordinacijo in sodelovanje. Projektni tim mora nenehno stremeti k doseganjuciljev in obsega projekta, oziroma k zaklju evanju nalog posameznih aktivnosti vskladu s asovnimi okvirom. Celoten projektni tim mora biti sposoben prepoznatipriložnosti projekta, jih uresni iti in reševati problemska stanja.

    4. Analiziranje - e smo v prejšnjih aktivnosti dolo ili cilje in vizijo projekta,moramo v sklopu analize definirati, kako bomo to dosegli. Dolo imo, kako boprenova poslovnih procesov sovpadala s funkcionalnostmi rešitve.

    5. Konfiguriranje - aktivnosti konfiguriranje zahtevajo podrobno poznavanje rešitveERP; tako lahko dolo imo tiste funkcionalnosti rešitve, ki najbolj ustrezajo našimposlovnim zahtevam.

    6. Testiranje - tukaj poteka testiranje posameznih transakcij sistema, njihoveinkovitosti ter skladnosti s prej dolo eno konfiguracijo. V tej aktivnosti je zelo

    pomembna vklju enost in sodelovanje uporabnikov, saj poznajo poro ila inpoizvedbe, ki jih je prejšnji sistem omogo al, in jih primerjajo s trenutnimi.

    7. Spremembe - menedžment sprememb ima vpliv tako na tehnološko inorganizacijsko podro je kot tudi na procesne spremembe.

    8. Pomo - se nanaša na sodelovanje internih strokovnjakov službe za informatiko.Pripraviti morajo ustrezne pogoje za delo projektnega tima (ra unalniki, telefoni,povezava z internetom, nameš ena mora biti programska oprema ponudnikarešitve). Te naloge morajo biti izpolnjene že v aktivnosti zaveza. V sami faziuvajanja rešitve pa morajo prevzeti vlogo sistemskih administratorjev inzagotavljati tehni no podporo.

    9. Pretvorba - tukaj je potrebno izvesti prenos podatkov iz obstoje egainformacijskega sistema v podatkovno bazo nove rešitve.

    10. Priprava - sem spadajo klju ne naloge, ki jih je potrebno opraviti pred zagonom vživo. Te naloge se odvijajo približno 4 do 6 tednov pred za etkom delovanja inuporabe nove rešitve. Opraviti se mora test integracije sistema, izobraževanjekon nih uporabnikov, pretvorba podatkov, priprava produkcijskega okolja indolo itev podpore po uvedbi.

  • 19

    11. Zagon v živo - z zagonom v živo se za ne uporabljati nova rešitev v organizaciji. Vorganizaciji se pri akujejo problemi in težave, ki bi naj trajali od nekaj dni pa tudido nekaj mesecev. Po zagonu v živo je potrebno zagotoviti zadostno podporouporabnikom s strani zunanjih izvajalcev kot ponudnika storitve. Potrebno jeopraviti revizijo projekta, kjer se ocenijo pozitivne in negativne vidike uvedbe.

    12. Izboljšave - pripravijo se predlogi za možne izboljšave naslednjih projektov napodlagi spoznanih izkušenj ter nadaljevanje z vzdrževalnimi deli in podporo.

    Slika 3: Proces hitre uvedbe ERP rešitev.

    Vir: Shields (2001,35)

    Axline et al. (2000, 182) omenja naslednje dejavnike kot najve je težave, povezane z ERPrešitvami: omejene funkcionalnosti, podpora k odlo anju in celotnemu poslovanju, težave,povezane z uvedbo rešitev in dograditvami, visoki celotni stroški lastništva (angl. total costof ownership). Ponudniki rešitev ponujajo odgovore oziroma rešitve zgoraj navedenihtežav. Rešitve vidijo v uporabi podatkovnih skladiš , ki podpirajo razli ne aplikacije,podporo odlo anju s posebnimi paketi rešitev, namenjenimi to no dolo eni veji industrije,z uporabo komponentizacije, dostopnosti do rešitve, uporabi web portalov, ki omogo ajodostop uporabnikom do poslovnih procesov kjerkoli na svetu, uporabi outsourcingaoziroma zunanjega nudenja programske opreme.

    Zadnji trendi na podro ju informacijskih rešitev kažejo na odmik od tradicionalnih ERPpaketov. Dolo ene organizacije menijo, da bodo z uvedbo ERP rešitve izgubile zmožnostprilagajanja spreminjajo im se tržnim spremembam. Razlogi izvirajo predvsem izkompleksnosti uvedb ERP rešitev. Zahtevajo ogromno asa, virov, njihova uvedba je težkain dolgotrajna, poleg tega je potrebno nenehno vzdrževanje in nadgradnja, saj sistemi nezagotavljajo takojšnih u inkov, ki jih lahko merimo s finan nimi ali drugimi kazalniki.Valacich in Schneider (2010, 381) pravita, da trendi narekujejo uporabo sistemov SOA

  • 20

    (angl. Service Orientated Acrhitecture Services). Uporaba SOA sistemov omogo arazdrobitev in lenitev poslovnih procesov na posamezne dele ali komponente. Poslovniprocesi se razdelijo na posamezne ravni in aplikacije upravljanja storitev.

    2.3.3 Pristopi k uvajanju celovitih informacijskih rešitev

    V tem poglavju bomo podali nekaj teoreti nih pogledov razli nih avtorjev k pristopomuvajanja celovitih informacijskih rešitev.

    Kremzar in Wallace (2001, 221) pravita, da obstajajo v širšem smislu trije generalnipristopi k uvajanju ERP rešitev: vzporedni pristop, big bang pristop in pilot pristop.O'Leary (2000,151) pravi, da obstajata dva primarna pristopa k uvajanju ERP rešitev: fazniin big bang pristop. Obstajajo pa tudi alternativni pristopi (O'Leary 2000,161) kot (angl.waved approach) pristop vala in agresivni fazni pristop ( angl. aggressive phasedapproach). Bobek in Sternad (2008a, 22) navajata naslednje pristope k uvajanju ERPrešitev: pristop velika poka (angl. big bang pristop), pristop malega poka, fazni pristop,vzporedni pristop, procesni pristop in hibridni pristop. Ve ina avtorjev pa podpira faznipristop kot kontinuiran in najpogosteje uporabljeni pristop.

    2.3.3.1 Big - bang pristop

    Big bang pristop omogo a uvedbo celotnega paketa naenkrat. Obstoje i informacijskisistem preneha delovati in isti trenutek uvedemo novega. Prednosti in slabosti big bangpristopa so ravno nasprotne kot prednosti in lastnosti faznega pristopa. Glavne prednostibig bang pristopa: ni potrebe po vmesnikih med obstoje o rešitvijo in novo uvedeno,krajši as uvedbe, saj se celoten projektni tim posveti procesu uvedbe. Kot glavna slabostse navaja možnost neuspele uvedbe, saj se naenkrat uvede celoten paket, delo na stareminformacijskem sistemu ni ve mogo e, as med razvojem rešitve in uvedbo se znapodaljšati, uporabniki nimajo priložnosti pridobiti znanja v asu uvedbe, potreben je velikobseg razpoložljivih loveških virov. Bobek in Sternad (2008, 26) omenjata še pristopvelikega malega poka (angl. mini big bang).To je pristop, kjer proces uvedbe rešitve ERPrazdelimo na dva ali ve delov. Vsak del je sestavljen iz ve povezanih modulov, ki seuvedejo na enak na in kot z metodo velikega poka. Bradford (2008, 100) pravi, da tapristop uporabljajo manjše organizacije z manj zahtevnimi poslovnimi procesi in takohitreje preidejo v fazo zagona v živo. Rezultati uvedbe so vidni mnogo prej kot pri drugihpristopih, vendar obstaja bojazen, da se zaradi hitrosti uvedbe spregledajo podrobnosti, kilahko usodno vplivajo na rezultate uvedbe.

    2.3.3.2 Vzporedni pristop

    Za vzporedni pristop po (Kremzar in Wallace 2001,221) je zna ilno, da isto asno delujetastar in nov informacijski sistem. So asno se spremlja delovanje obeh sistemov. Velja zaizredno kompleksen pristop, saj zahteva veliko loveških virov. Kremzar in Wallace ne

  • 21

    vidita uporabne vrednosti tega pristopa. Sprašujeta se o smiselnosti primerjave dvehsistemov. To pogojujeta z dejstvom, da smo pravkar uvedli nov ERP, obstojeinformacijski sistem pa je deloval v okolju MRP. O'Leary (2000,161) pravi, da vzporednipristop traja od enega meseca do etrtletja, ob tem da lahko uvedemo poljubno številomodulov. Vzporedni pristop ohranja stopnjo tveganja, saj v primeru neuspele uvedbeohranimo obstoje i informacijski sistem. Kot ve jo slabost O'Leary navaja podvojenoštevilo informacijskih in loveških virov vpetih v uvedbo. Tveganje vzporednega pristopase pove a, e organizacija spozna, da obstoje i informacijski sistem deluje bolje kotsistem, ki se uvaja.

    2.3.3.3 Fazni pristop

    Fazni pristop omogo a uvajanje posameznih modulov (eden po eden) ali v manjši skupini.Najprej uvedemo en model, nato pri nemo z uvedbo drugega. O'Leary (2000, 154 165)navaja prednosti in slabosti uvajanja modulov s faznim pristopom. Slabosti po O'Leary sovišji stroški uvajanja, daljši as uvedbe, uporaba vmesnikov med obstoje o in novorešitvijo, ker uvajamo module posami no, ne moremo zagotavljati skozi celoten procespopolne funkcionalnosti rešitve, so asno je tudi delovanje obeh informacijskih sistemov.Prednosti tovrstnega pristopa se kažejo v sorazmerno hitrem delovanju rešitve, epravfunkcionalnost ni izpolnjena. Z uvedbo vsakega novega modula naraš a produktivnost inznanje uvajalcev. Tako se zmanjša tveganje neuspele uvedbe. Uvedbi lahko namenimo vevirov, kot e bi uvajali pet ali šest modulov hkrati. Fazni pristop uvajanja traja mnogo dljekot drugi pristopi, zato (Bradford, 2008, 99) meni, da pomanjkanje hitrosti izvedbe opravilin nenehne spremembe vodijo do utrujenosti in naveli anosti zaposlenih.

    2.3.3.4 Procesni pristop

    Procesni pristop je podoben pristopu malega velika poka. V procesu uvedbe rešitve ERPrazdelimo poslovanje organizacije na vzporedne diagrame poslovnih procesov. Takonajprej uvedemo rešitev ERP za enostavnejši poslovni proces. Ko zaklju imo z uvedbotega, pri nemo z uvedbo naslednjega, zahtevnejšega procesa in tako nadaljujemo. Zaradimanjšega tveganja najprej uvedemo enostavnejše poslovne procese, nato pa kompleksnejše(Bobek in Sternad, 2008a, 30).

    2.3.3.5 Hibridni pristop

    Hibridni pristop je kombinacija procesnega, faznega in vzporednega pristopa. Kot ve jaslabost se pojavlja dejavnik, da je ta pristop le redkokdaj dobro planiran. Prednosti sekažejo v tem, da ni fiksen, ampak se lahko prilagaja med uvajanjem rešitve ERP. Vza etku uvedbe projektni tim uporabi vzporedni pristop in ko s pomo jo tega pristopaspozna ve o uvajanju modulov, preklopi na fazni ali procesi pristop (Bobek in Sternad,2008a, 31).

  • 22

    O'Leary navaja (2000, 160) tudi alternativne pristope uvajanja ERP rešitev. Ena takih jepristop vala (angl. waved), kjer je organizacija uvedbo definirala kot program sprememb vposameznih nizih oziroma valih. Vsak niz oziroma val je prinesel sprememboposameznemu poslovnemu podro ju. Podaja primer organizacije Tektronix, ki je v rokutreh let uvedla rešitev Oracle. Prednosti tovrstnega pristopa vidi v tem, da uvedba vsakeganiza omogo a povratne informacije (kako je bila sprememba sprejeta in kaj je doprinesla).Z vsako uspešno uvedbo je rasla morala in motivacija projektnega tima. Kot klju noprednost pa navaja, da z vsako dograditvijo rešitve ERP obstaja možnost uvedbe dodatneganiza oziroma vala sprememb. Agresivni pristop k uvedbi predvideva uvedbo ve modulovhkrati in povezavo z obstoje im informacijskim sistemom.

    2.4 Življenjski cikel celovitih informacijskih rešitev

    Življenjski cikel ERP rešitev je razdeljen na ve faz. Avtorji razli no podajajo definiciježivljenjskega cikla, nekateri v petih, drugi v sedmih fazah. V nadaljevanju bomo podalirazli ne poglede avtorjev na to tematiko.

    O'Leary (2000, 89) opisuje življenjski cikel ERP rešitev v naslednjih fazah: sprejetjeodlo itve za uvedbo rešitve ERP, izbira rešitve ERP, razvoj rešitve ERP, prenovaposlovnih procesov ali prilagajanje rešitve ERP obstoje im poslovnim procesom, uvajanjerešitve ERP, aktivnosti po uvedbi in izobraževanje uporabnikov rešitve. Bradford (2008,67) pa deli življenjski cikel na faze: sprejemanje odlo itve in razlogi za uvedbo rešitveEPR, izbor rešitve ERP, razvoj rešitve, uvedba rešitve in vzdrževanje rešitve.

    McLeod in Schell(2001,19) življenjski cikel ERP rešitev opisuje v petih fazah.

    Slika 4: Faze življenjskega cikla ERP rešitve.

    Vir: prirejeno po McLeod in Schell (2001, 19)

    1.Faza planiranja

    2.Faza analize

    3.Faza dizajna

    4.Faza uvajanja

    5. Faza uporaberešitve

    Faze življenjskega cikla ERP rešitve

  • 23

    Faze planiranja, analize, dizajna in uvajanja je poimenoval kot enotno fazo razvoja ERPrešitve v sklopu življenjskega cikla. Faza uporabe rešitve traja tako dolgo, dokler nipotrebe po prenovi rešitve, kar zahteva ponovitev celotnega življenjskega cikla. Vnadaljevanju bomo podrobneje navedli posamezne faze ter njihove korake.

    Faza planiranja - Menedžment organizacije pride do spoznanja, da je potrebna prenovainformacijske rešitve. Naslednji korak je dolo itev problema, menedžment se zavedaobstoja problema. V tem koraku se zbirajo samo površne informacije, menedžment dolo ivzroke za prenovo informacijskega sistema. Menedžment s pomo jo sistemskega analitikadolo i osnovne cilje, ki opredeljujejo, kaj bi pridobili z uvedbo nove informacijske rešitve.Nato se dolo ijo omejitve, ki jih z uvedbo prinaša informacijska rešitev. Bodisi da gre zaomejitve organizacijske narave, ujemanje z ra unovodskimi standardi ali dolo itevasovnega okvira, kdaj bo obstoje i sistem prenehal delovati oziroma se bo uveljavil novi.

    Študija izvedljivosti uvedbe rešitve je naslednji korak. Tu se dolo ijo dejavniki, ki bodovplivali na to, ali bo uvedba rešitve izvedena v skladu z zastavljenimi cilji. Ti dejavniki sotehni ne, ekonomske, neekonomske, pravne, eti ne ali operativne narave. Opravi se študijapredlogov izvedbe projekta. Na podlagi vseh predlogov se menedžment lahko odlo i zauvedbo nove rešitve ali pa tudi ne. Faza planiranja se zaklju i z vzpostavitvijo ustreznegasistema za zagotavljanje kakovosti na projektu uvedbe. Dejavnika tveganja v faziplaniranja (Gojal in Singla 2006,62) sta pomanjkanje podpore top menedžmenta insponzorja projekta.

    Faza analize - se pri ne z uradno objavo projekta uvedbe ERP rešitve. V tem koraku moramenedžment pojasniti vsem zaposlenim cilje projekta in prednosti uvedene rešitve zaorganizacijo in uporabnike. Pred uvedbo nove rešitve je potrebno minimizirati stopnjostrahu uporabnikov. To lahko storimo v okviru sestankov menedžmenta ali s pisnimiobrazložitvami in video posnetki. Sledi sestava projektnega tima z multidisciplinarnimiznanji. Dolo iti je potrebno informacijske zahteve. S pomo jo anket, osebnih intervjujev inopazovanj se sestavi projektni slovar, ki vsebuje vse informacije in dokumentacijo. Podatkiso podani s pomo jo grafov, diagramov in posnetkov poslovnih procesov. Zbrani so vsipodatki obstoje ega informacijskega sistema ter opredeljene nove potrebe po informacijskiplatformi s strani uporabnikov. Dolo ijo se merila zmogljivosti novega sistema, oblikatabel, poro il, poizvedb oziroma kvaliteta in obseg poro ilnega sistema. Kot zadnje sepripravi predlog za prehod na fazo dizajna, ki mora biti odobrena s strani izvršnegamenedžmenta.

    Faza dizajna - v tej fazi se dolo i potek poslovnih procesov v organizaciji in ERP rešitve.Dolo i in opravi se integracija, kostumizacija in prenos podatkov. Ta faza je izrednotehni no zahtevna in zahteva programersko zanje. Opravi se podatkovno modeliranje termodeliranje procesov in objektov. Faza dizajna temelji na konfiguraciji in nastaviparametrov, ki so potrebni glede na funkcijske zahteve ERP rešitve. Na zaklju ku sepripravi predlog prehoda na fazo uvedbe, ki vklju uje oceno obsega dela, zastavljenihciljev in stroškov faze uvedbe. Gojal in Singla (2006, 62) omenjata naslednje dejavniketveganja zna ilne v fazi dizajna ERP rešitve: visoka cena rešitve, vse ve ja razdrobljenostin raznolikost procesov, izbira rešitve lahko vpliva na zahtevano nivo znanja uporabnikov,zmogljivost omrežja kot pogoj za dostop do rešitve ERP, integriranost ERP rešitve, ki zostalimi sistemi dviguje raven kompleksnosti, ter razne modifikacije, ki prinašajospremembe poslovnih procesov.

  • 24

    Faza uvedbe - podobno kot druge faze se tudi ta za ne z uradno objavo. Poleg objave jenamen združiti vse sodelujo e na projektu ter zaposlene v družbi. McLeod in Schell (2001,135) pravita, da je nato potrebno pridobiti primerno strojno opremo. V primeru, daorganizacija uvaja lastno rešitev, je seveda potrebno pridobiti tudi ustrezno programskoopremo. Sledi priprava podatkovne baze. V nekaterih primerih je potrebno pridobiti novepodatke, ponavadi pa se opravi samo prenos podatkov iz enega informacijskega sistema vdrugega. Potrebno je poskrbeti za ustrezne pogoje (primerna temperatura, vlaga,ognjevaren prostor in drugi varnostni ukrepi) v prostorih, kjer se nahaja vsa strojnaoprema. Sledi izobraževanje uporabnikov nove rešitve. Nato se pripravijo predlogi zaprehod na nov sistem. Izbiramo lahko med pilotno verzijo, takojšnim prehodom na novsistem (big bang pristop), faznim ali vzporedni prehodom.

    Faza uporaba rešitve - je sestavljena iz petih korakov. Za nemo uporabljati novo rešitev.Ko se rešitev ustali, opravimo revizijo, ki je izvedena s strani strokovnega osebja spodro ja informatike ali s strani zunanjega izvajalca. Revizija bi se naj opravljala vsakoleto. Potrebna so redna vzdrževalna dela za odpravljanje napak, vzdrževanje to nosti inmožnih izboljšav rešitve. e uvedba rešitve ni bila uspešna, se pripravi predlogreinžiniringa oziroma prenove poslovnih procesov. Pripravi se poro ilo in predlog zagonanovega življenjskega cikla uvedbe celovite informacijske rešitve. V primeru, da je predlogsprejet, nov življenjski cikel sledi na elom menedžmenta prenove poslovnih procesov.

    Celovite informacijske rešitve so zasnovane na tehnološki osnovi. Prikazali bomopovezavo ERP rešitve skozi življenjski cikel tehnologije, prirejeno po (Radonji , 2008, 7).Opuš ene tehnologije so v glavnem že nadomestili oziroma jih še bodo. Bazne tehnologijeso v splošnem na razpolago, z njimi se oskrbujejo konkuren na podjetja v panogi in bodo vprihodnosti ve inoma vklju ene v proizvode in postopke. Prav zaradi tega je njihovkonkuren ni pomen v prihodnosti manjši. Klju ne tehnologije (npr. ERP rešitve) trenutnopomembno vplivajo na gospodarstvo in družbo ter tvorijo podlago za ustvarjanjekonkuren ne prednosti. Prihajajo e tehnologije so ve inoma še v bolj ali manj zgodnjemrazvojnem stanju, zato so manj razširjene in trenutno konkuren no manj pomembne, vendarbodo lahko v prihodnosti klju ne. Nove tehnologije so pogostokrat neekonomi ne zauporabo, zanje je zna ilen tudi visok investicijski riziko.

  • 25

    Slika 5: Razvrš anje tehnologij glede na konkuren no sposobnost po fazah življenjskega cikla.

    Vir: Radonji (2008, 7)

    Yeates (1991,192) pravi, da je povpre en življenjski cikel informacijske rešitve približnosedem let. Vzdrževanje rešitve v tem obdobju predstavlja približno 80% vseh stroškovrešitve skozi celoten življenjski cikel, vendar so tukaj izvzeti vsi ostali stroški delovanjaERP rešitve v tem asu. ERP rešitev uvedena v skladu z metodologijo, ki omogo adograditve in modifikacije skozi življenjski cikel, se bo izkazala kot stroškovno u inkovitav daljšem asovnem obdobju. Vsi dodatni stroški v fazi razvoja rešitve se bodo rezultirali vve jem izkoristku skozi življenjski cikel.

  • 26

    2.5 Mejniki uvajanja

    Turban et al. (1996, 395) navaja mejnike projekta kot temeljno orodje projektnegamenedžmenta. Mejniki projekta predstavljajo nekakšne kontrolne to ke, ki omogo ajopregled napredka projekta ali morebitna problemska stanja ter zaostanke. Tehnikeplaniranja mejnikov omogo ajo menedžmentu dolo anje dodatnih virov, morebitnoprekinitev ali modifikacije projekta. Mejniki projekta so dolo eni na osnovi predvidenegaasa, prora una in doseganja rezultatov oziroma vmesnih faz projekta.

    Najpogosteje uporabljene tehnike planiranja mejnikov projekta so:

    CPM - (angl. Critical path method),PERT - (angl. Program evaluation and review technique),GANTTOV diagram.

    2.5.1 CPM

    Turban et al. (1996, 396) - pogosto uporabljena tehnika planiranja mejnikov projekta jeCPM (angl. critical path method). Diagram CPM predstavlja mrežo nalog in zahtev zadokon anje projekta. CPM diagram je sestavljen iz razli nih dejavnosti in nalog.Dejavnosti so opredeljene z vidika asa in virov, ki so potrebni za dokon anjeposameznega segmenta celotnega projekta. Dejavnosti so predstavljene s pomo jo krogov.Naloge so prikazane z neprekinjenimi rtami s smernimi puš icami, ki predstavljajozaklju ek posameznega dela ali segmenta projekta. Prekinjene rte s smernimi puš icamipredstavljajo zaporedno odvisnost med nalogami, vendar ni potrebna uspešna realizacijanaloge iz prejšnje dejavnosti za prehod na novo dejavnost. Klju no prednost CPM tehnikepredstavlja dolo itev celotnega asovnega okvira projekta, ki jo predstavlja najdaljša pot(dolo ena v asovni enoti). Slednja je razvidna iz diagrama in se imenuje kriti na pot.

    Slika 6: CPM diagram.

    Vir: prirejeno po Turban (1996,396)

  • 27

    2.5.2 Ganttov diagram

    Turban et al. (1996, 396) - Ganttov diagram je podobna tehnika kot je CPM, ki opredeljujenabor nalog, ki se izvajajo, in dolo a, kdaj se pri nejo oziroma kon ajo. Ganttov diagramne prikazuje zaporedno odvisnost med nalogami kot pri tehniki CPM. Kot vidimo vdiagramu spodaj, ni potrebno, da je faza analize dokon ana, preden se pri nejo izvajatiaktivnosti faze dizajna. Ganttov diagram v osnovi ni tako kompleksen kot CPM diagram,vendar ga je lažje razumeti in pripraviti. Dobra lastnost Ganttovega diagrama je, da lahkovklju imo makro - Ganttov diagram v mikro - Ganttov diagram. Npr. za fazo analizenapravimo mikro diagram in dolo imo podrobnejša opravila in naloge, odgovornosti,asovne ovire in terminske plane.

    Graf 1: Ganttov diagram

    Januar Februar Marec April Maj Junij JulijAnalizaDizajnRazvojTestiranjeImplementacijaOcenitevVir: Turban (1996, 397)

    2.6 Dejavniki uspešnih in neuspešnih uvedb celovitih informacijskih rešitev

    O’Leary (2000, 213) pravi, da je mnogo implementacij izvedenih uspešno oziromaneuspešno zaradi razli nih razlogov. e je tveganje v okviru projekta pravilno zastavljeno,se lahko izkaže tako kot dejavnik uspeha ali neuspeha. Tveganja se pojavljajo skozi celotenživljenjski cikel ERP rešitve. Vrsta in obseg tveganj se spreminjajo odvisno od tega, kje senahajamo v življenjskem ciklu rešitve.

    Tabela 2: Matrika tveganja

    Življenjski cikel ERPrešitve Tveganja

    Tehnološka Poslovna OrganizacijskaOdlo itev za ERP XIzbira ERP rešitve XDizajn X XImplementacija X X XAktivnosti po uvedbiIzobraževanje X X

    Vir: prirejeno po O’Leary (2000, 213).

  • 28

    Tehnološka tveganja - to so tveganja ob novem operacijskem sistemu, arhitekturiodjemalec/strežnik, relacijski podatkovni bazi, ali tveganja pri integraciji s preostalimiinformacijski rešitvami.Poslovna tveganja - izhajajo iz odlo itev organizacije o izbiri modulov, procesov rešitvein na ina delovanja procesov v organizaciji ter navzven, s partnerskimi podjetji indobavitelji. Pomembno je vedeti tudi, kakšen nivo konkuren nosti zagotavlja ERP rešitev.Organizacijska tveganja - izhajajo iz zaposlenih, organizacijske strukture in okolja, vkaterem je ERP izbran in implementiran.

    Kimble et al. (2010, 417) navaja najpogostejše vzroke za neuspešne uvedbe ERP rešitev:

    nejasna povezanost med cilji projekta in cilji organizacije,nezadostna podpora top menedžmenta,nezadostno sodelovanje z delni arji organizacije,pomanjkanje znanja s podro ja projektnega menedžmenta,pomanjkanje znanja in virov ob kompleksnosti projekta.

    Valacich in Schneider (2010, 380) navaja rezultate anket, ki kažejo, da 40 60%organizacij, ki so uvedle eno izmed informacijskih rešitev, niso zadovoljne z rezultati.Razlogi: nezadostna podora top menedžmenta, uvedbe rešitve brez pomo i zunanjihizvajalcev, nezadostno izobraževanje uporabnikov, pomanjkanje multidisciplinarnosti pripristopu uvajanja. McLeod in Schell (2001, 313) poudarjata, da je potrebno pred za etkomuvedbe dose i konsenz med vodstvom in ostalimi deležniki v organizaciji. Priti morajo dospoznanja, da bo potrebno prilagoditi poslovne procese ERP rešitvi in razumetikompleksnost uvedbe.

    Bradford (2008, 102) omenja naslednje dejavnike, ki vodijo k uspešni uvedbi ERP rešitev:

    Sestava projektnega tima, ki bi naj vklju eval sponzorja projekta, kon neuporabnike in top menedžment organizacije.Organizacijska kohezivnost z mo no podporo uprave organizacije. Celotnaorganizacijska struktura mora biti podrejena in zavezana k uspehu projekta odza etne zaveze do zaklju ka uvedbe.Komunikacija na projektu, ki bi naj temeljila na na elih poštenosti, neposrednostiin zagotavljanja kakovosti. Soo anje s problemi in reševanje le-teh.Dokumentacija na projektu (projektni plan, listina projekta, najnovejša uporabniškanavodila, kodeks korporativnega obnašanja in pravil).Projektni menedžment. Uporaba principov projektnega menedžmenta (projektniplan, projektni tim, budget projekta, roki projekta, ustrezna metodologijaodkrivanja problemov).Testiranje rešitve, zagotavljanje kakovosti in izobraževanje uporabnikov.

    Yeates (1991,219) ocenjuje dejavnike neuspelih uvedb zgolj iz organizacijskih vzrokov, nepa tudi tehnoloških, in sicer premalo podpore s strani menedžmenta, pomanjkanje virovprojekta ( loveški, psihi ni, finan ni), pomanjkanje podpore rešitvi s strani uporabnikov,slaba ocena funkcionalnosti rešitve v primerjavi s potrebami poslovanja. Stroški neuspelihuvedb se kažejo v posledicah pri poslovanju organizacije (nezadovoljne stranke, izgubaposla in prihodkov, zamujene priložnosti, pritisk konkurence). Posledice, ki so interne

  • 29

    narave, vplivajo na vse organizacijske ravni (neu inkovito uporabljeni loveški viri v asuuvajanja, demotivirani zaposleni, porušena korporativna kultura).

    Tveganja, ki se pojavijo po uvedbi ERP rešitev, (Pan et al., 2010, 111) razvrš a v štiriskupine ter jih podrobneje deli v podskupine.

    1. Operativna tveganja1.1. Splošna

    1.1.1. Uporabniki neradi uporabljajo ERP rešitev.1.1.2. Uporabniki napa no vnašajo podatke.

    1.2. S podro ja marketinga in nabave.1.2.1. Uporabniki s podro ja nabave ne morejo pridobiti potrebnih informacij ERP

    rešitve.1.2.2. Uporabniki s podro ja nabave ne morejo/znajo posodabljati informacij o

    strankah.1.3. S podro ja proizvodnje in materialnega poslovanja.

    1.3.1. Sistem vsebuje neto ne podatke o dobaviteljih.1.3.2. Sistem vsebuje neto ne podatke o kosovnicah materiala.1.3.3. Sistem vsebuje neto ne podatke o zalogah materiala.

    1.4. S podro ja financ in ra unovodstva.1.4.1. Uporabniki s podro ja ra unovodstva ne želijo prenašati delovne

    odgovornosti, nalog ter pravic na uporabnike drugih podro ij.1.4.2. Uporabniki z drugih podro ij niso pripravljeni prevzeti odgovornosti in

    nalog s podro ja financ in ra unovodstva.2. Analiti na tveganja

    2.1. Splošna2.1.1. Top menedžment zavra a uporabo aplikacij ERP rešitve.2.1.2. Menedžment/vodstvo ne more pridobiti želenih informacij ERP rešitve.

    2.2. S podro ja marketinga in nabave2.2.1. Uporabniki na znajo uporabljati sistema za potrebe pridobivanja to nih

    podatkov o napovedi prodaje.2.2.2. Uporabniki na znajo uporabljati sistema za potrebe napovedovanja potreb

    po novih izdelkih/materialih.2.3. S podro ja proizvodnje in materialnega poslovanja

    2.3.1. Sistem ne omogo a planiranja terminski okvirov/posameznih faz inpostopkov proizvodnje.

    2.3.2. Sistem ni zmožen generirati potrebnih materialnih na rtov/potreb pomaterialu

    2.4. S podro ja financ in ra unovodstva2.4.1. Uporabniki ne znajo pridobivati ustreznih podatkov finan nih

    prora unov/finan ni budget.3. Organizacijska tveganja

    3.1. Top menedžment3.1.1. Top menedžment sprejema pomembne odlo itve brez posvetovanj z

    zunanjimi svetovalci in uporabniki.3.1.2. Top menedžment ne zagotavlja zadostne podore ERP sistema po kon ani

    uvedbe.3.1.3. Spremembe osebnostnih karakteristik top menedžmenta v asu po uvedbi.

  • 30

    3.2. IS/ERP sistem3.2.1. Poslovni na rt projekta uvedbe ni v skladu s poslovno strategijo, je slabo

    opredeljen in nepopoln.3.2.2. Strategija za nadaljnje izboljšave ERP sistema ni znana oziroma je nejasna.3.2.3. Viri in prora un za izvedbo ERP projekta ne ustrezajo zahtevam.

    3.3. In-house specialisti s podro ja informatike ali katerega drugega, ki imajo zadostnoznanje s podro ja ERP rešitve.

    3.3.1. Ne morejo oblikovati kompetentne ekipe, ki bo skrbela za nadzor delovanjarešitve ERP.

    3.3.2. Slabo usposobljeni ter nezadostno izobraženi strokovnjaki s podro ja ERPrešitve.

    3.3.3. Nezadostno znanje oziroma know-how, pridobljen v procesu uvedbe rešitveERP.

    3.4. Uporabniki rešitve3.4.1. Uporabniki (kon ni uporabniki kot top menedžment) niso bili deležni

    zadostnega izobraževanja.3.4.2. Težave delovanja rešitve ERP, s katerimi se sre ujejo uporabniki rešitve,

    niso javljene potrebnim organom (službi za informatiko, ponudniku rešitve, kizagotavlja podporo in pomo ).

    3.4.3. Nedolo ene pravice dostopa do podatkov.3.5. Ponudniki rešitve/zunanji izvajalci in svetovalci

    3.5.1. Nezadostna podpora s strani ponudnika rešitve.3.5.2. Nezadostno in neustrezno svetovanje s strani ponudnika.

    4. Tehnološka tveganja4.1. Integracija sistema

    4.1.1. Integracija ERP rešitev in drugih informacijskih sistemov.4.2. Napake/pomanjkljivosti sistema

    4.2.1. Neveljavni podatki niso avtomatsko zaznani pri vhodu v sistem.4.2.2. Problemi povezani s strojno in programsko opremo.

    4.3. Vzdrževanje sistema4.3.1. Neustrezno upravljanje zastarelih podatkov/podvajanja podatkov.4.3.2. Rešitev ni bila ustrezno prilagojena poslovnim zahtevam.4.3.3. Odpravljanje tehni nih napak traja predolgo.

    2.7 Ekonomika celovitih informacijskih rešitev

    Khan (2002, 10) pravi, da so stroški uvajanja ERP rešitev odvisno od velikostiorganizacije, sektorja industrije, v katerem se nahaja, od števila divizij, obsegafunkcionalnosti uvedene rešitve, obstoje ega informacijskega sistema, upravljanjaorganizacije, od organizacijske kulture, na ina poslovanja organizacije, poslovnihprocesov, obstoje e strojne opreme in infrastrukture, števila uporabnikov in ostalihdejavnikov.

    Oswald (2004, 151) govori o ekonomiki in donosnosti naložb, kot je uvedba celoviteinformacijske rešitve. V ospredje postavlja skupne stroške lastništva TCO (angl. total costof ownership) in donose investicije ROI (angl. return on investment) uvedb SAP in drugihcelovitih informacijskih rešitev. ROI lahko definiramo po tem, kako u inkovito je

  • 31

    organizacija uporabljala njihov kapital za generiranje dobi ka. Z uvedbo ERP rešitveželimo znižati celotne stroške ter obenem maksimizirati finan ne donose, ki jih ta ustvarja.

    Na velikost TCO vpliva velikost organizacije in posledi no število kon nih uporabnikov.Ve ja kot je organizacija, ve je uporabnikov, poslovnih procesov in transakcij. Pomembnaje funkcionalnost rešitve, ki je pogojena s številom uvedenih modulov. Stroški, povezani zuvedbo rešitve, ki združujejo licence za programsko in podatkovno bazo, stroški strojneopreme, stroški povezani s storitvami uvedbe in notranji stroški organizacije (Bradford,2008, 74).

    TCO metoda omogo a izvajanje kontrole stroškov in optimiziranje IT infrastrukture zdolo itvijo celotnih stroškov skozi njen življenjski cikel. Avtor opozarja, da ERP rešitev znajnižjo vrednostjo TCO ni nujno najboljša izbira za organizacijo in da organizacije priprojektih uvedbe ne posve ajo dovolj pozornosti t.i. mehkim dejavnikom, kot je na primerkakovost informacijske tehnologije. Metoda uravnoteženih kazalnikov lahko nadomestipomanjkljivosti TCO metode. Poleg standardnih finan nih izkazov ta metoda podajaizkaze o strankah, uporabnikih rešitve, o notranjih informacijskih procesih ter oizobraževanju uporabnikov.

    Osnovni namen obeh metod je optimizacija IT infrastrukture. Metoda ne omogo afinan nih izkazov analiz, ki jih uvedba ERP rešitve s svojim delovanjem zagotavlja. Da biugotovili dolgoro ne finan ne u inke uvedbe, moramo primerjati celotne stroške zdonosom investicije (ROI).

    TCO stroškovni model zajema posredne in neposredne stroške. Neposredni stroški sopovezani z naro anjem strojne in programske opreme, s pogodbami z zunanjimi izvajalciali ponudniki rešitev o vzdrževanju ter pla ami v sektorju za informatiko. Posredni stroškiso povezani z lastnimi stroški organizacije v zvezi s podporo ERP rešitve za lastneuporabnike, z zniževanjem produktivnosti uporabnikov rešitev zaradi napak na programskiali strojni opremi. Oswald (2004,152) pravi, da so celotni stroški informatike razdeljeni:

    10% stroškov inovacij predstavljajo stroški, kadar prvi uvajamo ERP rešitev, ali jorazvijamo;30% stroškov predstavljajo projekti, povezani s poenostavitvijo obstoje ih funkcijin aplikacij in60% operativnih stroškov, ki nastajajo na dnevni ravni. Stroški podporeuporabnikom, help-desk storitve, stroški vzdrževanja programske opreme, popravkidograditve aplikacij, stroški za strojno opremo, stroški upravljanja s podatkovnimibazami, operacijskimi sistemi in programsko opremo namenjeno menedžmentu.

    Samo z optimizacijo stroškov ne bomo dosegli želenih rezultatov. Uravnotežen sistemkazalnikov in TCO model pripomore k temu, da organizacije prepoznajo, katerimpodro jem uvedbe morajo posvetiti najve pozornosti, da zagotovijo im nižje stroškeuvajanj in ve jo donosnost ERP rešitve.

    Zhang in Li (2006, 231) prikažeta smiselnost uvajanja ERP stroškov po ekonomski plati.Pravita, da si morajo organizacije zastaviti vprašanje, koliko stane projekt uvedbe in aliuvedba ERP rešitve ustvarja prihodke. V grafih bomo prikazali gibanje mejnih stroškov(MS) in mejnega profita (MR). Na podlagi gibanja stroškov bomo prikazali smotrnostodlo itve uvedbe ERP rešitve.

  • 32

    Graf 2: Primerjava mejnih stroškov in mejnega profita uvedb ERP projektov 1.

    Vir: prirejeno po Zhang in Li (2006, 222)

    Iz grafa 2 je razvidno, da mejni stroški uvajanja ERP rešitve naraš ajo postopoma, medtemko mejni prihodki postopoma padajo. Mejni stroški vseskozi presegajo mejni prihodek,zato je smotrna odlo itev, da se ne lotimo projekta uvedba rešitve. V grafu 3 vidimo, da sov za etku mejni prihodki višji od mejnih stroškov, kar je pozitivno za organizacijo. V to ki0 pride do ravnovesja, kjer se izena ijo MS=MP mejni stroški in mejni prihodki.Ekonomsko gledano je to optimalna to ka za odlo itev o za etku procesa uvedbe rešitveERP.

    Graf 3: Primerjava mejnih stroškov in mejnega profita uvedb ERP projektov 2

    Vir: prirejeno po Zhang in Li (2006, 222)

    MS

    MP

    DenarnaEnota

    Proces uvedbe ERP rešitve

    UVEDBA ERP REŠITVE JE EKONOMI NA!

    0

    MS

    MP

    Proces uvedbe ERP rešitve

    UVEDBA ERP REŠITVE NIEKONOMI NA!

  • 33

    3 CELOVITA INFORMACIJSKA REŠITEV SAP

    3.1 Predstavitev informacijskega sistema in zna ilnosti

    Podjetja SAP ima sedež v nemškem Walldorfu in je najve je svetovno podjetje napodro ju programske opreme za podjetja. Temelji podjetja so grajeni na konceptuintegracije. SAP-ova družina izdelkov in storitev povezuje podjetje od financ in kadrovskihsistemov do proizvodnje, prodaje in distribucije. Vsak od omenjenih modulov u inkovitoupravlja dolo eno podro je organizacije ter vsebuje poslovne procese, ki temeljijo nanajboljših praksah posameznega podro ja. Cilj podjetja je bil razviti paket, ki bi lahkointegriral poslovne rešitve, torej zagotovil boljši pretok informacij. Tako se je podjetjerazvilo v Systems, Applications and Products in Data Processing (SAP) (Larocca, 2002, 4).

    3.2 Arhitektura R/3 sistema

    Izraz R/3 (angl. runtime system three) predstavlja komplet poslovnih aplikacij, ki sooblikovane za okolje odjemalec. Strežnik R/3 se je razvil iz prvotnega SAP R/2 sistema, kitemelji na glavnem ra unalniku. R/3 arhitektura omogo a porazdelitev delovnega bremenana številne osebne ra unalnike, ki so medsebojno povezani z omrežjem. SAP R/3 sistem jeoblikovan tako, da porazdeli predstavitev, aplikacijsko logiko in obdelavo podatkov na verazli nih ra unalnikov (Larocca, 2002, 6).

    Slika 7: Trinivojska arhitektura.

    Vir: Larocca (2002, 11)

    Arhitektura R/3 sistema je zgrajena kot trinivojska arhitektura, ki je arhitekturaodjemalec/strežnik, v kateri so programski sistemi strukturirani v treh nivojih: nivouporabniškega vmesnika, nivo poslovne logike in nivo podatkovne baze. Magal in Word(2001, 1-2) pravita, da nam nivo uporabniškega vmesnika pove, kako poteka interakcijamed nami in aplikacijo, nivo poslovne logike nam definira, kaj nam aplikacija omogo a,nivo podatkovne baze nam shrani podatke. V tem primeru centralni ra unalnik gostipodatkovno bazo, ki ji pravimo strežnik podatkovne baze. Za razumevanje delovanja SAPsistema je dovolj, e vemo, da je podatkovna baza prostor, kjer so shranjeni podatki.Aplikacijski strežnik je odgovoren za administrativne funkcije sistema. To obsega

  • 34

    obdelavo v ozadju, tiskanje in obvladovanje zahtev procesa. Dodatni ra unalniki seuporabijo kot predstavitveni sistemi. Ti ra unalniki ali odjemalci, kakor jim pravimo,prikazujejo programsko opremo in zaslone, sicer pa jih imenujemo grafi ni uporabniškivmesniki (angl. Graphical User Interface GUI). (Larocca, 2002, 7). Khan (2002, 32)našteva prednosti uporabe decentralizirane arhitekture SAP. Skalabilnost podpira SAP,neomejeno število uporabnikov, podatkovnih baz, aplikacijskih strežnikov in omogo araznolikost konfiguracije strojne opreme. Skalabilnost omogo a, da z rastjo sistema inpotreb uporabnikov le-to po želji dodajamo. Druge prednosti decentralizirane arhitektureSAP so krajši odzivni as sistema, porazdelitev delovnih bremen in enostavnost uporabesistema.

    Okolje odjemalec/strežnik

    Koncept odjemalec/strežnik je postal zelo priljubljen in predstavlja standard za gradnjokateregakoli tipa ra unalniške komunikacijske arhitekture. Okolje odjemalec/strežnik jetisto okolje, kjer odjemalec (posamezni osebni ra unalnik ali delovna postaja) zahtevainformacije (preko povezave) od strežnika. Komunikacijo in izmenjavo podatkov medtema dvema napravama imenujemo relacija odjemalec/strežnik (Larocca, 2002, 6).

    Okolje odjemalec/strežnik omogo a u inkovito porazdelitev delovnih bremen. Aplikacijskistrežniki delujejo in komunicirajo s podatkovno bazo vzporedno ter tako u inkovitoporazdelijo posamezne aplikativne naloge. Za SAP je zna ilno, da za izvajanje posameznenaloge deluje ve aplikativnih strežnikov. Fleksibilna konfiguracija je naslednja zna ilnostokolja strežnik/odjemalec. Arhitektura odjemalec/strežnik omogo a mnogo na inovinštalacije, distribucije in nadgradnje sistema.

    Skalabilnost arhitekture odjemalec/strežnik

    Pojem skalabilnost navadno uporabljamo v kontekstu metodologij uvajanja ERP rešitev.Skalabilnost metodologije ASAP pomeni, da je primerna za uvajanje v razli no velikapodjetja, da podpira nadgradnjo in optimizacijo ter razli ne tipe projektov uvedbe. Vprimeru odjemalec/strežnik pomeni, da je mogo e pove ati ali prilagoditi zmožnostisistema poslovnim potrebam organizacije (Hernandez, 2002, 41).

    Slika 8: Arhitektura odjemalec/strežnik.

    Vir: Larocca (2002, 7)

  • 35

    3.3 Modularnost

    Eden klju nih SAP-ovih elementov, ki ga lo uje od ostalih aplikacij, je resni noudejanjanje integracije. Ta omogo a povezovanje številnih poslovnih okolij od financ,kadrovskih sistemov, proizvodnje do prodaje in distribucije. Modularnost j