UNIVERZA V LJUBLJANI

EKONOMSKA FAKULTETA

DIPLOMSKO DELO

KLJUČNI DEJAVNIKI USPEHA UVEDBE SISTEMA ERP

V IZBRANEM PODJETJU

Ljubljana, junij 2016 VESNA PESTOTNIK

IZJAVA O AVTORSTVU

Podpisana Vesna Pestotnik, študentka Ekonomske fakultete Univerze v Ljubljani, avtorica predloženega dela

z naslovom Ključni dejavniki uspeha uvedbe sistema ERP v izbranem podjetju, pripravljenega v sodelovanju

s svetovalcem prof. dr. Petrom Trkmanom.

IZJAVLJAM

1. da sem predloženo delo pripravila samostojno;

2. da je tiskana oblika predloženega dela istovetna njegovi elektronski obliki;

3. da je besedilo predloženega dela jezikovno korektno in tehnično pripravljeno v skladu z Navodili za

izdelavo zaključnih nalog Ekonomske fakultete Univerze v Ljubljani, kar pomeni, da sem poskrbela, da

so dela in mnenja drugih avtorjev oziroma avtoric, ki jih uporabljam oziroma navajam v besedilu,

citirana oziroma povzeta v skladu z Navodili za izdelavo zaključnih nalog Ekonomske fakultete

Univerze v Ljubljani;

4. da se zavedam, da je plagiatorstvo – predstavljanje tujih del (v pisni ali grafični obliki) kot mojih lastnih

– kaznivo po Kazenskem zakoniku Republike Slovenije;

5. da se zavedam posledic, ki bi jih na osnovi predloženega dela dokazano plagiatorstvo lahko predstavljalo

za moj status na Ekonomski fakulteti Univerze v Ljubljani v skladu z relevantnim pravilnikom;

6. da sem pridobila vsa potrebna dovoljenja za uporabo podatkov in avtorskih del v predloženem delu in jih

v njem jasno označila;

7. da sem pri pripravi predloženega dela ravnala v skladu z etičnimi načeli in, kjer je to potrebno, za

raziskavo pridobila soglasje etične komisije;

8. da soglašam, da se elektronska oblika predloženega dela uporabi za preverjanje podobnosti vsebine z

drugimi deli s programsko opremo za preverjanje podobnosti vsebine, ki je povezana s študijskim

informacijskim sistemom članice;

9. da na Univerzo v Ljubljani neodplačno, neizključno, prostorsko in časovno neomejeno prenašam pravico

shranitve predloženega dela v elektronski obliki, pravico reproduciranja ter pravico dajanja predloženega

dela na voljo javnosti na svetovnem spletu preko Repozitorija Univerze v Ljubljani;

10. da hkrati z objavo predloženega dela dovoljujem objavo svojih osebnih podatkov, ki so navedeni v njem

in v tej izjavi.

V Ljubljani, dne 05.06.2016 Podpis študentke:__________________

i

KAZALO

UVOD ........................................................................................................................................ 1

1 SISTEMI ERP ................................................................................................................... 2

1.1 Stanje na trgu ............................................................................................................... 4

1.2 Prednosti, slabosti ali omejitve sistema ERP ............................................................... 7

1.3 Ključni dejavniki uspeha pri uvedbi sistema ERP ....................................................... 9

2 SISTEM MICROSOFT DYNAMICS AX .................................................................... 14

2.1 Splošna predstavitev sistema Microsoft Dynamics AX............................................. 14

2.2 Predstavitev glavnih funkcijskih modulov ................................................................ 16

2.3 Prednosti in slabosti ................................................................................................... 17

3 METODOLOGIJA SURE STEP UVEDBE SISTEMA AX ....................................... 18

3.1 Diagnostika ................................................................................................................ 19

3.2 Analiza ....................................................................................................................... 21

3.3 Načrtovanje ................................................................................................................ 23

3.4 Razvoj ........................................................................................................................ 24

3.5 Uvajanje ..................................................................................................................... 26

3.6 Izvajanje ..................................................................................................................... 28

3.7 Optimizacija in nadgradnja ........................................................................................ 29

4 UVEDBA SISTEMA MICROSOFT DYNAMICS AX V IZBRANEM

PODJETJU ...................................................................................................................... 31

4.1 Metodologija .............................................................................................................. 31

4.2 Predstavitev izbranega podjetja ................................................................................. 33

4.3 Stanje sistema ERP in drugih sistemov ..................................................................... 33

4.4 Potek uvedbe sistema AX .......................................................................................... 35

4.5 Ključni dejavniki za prekinitev projekta .................................................................... 39

SKLEP ..................................................................................................................................... 41

LITERATURA IN VIRI ........................................................................................................ 42

KAZALO SLIK

Slika 1: Svetovni tržni delež prihodkov ponudnikov sistemov ERP leta 2013 ..................... 4

Slika 2: Gartnejev Magic Quadrant za enojne instance produktno usmerjenih sistemov ERP

na srednje velikem trgu ............................................................................................ 6

Slika 3: Prikaz hierarhije plasti znotraj sistema AX ............................................................ 16

Slika 4: Prikaz faze Diagnostika .......................................................................................... 20

Slika 5: Prikaz faze Analiza ................................................................................................ 21

Slika 6: Prikaz faze Načrtovanje ......................................................................................... 23

Slika 7: Prikaz faze Razvoj .................................................................................................. 25

Slika 8: Prikaz faze Uvajanje .............................................................................................. 27

Slika 9: Prikaz faze Izvajanje .............................................................................................. 28

ii

Slika 10: Prikaz faze Optimizacija ...................................................................................... 29

Slika 11: Prikaz faze Nadgradnja ........................................................................................ 31

Slika 12: Stanje vseh informacijskih sistemov v podjetju in vplivi med njimi ................... 34

Slika 13: Hierarhija na najvišji ravni ................................................................................... 36

Slika 14: Proces naročanja blaga in povezave med oddelki ................................................ 38

KAZALO TABEL

Tabela 1: Tipične značilnosti sistemov ERP glede na njihovo naravo ...................................... 3

Tabela 2: Ključni dejavniki uspeha, združeni v tri skupine ..................................................... 10

Tabela 3: Število sestankov in prisotnih ljudi po poslovnih področjih .................................... 32

1

UVOD

Danes podjetja uporabljajo celovite programske rešitve (v nadaljevanju sistem ERP) ne

samo zaradi zajemanja podatkov, ampak tudi zaradi podpore pri izvajanju poslovnih

procesov in pri odločanju ter učinkovitem postavljanju ciljev podjetja. Uspešno uveden

sistem ERP prinese veliko strateških, organizacijskih, managerskih in tehnoloških

prednosti (Zhu, Li, & Wang, 2010, str. 266–267), hkrati pa tudi slabosti, ki so predvsem

tehnične in poslovne (Saatçıoğlu, 2009, str. 695–697).

Trg je zasičen z raznimi ponudniki sistemov ERP. Velikokrat se zgodi, da podjetje, ki bi

želelo uvesti nov sistem ERP, enostavno ne ve, katerega izbrati. Zato se je v takih primerih

najbolje odpraviti do lokalnih ponudnikov in z njimi preveriti skladnosti ponujenih

sistemov ERP. Najbolje je, da se sistem ERP ujema s poslovnimi procesi podjetja, saj so

tako prihranjene investicija za spreminjanje programa in s tem možnosti napak v

programiranju, hkrati pa se poslovni procesi v podjetju ne spreminjajo. Seveda pa v praksi

to ni vedno mogoče. Prenova poslovnih procesov ob uvedbi novega sistema ERP je skoraj

vedno nujna (Ngai, Law, & Wat, 2008, str. 551).

Podjetje se mora uvajanja novega sistema ERP lotiti premišljeno in sistematsko. Sistem se

lahko uvede v celoti naenkrat ali pa se loti uvajanja sistema po modulih. Ne glede na

izbran način uvedbe je pomembno, da se uvedbe loti po metodologiji, ki je standardiziran

proces in je opredeljen na podlagi izkušenj. Prav tako mora podjetje pri uvedbi novega

sistema ERP upoštevati ključne dejavnike uspeha (Ngai et al. 2008, str. 548). Ključni

dejavniki uspeha so področja, kjer se morajo stvari odvijati pravilno, če želimo, da je

projekt uspešen (Trkman, 2010, str. 126). Če niso upoštevani, se stopnja neuspeha oziroma

prekinitve projekta povečuje.

Namen diplomske naloge je preučiti ključne dejavnike uspeha in proces uvedbe sistema

ERP Microsoft Dynamics AX z metodologijo Sure Step v izbranem podjetju.

Metode zbiranja podatkov, uporabljene pri izdelavi diplomske naloge, so pregled

strokovnih člankov in literature na temo uvajanja sistemov ERP in ključnih dejavnikov

uspeha pri uvajanju sistemov ERP, pregled internih gradiv tako izbranega podjetja

(naročnika) kot tudi uvajalca, ki je bil prisoten od vsega začetka ustanovitve izbranega

podjetja, in pregled literature na temo metodologije Sure Step, ki je dostopna na

Microsoftovem portalu za partnerje. V diplomsko delo je vključeno tudi znanje, ki sem ga

pridobila med uvajanjem sistemov v različnih podjetjih in predvsem v izbranem podjetju.

Pri uvedbi sistema ERP v izbranem podjetju sem bila aktivno vključena v fazi analize, v

kateri smo popisovali obstoječe stanje izbranega podjetja. Podala sem tudi rešitve v

primerih, ko se izbrani sistem ni skladal z obstoječimi poslovnimi procesi.

Prvi del diplomske naloge je teoretičen: najprej predstavim sisteme ERP, kakšno je stanje

na trgu, prednosti in slabosti, ki jih prinaša uvedba novega sistema, hkrati pa opišem

2

ključne dejavnike uspeha; nato predstavim sistem Microsoft Dynamics AX, njegovo

zgodovino, glavne funkcijske module ter njegove prednosti in slabosti, potem pa še

metodologijo Sure Step in njene faze. Nato sledi drugi del diplomske naloge, v katerem

teorijo iz prvega dela prenesem na praktični primer in proučim uvedbo sistema AX po

metodologiji Sure Step na izbranem podjetju ter vpliv ključnih dejavnikov uspeha na

prekinitev projekta v fazi razvoja.

1 SISTEMI ERP

Sistemi ERP (angl. enterprise resource planning), kot jih poznamo danes, so se razvili iz

predhodnih sistemov, ki so bili uporabljeni za načrtovanje materialnih potreb proizvodnje

(angl. material requirements planning – v nadaljevanju MRP), in iz MRP II (angl.

manufacturing resources planning), ki so imeli dodane še funkcionalnosti za nabavo,

prodajo in marketing. Pravzaprav končnica ERP izvira direktno iz končnice MRP II, v

kateri angleško besedo manufacturing zamenja angleška beseda enterprise in s tem nakaže,

da sistem zajema celotno podjetje (Uwizeyemungu & Raymond, 2005, str. 70).

Koncept ERP lahko pogledamo s treh strani. Prva in najbolj očitna stran je, da je ERP

proizvod v obliki računalniškega programa. Druga stran je, da je ERP razvojni objekt, v

katerem so združeni vsi procesi in podatki podjetja v celovito povezano strukturo. Tretja

stran pa predstavlja ERP kot ključni element infrastrukture, ki prinaša dodano vrednost v

poslovanju podjetja (Klaus, Rosemann, & Gable, 2000, str. 142).

Definicijo sistema ERP so podali različni avtorji, toda vse imajo zelo podobno razlago.

Morton in Hu (2008, str. 391) pravita, da so sistemi ERP postali hrbtenica informacijskih

infrastruktur v večini srednjih in velikih podjetij po svetu ter so osnovni programski paketi,

ki povezujejo tok informacij skozi celotno poslovanje podjetja. Ngai et al. (2008, str. 548)

pa opredeljujejo, da je ERP generični izraz za velik nabor dejavnosti, ki so podprte z

aplikacijami, katere vsebujejo funkcijske module in omogočajo organizaciji management

svojih virov.

Kot že rečeno, so sistemi ERP sestavljeni iz različnih funkcijskih modulov, spodaj pa so

našteti samo glavni (Kovačič & Bosilj Vukšić, 2005, str. 277):

planiranje,

nabava,

proizvodnja,

management zalog,

vzdrževanje,

finance,

prodaja,

distribucija in

3

management kadrov.

Vsak izmed zgoraj naštetih funkcijskih modulov lahko deluje samostojno, lahko pa se jih

kombinira in tako nastane celovit sistem. Sistem ERP tako povezuje podjetje v celovito

enoto, kar pomeni, da vse njegove oddelke in enote, ne glede na geografsko oddaljenost,

poveže z enim samim računalniškim sistemom, ki ima centralno bazo podatkov (Kovačič

& Bosilj Vukšić, 2005, str. 277). Podatki so tako ažurni in prikazani v realnem času,

najbolj pomembno od vsega pa je, da se zapišejo samo enkrat in se nato po verigi

prenašajo do različnih končnih odjemalcev, ki opravljajo različne poslovne funkcije. S tem

sta omogočeni hitrejše sodelovanje med notranjimi uporabniki in učinkovito povezovanje z

zunanjimi dejavniki, kot so kupci in dobavitelji.

Sistemi ERP so visoko prilagodljivi in pokrivajo potrebe uporabnikov v vseh sektorjih

ekonomije. Obstajajo generične oblike sistemov ERP, ki so usmerjene na veliko različnih

trgov, a vseeno morajo biti primerno nastavljene, predno se začnejo uporabljati. Prednost

generičnih sistemov ERP je, da se lahko spreminjajo in nastavljajo glede na potrebe

podjetja. Drugi sistemi ERP so paketni, ki že vsebujejo procese in funkcionalnosti. Ti so

usmerjeni na specifične trge, kot je avtomobilska industrija ali maloprodaja (Klaus et al.,

2000, str. 142). Te je težje spreminjati, če že, pa to s seboj prinaša dokaj visoke stroške.

Vendar pa uspešen in delujoč sistem ERP pripomore k zmanjšanju operativnih stroškov,

ustvarja bolj natančne načrte povpraševanja, pohitri proizvodnjo in izboljša storitve, to vse

pa dolgoročno vodi k boljšemu poslovanju podjetja (Umble, Haft, & Umble, 2003, str.

244).

Tabela 1: Tipične značilnosti sistemov ERP glede na njihovo naravo

Tip značilnosti Značilnost Pojasnilo

Organizacijska Integracija Povezava med funkcijami in hierarhičnimi nivoji.

Povezava različnih procesov.

Celovitost Širok razpon funkcionalnosti.

Primerne za različne tipe podjetij.

Povezanost z zunanjimi dejavniki.

Poenotenost

(homogenizacija)

Unikatni referenčni podatki.

Enotnost vmesnikov.

Enotnost managementa sistemov.

Procesna usmerjenost Sistemi so prilagojeni glede na poslovne procese za dosego

ciljev.

Najboljše poslovne

prakse

Sistem vključuje najboljše poslovne prakse z različnih

področij.

Tehnična Prilagodljivost Zmožnost sledenja pravilom in spremembam organizacije.

Odprtost Funkcijski moduli (modularnost).

Prenosljivost funkcionalnosti.

Informacijska Realen čas Podatki dostopni v realnem času.

Predvidevanje Poslovni proces se lahko predvidi oz. simulira.

Vir: S. Uwizeyemungu & L. Raymond, Essential characteristics of an ERP system: conceptualization and

operationalization, 2005, str. 71.

4

Tipične značilnosti sistemov ERP glede na njihovo naravo prikazuje Tabela 1.

Organizacijske značilnosti so tiste, ki se nanašajo na uporabo sistema v podjetju, in so tiste,

na katere ima sistem ERP največji vpliv, tako na strukturo podjetja kot tudi poslovno

prakso. Tehnične značilnosti sistema ERP so povezane neposredno s sistemom ERP, kot je

stopnja prilagodljivosti in modularnosti. Informacijske značilnosti pa so povezane s

kakovostjo in uporabnostjo podatkov, ki se zapisujejo v sistem ERP (Uwizeyemungu &

Raymond, 2005, str. 71–72).

Najbolj pomembne značilnosti sistema ERP so integracija, prilagodljivost in procesna

usmerjenost. Uwizeyemungu & Raymond (2005, str. 74) pravita, da so te značilnosti

minimalne zahteve, da se določen program lahko definira kot sistem ERP.

1.1 Stanje na trgu

Na trgu je veliko ponudnikov sistemov ERP, ki so namenjeni tako velikim, srednjim kot

tudi malim podjetjem. Svetovni trg sistemov ERP je v letu 2013 zrastel za 3,8 %, to

pomeni, da so se celotni prihodki iz naslova prodaje sistemov ERP povečali s 24,4

milijarde dolarjev v letu 2012 na 25,4 milijarde dolarjev v letu 2013 (Forbes, 2014).

Slika 1: Svetovni tržni delež prihodkov ponudnikov sistemov ERP leta 2013

Vir: Forbes, Gartner's ERP Market Share Update Shows The Future Of Cloud ERP Is Now, 2014.

Vodilni ponudnik sistemov ERP v letih 2012 in 2013 je podjetje SAP, ki ima v letu 2013

24 % delež celotne prodaje, to je 6,1 milijarde dolarjev prihodkov (Forbes, 2014), kar

prikazuje tudi Slika 1. Zgodovina podjetja SAP sega v leto 1972, ko je v Nemčiji pet

podjetnikov ustanovilo podjetje. V naslednjem letu so na trgu ponudili prvo različico

SAP

Oracle

Sage

Infor Microsoft Kronos

Drugi

5

finančno računovodskega sistema (SAP, 2016). Zadnja različica sistema SAP Business

All-in-One vsebuje vse funkcionalnosti tipičnih sistemov ERP, hkrati pa ima delno dodane

še funkcionalnosti za management odnosov s kupci (angl. Customer Relationship

Management – v nadaljevanju CRM) ter management oskrbovalne verige (angl. Supply

Chain Management – v nadaljevanju SCM). SAP Business All-in-One predstavlja

vizionarski sistem z visoko zmožnostjo izvedbe za velika mednarodna podjetja že danes in

s skrbno vizijo za prihodnost, to lahko vidimo tudi na Sliki 2. SAP Business All-in-One

predstavlja celovit sistem ERP za podjetja iz različnih panog in geografskih področij

(Gartner, 2015).

Naslednji na lestvici ponudnikov sistemov ERP v letu 2013 je podjetje Oracle. S 3,1

milijarde dolarjev prihodkov predstavlja 12 % delež celotne svetovne prodaje sistemov

ERP (Forbes, 2014), to lahko vidimo tudi na Sliki 1. Podjetje Oracle je bilo ustanovljeno

leta 1977 z imenom Software Development Laboratories in se je leta 1982 preimenovalo v

Oracle Systems. Posebnost Oracla je, da ne ponuja celovite programske rešitve, ampak je

sestavljen iz različnih aplikacij, ki jih ponuja pod imenom Oracle E-Business Suite in

Oracle JD Edwards EnterpriseOne. Oraclova finančna aplikacija obsega sredstva, glavno

knjigo, obveznosti, terjatve in banko. Poleg finančne aplikacije Oracle ponuja tudi

aplikacije, ki pokrivajo še področja management projektov, življenjski cikel izdelkov,

proizvodnja in oskrbovalna veriga ter management človeških virov (Oracle, b.l.). Oracle

JD Edwards EnterpriseOne je prilagodljiv, globalen in uporaben sistem za podjetja z

zahtevnimi poslovnimi procesi, kot so proizvodnja, distribucija, projekti, storitve in naftna

industrija (Gartner, 2015). Uporabniku dopušča možnost izbire podatkovne baze,

operacijskega sistema in strojne opreme za izgradnjo in nadgradnjo prilagodljivega sistema

z možnostjo hitrega zagona v živo in s tem doseganje ciljev poslovanja (Grandhi & Chugh,

2012, str. 214). Podjetje Oracle je finančno zelo stabilno in ima dodelano vizijo

prihodnosti, vendar ni čisto v skladu z večinskim povpraševanjem, zato je v Magic

Quadrantu 2015 umeščeno v kvadrantu izzivalcev, kar je prikazano tudi na Sliki 2

(Gartner, 2015).

Večja ponudnika sistemov ERP na trgu sta še podjetji Sage in Infor, vsak s 6 % deležem

prodaje v letu 2013, to je 1,5 milijarde dolarjev prihodkov od prodaje sistemov ERP na

podjetje (Forbes, 2014). Sage ponuja sistem ERP za mala in srednja podjetja, ki so

usmerjena tako produktno kot tudi storitveno. Je britansko podjetje, katerega začetki segajo

v leto 1981. Sistem ERP, ki ga Sage ponuja, se imenuje Sage X3 in podpira nabavo,

prodajo, finance in računovodstvo, management zalog, skladišče ter proizvodnjo (Sage,

b.l.). Gartner (2015) je umestil Sage X3 v kvadrant nišnih igralcev, kar je vidno tudi na

Sliki 2, saj je zmogljiv izdelek, ki s svojo usmeritvijo na produktno usmerjene uporabnike

cilja na industrijo visoke tehnologije in avtomatizacije (Gartner, 2015).

Ameriško podjetje Infor je bilo ustanovljeno leta 2002 z imenom Agilisys, ki je po

prevzemu nemškega podjetja Infor Business Solutions leta 2004 spremenilo ime v Infor

Global Solution (Infor, b.l.). S sistemom ERP Infor LN podjetje cilja predvsem na

6

proizvodna podjetja, industrijo visoke tehnologije in avtomatizacije, hkrati pa tudi na

letalsko ter vojaško industrijo. Podjetje ponuja tudi sistem ERP za modno in tekstilno

industrijo, gostinstvo in kemijsko industrijo, ki se imenuje Infor M3. Podjetje Infor

investira v svoje sisteme ERP in svetovalne storitve, vendar je njihova vizija prihodnosti

omejena predvsem na želje kupcev, zato se oba sistema nahajata v kvadrantu nišnih

igralcev na Sliki 2 (Gartner, 2015).

Slika 2: Gartnejev Magic Quadrant za enojne instance produktno usmerjenih sistemov

ERP na srednje velikem trgu

Vir: Gartner, Magic Quadrant for Single-Instance ERP for Product-Centric Midmarket Companies, 2015.

Na petem mestu po prihodkih iz prodaje sistemov ERP v letu 2013 je podjetje Microsoft,

ki ima 5 % tržni delež, to predstavlja 1,17 milijarde dolarjev prihodkov (Forbes, 2014).

Podjetje Microsoft se je začelo ukvarjati s prodajo sistemov ERP v letu 2001, ko je

prevzelo ameriško podjetje Great Plans Software, ki je imelo v lasti predhodno različico

sistema Microsoft Dynamics GP. Leto pozneje so kupili še dansko podjetje, ki je imelo v

lasti predhodnika današnjega sistema Microsoft Dynamics NAV. Del ponudbe

Microsoftovih sistemov ERP je tudi sistem Microsoft Dynamics AX, ki ga je Gartner

(2015) uvrstil v kvadrant vizionarjev, saj so z razvojem v zadnjem letu naredili velik

7

napredek. Več o sistemu Microsoft Dynamics AX je predstavljeno v nadaljevanju

diplomske naloge.

Med večje ponudnike sistemov ERP spada tudi podjetje Kronos, ki ima 3 % tržni delež.

Preostali manjši ponudniki sistemov ERP, kot so Concur, IBM, Totvs, Yonyou in drugi,

predstavljajo skupaj 44 % tržni delež prihodkov od prodaje sistemov ERP v letu 2013

(Forbes, 2014).

Trg sistemov ERP še vedno raste in se razvija predvsem v dve smeri, in sicer sistemi ERP

nameščeni lokalno (angl. on-premises ERP) in sistemi ERP v oblaku (angl. cloud ERP).

Lokalno nameščeni sistemi ERP bodo do leta 2020 imeli večinski 57 % tržni delež.

Pričakuje pa se, da bodo sistemi ERP v oblaku porasli v letih med 2014 in 2020 na 10 %

tržnega deleža. Napovedano je, da bodo celotni prihodki svetovne prodaje sistemov ERP

dosegli 41,69 milijarde dolarjev do leta 2020, to je 7,2 % rast med letoma 2014 in 2020

(Chaudhari & Ghone, 2015).

Johansson, Alajbegovic, Alexopoulos in Desalermos (2015, str. 4221) so raziskovali

prednosti in slabosti sistemov ERP v oblaku in so ugotovili, da znajo mala in srednja

podjetja (angl. small and medium enterprises – v nadaljevanju SME) zelo dobro izkoristiti

prednosti sistemov ERP v oblaku, medtem ko njihove slabosti sploh ne vplivajo nanje. Na

drugi strani pa imajo velika podjetja pomisleke pri uporabi izključno sistemov ERP v

oblaku, ki so vezani na velikost, zapletenost in specifične poslovne zahteve. Ugotovili so

tudi, da velikim podjetjem najbolj ustrezajo mešani sistemi, v katerih so poslovno kritične

in občutljive aplikacije nameščene lokalno in tako zmanjšujejo pomisleke, hkrati pa

omogočajo izkoristek prednosti sistema ERP v oblaku.

1.2 Prednosti, slabosti ali omejitve sistema ERP

Kot vsi računalniški programi imajo tudi sistemi ERP svoje prednosti in slabosti, ki jih

prinesejo s seboj ob uvedbi. Prednosti lahko razdelimo na operativne, managerske,

strateške, tehnične in organizacijske, slabosti pa so predvsem poslovne in tehnične.

Operativne prednosti se nanašajo na prednosti, ki so pridobljene ob uvedbi sistema ERP na

operativnih procesih, kot so naročanje, management zalog in storitev za stranke (Zhu et al.,

2010, str. 266). Sistemi ERP nadomestijo večino rutinskih in ponavljajočih se nalog ter

združijo različne operativne enote v podjetju. Zaradi njih so poslovni procesi

racionalizirani in s tem izboljšajo učinkovitost v podjetju (Zhu et al., 2010, str. 267) in to

prinaša prednosti, kot so (Saatçıoğlu, 2009, str. 695–697):

znižanje stroškov,

skrajšanje pretočnih časov v poslovnem procesu,

povečana produktivnost,

8

hitrejše zapiranje računovodskih obdobij,

nižje zaloge,

hitrejši informacijski odzivni čas,

izboljšano načrtovanje zalog in naročanje,

izboljšana logistika in pravočasna dostava blaga,

boljša koordinacija in sodelovanje med oddelki,

možnost preoblikovanja neučinkovitih poslovnih funkcij,

hitrejše in bolj natančne transakcije.

Managerske prednosti so predvsem prednosti, ki jih uvedba sistema ERP prinese na

sposobnost odločanja in managementa (Zhu et al., 2010, str. 266). V sistemih ERP se

zbirajo in analizirajo informacije, ki so povezane prek celotnega sistema (Zhu et al., 2010,

str. 267), s tem pa prinašajo prednosti, kot so (Saatçıoğlu, 2009, str. 695–697):

izboljšanje kakovosti in izvajanja vodenja,

boljši management virov,

olajšan in izboljšan proces odločanja in sprejemanja odločitev,

boljši pregled nad denarnim tokom,

izboljšane vodstvene in kontrolne funkcije,

boljša kontrola nad zalogo, informacijami in finančnim stanjem.

Strateške prednosti prinašajo konkurenčne prednosti in omogočajo rast podjetja, tehnične

prednosti pa povečujejo zmožnost informacijskega sistema (Zhu et al., 2010, str. 267).

Strateške in tehnične prednosti lahko povzamem v naslednje (Shang & Seedon, 2000, str.

1012):

možnosti rasti podjetja in poslovanja: povečan obseg transakcij, novi produkti in

storitve, dodatne poslovne enote ali nove funkcije v različnih regijah,

generiranje produktnega ločevanja: zmožnost proizvodnje produktnega ločevanja in

proizvodnja produktov ali storitev po naročilu za posamezne kupce po nižjih cenah,

izboljšani poslovni odnosi s partnerji in kupci,

možnosti povečanja prihodkov,

okrepljena, posodobljena in novejša informacijska oprema oziroma zamenjava stare

opreme za novo,

sledenje trendom.

Organizacijske prednosti so povezane z možnostjo učenja in osebne rasti zaposlenih ter so

(Saatçıoğlu, 2009, str. 695–697):

podpiranje organizacijskih sprememb,

določanje enotne vizije in ciljev podjetja,

preoblikovanje v procesno organizacijo.

9

Treba je poudariti, da je nemogoče realizirati strateške in organizacijske prednosti, ne da bi

bile predhodno realizirane operativne prednosti (Saatçıoğlu, 2009, str. 695).

Kljub temu da imajo sistemi ERP veliko prednosti, imajo tudi nekatere slabosti in

omejitve, ki so povezane z uvedbo. Tehnične omejitve in slabosti (Saatçıoğlu, 2009, str.

695–697) so:

težave pri navajanju na nov sistem,

težavnost in zapletenost uvedbe,

omejitve tehničnih virov znotraj podjetja,

napake ali hrošči (angl. bugs) v programu,

nezadostni postopki za finančno poročanje in poročanje managementu,

slaba funkcionalnost programa,

nezadostna podpora ob uvedbi,

težave v povezovanju z obstoječimi informacijskimi sistemi.

Poslovne omejitve in slabosti (Saatçıoğlu, 2009, str. 695–697) so:

visoki stroški uvedbe,

premalo primerno usposobljenih ljudi,

velika fluktuacija ključnih ljudi,

težave pri ocenjevanju projektnih zahtev,

upiranje novemu s strani uporabnikov,

visoka stopnja sprememb v podjetju, tako v poslovnih procesih kot tudi v programu.

1.3 Ključni dejavniki uspeha pri uvedbi sistema ERP

Uvedba novega sistema ERP v podjetje je zahteven in dolgotrajen proces, s katerim so

povezani tudi visoki stroški. Na projekt uvedbe nenehno prežijo nevarnosti, kot so zamude,

dodatni nepričakovani stroški ali celo prekinitev projekta, ki se jim želimo izogniti (Ngai et

al., 2008, str. 548). Deloitte (b.l.) pravi, da od 55 do 75 % vseh projektov ERP propade.

Zato je treba še pred uvedbo sistema ERP narediti dober načrt projekta in se seznaniti s

ključnimi dejavniki, ki privedejo do uspešnega projekta in so v literaturi znani kot ključni

dejavniki uspeha (angl. critical success factors).

Na splošno so bili ključni dejavniki uspeha (v nadaljevanju KDU) ena izmed prvih in zelo

aktivno raziskana tema. Opredelimo jih lahko na omejeno število področij, in če jih

upoštevamo, bodo posledično zagotovili uspešnost projekta. Strokovna literatura ponuja

dokaj podobne in splošne KDU, ki so v večini združeni v naslednje: podpora najvišjega

poslovodstva, vodenje projekta, projektni sponzor, komunikacija in sodelovanje znotraj

organizacije ter usposabljanje končnih uporabnikov (Trkman, 2010, str. 125).

10

Ngai et al. (2008, str. 551–560) so našteli 18 osnovnih KDU in jih razdelili v tri glavne

skupine, to prikazuje Tabela 2.

Zelo podobne ključne dejavnike uspeha navajata Dezdar in Sulaiman (2009, str. 1045–

1046), ki kot najpomembnejše identificirata podporo najvišjega poslovodstva, management

in ocenjevanje projekta, spremembo poslovnih procesov ter minimalno spremembo

sistema, sestavo, usposobljenost in nadomeščanje projektne skupine ERP, učinkovit

management sprememb in usposabljanje ter izobraževanje uporabnikov.

Tabela 2: Ključni dejavniki uspeha, združeni v tri skupine

Skupina Ključni dejavniki uspeha

Dejavniki na strani uvajalca oziroma

dobavitelja sistema ERP Izbira pravega uvajalca sistema ERP

Dejavniki na strani naročnika oziroma

organizacije, ki uvaja nov sistem ERP

Podpora najvišjega poslovodstva

Vodenje projekta

Cilji, namen in strategija projekta

Nadzor in ocenjevanje projekta

Projektni sponzor

Komunikacija

Projektna skupina

Sprememba poslovnih procesov

Usposabljanje uporabnikov

Upoštevanje obstoječih sistemov

Management podatkov in njihova analiza

Strategija in metodologija uvedbe sistema ERP

Značilnosti podjetja

Izbira sistema ERP

Razvoj, testiranje in reševanje sprotnih problemov

Dejavniki na strani države Lokalna zakonodaja

Lokalna poslovna praksa

Vir: E. W. T. Ngai, C. C. H. Law in F. K. T. Wat, Examining the critical success factors in the adoption of

enterprise resource planning, 2008, str. 560.

Prva skupina KDU so tisti, ki izvirajo s strani uvajalca oziroma dobavitelja sistema ERP:

Izbira pravega uvajalca sistema ERP je ključnega pomena. Naročnik naj bi pred

izbiro uvajalca najprej preveril njegovo finančno stanje, njegove reference, tehnične

zmožnosti in število uspešno izvedenih projektov. Izkušnje uvajalca so izredno

pomembne, saj je tekom preteklih projektov pridobil znanja, ki jih lahko primerno

uporabi na bodočih projektih (Kovačič & Bosilj Vukšić, 2005, str. 295). Poleg vseh

naštetih razlogov, ki vplivajo na izbiro uvajalca, so pomembni tudi kadri oziroma

človeški viri, ki bodo naročniku na razpolago. Če kadri nimajo izkušenj, je tveganje

povezano z njimi visoko, izkušeni kadri pa prinesejo neko zaupanje, da so sposobni

projekt uspešno zaključiti. Pritiski glede rokov pri projektih uvedbe sistemov ERP so

veliki in pomembno je, da se kadri tega zavedajo in tudi tu imajo izkušeni kadri

prednost pred neizkušenimi.

11

Naslednja skupina KDU so dejavniki, ki izvirajo s strani naročnika oziroma organizacije,

ki uvaja nov sistem ERP. V tej skupini so najpomembnejši dejavniki naslednji:

Podpora najvišjega poslovodstva: Če se podjetje odloči, da bo uvedlo nov sistem

ERP v svoje poslovanje, zagotovo ima podporo najvišjega poslovodstva. Vendar sama

podpora ni dovolj, saj mora biti to poslovodstvo aktivno vpleteno v vsak korak projekta

ter mora zagotoviti primerne razmere in vire za njegovo izvedbo. Vloga najvišjega

poslovodstva pri uvedbi sistema ERP vključuje razvoj razumevanja prednosti in

omejitev izbranega sistema ERP, postavljanje dosegljivih rokov za posamezne faze

uvedbe sistema ERP, visoko predanost do uspešne uvedbe sistema ERP in prenos

organizacijske strategije do vseh zaposlenih (Somers & Nelson, 2001, str. 3776).

Uvedba sistema ERP zadeva celotno podjetje, in če poslovodstvo ni predano projektu,

tudi zaposleni ne bodo. Ngai et al. (2008, str. 556) so s svojo raziskavo potrdili, da

različne študije podporo najvišjega poslovodstva uvrščajo na zelo pomembno mesto

med ključnimi dejavni uspeha.

Vodenje projekta, cilji, namen, strategija in nadzor ter ocenjevanje projekta: Zelo

pomemben dejavnik iz druge skupine je tudi vodenje projekta. Kot že rečeno, je

uvedba novega sistema ERP zahteven in dolgotrajen proces. Zato mora projekt

vsebovati jasne cilje, imeti mora namen in strategijo ter časovni načrt (Umble et al.,

2003, str. 245), ki so tudi pomemben ključni dejavnik uspeha. Vodenje projekta vse to

povezuje z načrtovanjem, organizacijo kot tudi vodenjem in kontrolo nad celotno

uvedbo sistema ERP. Z vodenjem projekta je tesno povezan tudi dejavnik nadzora in

ocenjevanja napredka. Na vsakem koraku projekta je treba imeti nadzor nad vsemi

procesi, ki se izvajajo. Napredek je treba oceniti in ugotoviti odstopanja od

načrtovanega, saj vsako odstopanje lahko pripelje do neuspeha.

Projektni sponzor: Naslednji dejavnik druge skupine je projektni sponzor, ki ima

pomembno vlogo pri uvedbi sistema ERP v podjetje in ima hkrati tudi moč pri

odločanju v podjetju, saj razume tako tehnično kot tudi poslovno in organizacijsko

stran pri uvedbi sistema ERP (Somers & Nelson, 2001, str. 3776). Uvedba sistema ERP

zahteva od delavcev podaljševanje delovnega časa in s tem povezan stres. Naloga

projektnega sponzorja pa je, da bodri delavce, jih spodbuja in dviguje delovno moralo

(Ngai et al., 2008, str. 555). Hkrati je projektni sponzor vezni člen med najvišjim

poslovodstvom in projektno skupino (Somers & Nelson, 2001, str. 3776).

Komunikacija in projektna skupina: Pravilna, jasna in učinkovita komunikacija je

naslednji pomemben dejavnik uspeha pri uvedbi sistema ERP. V proces uvedbe

sistema ERP v podjetje je vpleteno veliko ljudi, tako na strani naročnika kot na strani

uvajalca, vendar njihovi individualni cilji včasih niso enaki ciljem podjetja (Kovačič &

Bosilj Vukšić, 2005, str. 296). Zato je pomembno vzpostaviti učinkovito izmenjavo

informacij, da ne pride do nesporazumov (Ngai et al., 2008, str. 551). Hkrati je

pomembno tudi, kakšna projektna skupina se sestavi in da v njej vlada zaupanje. Na

12

strani uvajalca morajo biti vključeni sposobni in kompetentni kadri (Somers & Nelson,

2001, str. 3780), na strani naročnika pa morajo biti vključeni kadri, ki imajo možnost

sprejemanja hitrih in učinkovitih odločitev (Umble et al., 2003, str. 246).

Sprememba poslovnih procesov in usposabljanje uporabnikov: Z uvedbo novega

sistema ERP v podjetje se zaposleni in podjetje soočijo s spremembami tako poslovnih

procesov kot tudi s spremembami, ki jih prinaša nov program. Včasih je lažje in bolj

učinkovito, če spremenimo poslovni proces, kot da bi nadgradili ali spremenili

določeno funkcionalnost sistema ERP, da bi zadovoljili možnost izvajanja utečenega

poslovnega procesa. Spremembe v funkcionalnosti sistema ERP so drage in vsaka

sprememba lahko s seboj pripelje napake v delovanju sistema. Sistem ERP sam po sebi

ne izboljša delovanja podjetja, razen če podjetje sočasno spremeni še poslovne procese

(Somers & Nelson, 2001, str. 3779). Zato je eden izmed pomembnih dejavnikov

uspeha zmožnost spremeniti poslovne procese, da omogočijo učinkovito izrabo

prednosti, ki jih ponuja nov sistem ERP. Hkrati pa je ključno, da se uporabniki naučijo

uporabljati in razumeti logiko programa, to pa dosežemo z izobraževanjem in

usposabljanjem uporabnikov, ki je prav tako pomemben dejavnik uspeha pri uvedbi

sistema ERP. S tem ko so uporabniki seznanjeni, kako program deluje, kakšna je

njegova logika in kako poslovni procesi vplivajo na dogodke, ki se bodo zapisali v

sistem, je uspešnost uvedbe sistema povečana (Ngai et al., 2008, str. 551). Umble et al.

(2003, str. 246) so ugotovili, da če namenimo 10–15 % vseh stroškov uvedbe sistema

ERP za usposabljanje uporabnikov, si zagotovimo 80 % uspešnost projekta uvedbe

sistema ERP.

Upoštevanje obstoječih sistemov: Obstoječi sistemi zajemajo obstoječo informacijsko

tehnologijo (opremo in programe), poslovne procese in organizacijsko strukturo ter

kulturo. Pred uvedbo sistema ERP morajo biti obstoječi sistemi preučeni in z njimi

povezani problem znani, da lahko določimo obseg problemov, s katerimi se lahko

srečamo med uvedbo novega sistema ERP (Al-Mashari, Al-Mudimigh, & Zairi, 2003,

str. 360). Holland in Light (1999, str. 32) sta poudarila, da so obstoječi sistemi

pomembni, saj določajo kompleksnost projekta. Če so obstoječi sistemi na mnogih

tehnoloških platformah, so posledično poslovni procesi bolj zapleteni in to s seboj

prinaša visoke tehnološke in poslovne spremembe (Holland & Light, 1999, str. 32).

Med različnimi sistemi je treba zgraditi vmesnike, to pa je dodaten strošek za naročnika

in zahteva nenehno vzdrževanje (Al-Mashari et al., 2003, str. 360–361). Manj

kompleksni so obstoječi sistemi, večja je verjetnost, da bo prehod na nov sistem ERP

lažji.

Management podatkov: Pravilni in natančni podatki so brezpogojno potrebni, da

sistem ERP pravilno deluje (Umble et al., 2003, str. 246). Podatki iz obstoječih

sistemov morajo biti preverjeni in prevedeni v primerno obliko, ki je podprta v novem

sistemu ERP (Ngai et al., 2008, str. 555). Zato je treba dati velik poudarek pripravi

13

podatkov, ki jih bomo uvozili v nov sistem, saj je od tega odvisna uspešnost uporabe

novega sistema ERP.

Strategija in metodologija uvedbe sistema ERP: Kako uvajamo nov sistem ERP, je

zelo pomembno. Uvajamo ga lahko postopno, glede na funkcionalnosti in module ali

pa uvedemo celoten sistem naenkrat. Holland in Light (1999, str. 32) pravita, da je

slednja precej ambiciozna strategija. Enako velja, kako povežemo obstoječe sisteme, ki

jih podjetje želi obdržati. V rokah poslovodstva je, da se odločijo, ali bo podjetje

spremenilo poslovne procese, da bodo ustrezali sistemu ERP, ali bodo spreminjali

sistem ERP, da bo ustrezal poslovnim procesom (Holland & Light, 1999, str. 32).

Treba je proučiti tako tehnološke kot poslovne prednosti in priporočeno je, da so

medsebojno usklajene (Ngai et al., 2008, str. 555).

Značilnosti podjetja: Značilnosti podjetja, ki uvaja nov sistem ERP, so zelo

pomembne za uspešno uvedbo sistema ERP. Podjetja, ki imajo izkušnje s projektnim

delom in uvajanjem različnih sistemov, bodo lažje prenesle uvedbo sistema ERP kot pa

podjetja, ki takih izkušenj nimajo (Ngai et al., 2008, str. 555).

Izbira sistema ERP: Podjetje naj bi izbralo sistem ERP, ki ustreza njegovi poslovni

praksi in procesom, ki se izvajajo v podjetju. S tem ko podjetje izbere sistem, ki mu

najbolj ustreza, si zagotovi, da ne bo treba spreminjati njegove funkcionalnosti, hkrati

pa olajša uvedbo in nadaljnjo uporabo sistema (Ngai et al., 2008, str. 556).

Razvoj, testiranje in reševanje sprotnih problemov: Uporaba sistema ERP brez

predhodnega testiranja je recept za neuspeh (Al-Mashari et al., 2003, str. 361). Zato je

treba izbran sistem ERP testirati, dodatno razviti funkcionalnosti, ki jih želimo imeti, in

sistem ponovno testirati. Vse napake in probleme, ugotovljene med testiranjem, je treba

pred zagonom v živo odpraviti. Včasih želimo neki obstoječi sistem povezati z novim

sistemom ERP, to prav tako zahteva dodaten razvoj, ponovno testiranje in odpravljanje

napak, ugotovljenih pri testiranju, če želimo, da funkcionalnost deluje tako, kot smo si

zamislili. Predvsem odpravljanje teh sprotnih problemov in napak je pomembno, saj če

niso odpravljeni, je vprašljiva uspešnost uvedbe sistema ERP (Ngai et al., 2008, str.

556).

Zadnja skupina KDU pa so dejavniki, ki izvirajo s strani države.

Lokalne posebnosti: Tukaj mislimo predvsem na to, da sistem ERP podpira lokalne

posebnosti, kot sta lokalna zakonodaja in lokalna poslovna praksa. Če sistem ERP ni

lokaliziran, je možnost njegove uporabe zmanjšana, saj podjetje ne more zagotoviti

delovanja glede na lokalne posebnosti. Če želimo sistem ERP lokalizirati, pa so s tem

povezani dodatni stroški razvoja. Ngai et al. (2008, str. 556) so ugotovili, da je

ključnega pomena, da sistem ERP ustreza in podpira lokalne posebnosti. Ugotovili so

14

še, da so sistemi ERP, ki so razviti na zahodu, po navadi neprimerni za vzhodne trge ter

obratno in da so bili projekti, ki so uporabili take sisteme, večinoma neuspešni.

2 SISTEM MICROSOFT DYNAMICS AX

Zgodovino sistema Microsoft Dynamics AX pretežno povzemam po Dynamics AX

Milestones, Microsoft (2015) in sega 32 let nazaj, ko sta v Kopenhagnu na Danskem brata

Erik in Preben Damgaard leta 1983 razvila aplikacijo Danmax. Poglavitna področja so bila

finančni management, trgovina, management zalog, logistika in proizvodnja.

Julija 1999 je bila izdana tretja pomembnejša verzija Axapta 2.0. V njej so dodali

pomembne novosti, kot so projektni računovodski modul, skladiščni modul in zunanji

OLAP (angl. OnLine Analytical Processing). Prav tako je bila vključena začetna verzija

Axapta objektnega strežnika (angl. Axapta Object Server – v nadaljevanju AOS), ki je

omogočal izvajanje nekaterih operacij na ločenem strežniku.

Četrta pomembnejša izdaja Axapta 2.1 se je zgodila leta 2000, in sicer je bila velika

pridobitev orodje Customer Self-Service, ki je bilo predhodnik današnjega poslovnega

portala (angl. Enterprise Potral). Podjetje Damgaard se je leta 2001 združil z danskim

podjetjem Navision. Izdali so še dve verziji, ki sta se imenovali Navision Damgaar Axapta

2.5 in 3.0.

Poleti 2002 je sledil Microsoftov prevzem; aplikacijo so sprva preimenovali v Microsoft

Business Solution Axapta, nato pa v Microsoft Dynamics AX. Sledili sta dve veliki izdaji,

in sicer oktobra 2002 Axapta 3.0 in marca 2006 Dynamics AX 4.0, ki je s seboj prinesla

osvežen videz.

Dynamics AX 4.0 je bil v celoti razvit pod okriljem Microsofta in je bil prva izdaja, ki se je

skušala vključiti v Microsoftovo tehnologijo: na primer AOS je postal Windows service,

podprta je bila podatkovna izmenjava prek XML in s tem se je pojavil prvi Application

Integration Framework.

Junija 2008 je trg spoznal verzijo Axapta 4.1, ki je bila nato preimenovana v AX 5.0 in

končno v Dynamics AX 2009. Avgusta 2011 pa je bila izdana še verzija Dynamics AX

2012. Trenutna verzija na trgu je Dynamics AX 2012 R3. V zadnjih treh verzijah je bil

poudarek razvoja pri varnosti in pri razvoju grafičnega vmesnika. Februarja 2016 pa so

predstavili prvo verzijo Microsoft Dynamics AX v oblaku.

2.1 Splošna predstavitev sistema Microsoft Dynamics AX

Microsoft Dynamics AX (v nadaljevanju sistem AX) je sistem ERP, namenjen srednje

velikim in večjim podjetjem. Sistem AX je funkcionalno obsežnejši in zahtevnejši od

15

sorodnega sistema Microsoft Dynamics NAV (v nadaljevanju sistem NAV). Primeren je za

uvedbo v večja mednarodna podjetja in združuje celotno poslovanje podjetja v en sam

povezan sistem, ki je vizualno in funkcionalno močno povezan z operacijskim sistemom

Microsoft Windows in delovnimi orodji Microsoft Office. Prednosti sistema AX so

prilagodljivost, enostavna uporaba in učinkovita povezljivost z drugimi informacijskimi

sistemi. Nabor funkcionalnih področij zajema celotno finančno poslovanje, proizvodnjo in

oskrbovalno verigo, prodajo in marketing, management kadrov ter vodenje projektov in

servisne dejavnosti (Microsoft, 2016b). Sistem AX zajema več kot 150.000 namestitev po

vsem svetu, in sicer kar v 110 državah, in je podprt v 45 jezikih (ErpSearch, b.l.).

Sistem AX ima tipično trinivojsko okolje (angl. three-tier environment), ki ga tvorijo

(Microsoft, 2008, str. 2–3):

odjemalec,

podatkovna baza in

strežnik.

Strežnik izvaja logiko poslovanja in omogoča prožnost ter obvladljivost. Podatkovna baza,

ki jo uporablja sistem AX, je strežnik SQL na katerem se vsi podatki shranjujejo v t.i.

tabelah SQL. Odjemalec pa je nameščen na delovna okolja uporabnikov in prestavlja

masko aplikacije (Microsoft, 2008). Odjemalec, podatkovna baza in strežnik tako tvorijo

logične neodvisne nivoje, kajti sistemi ERP po navadi ciljajo na različne tipe ter velikosti

podjetij in morajo biti sposobni obdelati veliko količino podatkov (Klaus et al., 2000, str.

144).

Microsoft je za programiranje sistema AX uporabil metodo, ki ločuje in nadzira

posodobitve ter spremembe na aplikaciji in se imenuje plastenje (angl. layering). Strategija

deljenja optimizacijskih problemov v plasti z deljenjem spremenljivk v več kopij se je

izkazala kot uporabna metoda, ki omogoča uporabno strukturo, zlasti v osnovnih omrežjih

in aplikacijah (Glover & Klingman, 1988, str. 165). Plasti so razporejene po hierarhiji in

omogočajo nadgradnjo novih verzij kljub spremembam na aplikaciji. Ko spreminjamo

objekt na eni plasti, spremenjen objekt povozi vse iste objekte na nižjih nivojih. Obstaja

osem plasti, ki so združene v tri glavne skupine in so prikazane na Sliki 3.

Notranja plast je sistemska plast (angl. System ali SYS layer) in vsebuje standardno

aplikacijo AX. Naslednja je globalna plast (angl. Global Localizaton ali GLS layer), v

kateri so vključene specifične funkcionalnosti držav, ki uporabljajo sistem AX. Nato je še

plast funkcijskih paketov (angl. Hot Fixes ali HFX layer), ki vsebuje popravke, za katere

skrbi Microsoft. Naslednje tri so plasti rešitev (angl. Solution ali SL layer) in so na

razpolago Microsoftovim partnerjem, da lahko razvijajo vertikalne rešitve. Zadnje štiri

plasti pa so na voljo razvijalcem in končnim uporabnikom, ki razvijajo specifične dodelave

za lastne potrebe (Microsoft, 2008, str. 19–20).

16

Slika 3: Prikaz hierarhije plasti znotraj sistema AX

Vir: Microsoft, Microsoft Dynamics AX 2009, Development I (training materials), 2008, str. 19.

Prednost plastne arhitekture je, da originalna koda ostane nespremenjena, kljub temu da so

dodane dodelave in spremembe, saj te potekajo na nižji plasti in ne vplivajo na kodo v višji

plasti (Microsoft, 2008, str. 18).

2.2 Predstavitev glavnih funkcijskih modulov

Sistem AX je sestavljen iz osnovnih in dodatnih modulov. Vsi moduli so med seboj

povezani in omogočajo uporabniku hitro premikanje in pridobivanje informacij iz

celotnega sistema (Microsoft, 2016c).

Osrednji funkcijski modul v sistemu AX se imenuje glavna knjiga in je jedro vseh

finančnih dogodkov. V tem modulu določimo kontni načrt, ki ga poljubno številčimo. Po

navadi se podjetja odločijo za standardni konti načrt, ki velja glede na lokalne

računovodske standarde. V glavni knjigi se zbirajo vsi knjigovodski dogodki podjetja.

Določajo se tudi računovodska obdobja, možno je knjiženje ročnih temeljnic, nastavljajo

se številčne serije, ki se nato uporabljajo v celotnem sistemu. Modul vsebuje finančna

poročila, ki omogočajo enostaven dostop do finančnih podatkov in jih podjetje potrebuje

pri vsakdanjem poslovanju. Uporabniku je omogočeno vnaprej pripraviti poročila, ki jih

nenehno uporablja, kot so bilanca stanja, izkaz poslovnega izida in denarni tok (Microsoft,

2016c).

V modulu obveznosti zbiramo vse nabave in stroške, povezane z dobavitelji. Znotraj tega

modula obstaja šifrant dobaviteljev, na katerih se vodijo vse odprte obveznosti do

posameznega dobavitelja in odprti nalogi, na katerih so prevzete ali pa samo naročene

17

količine za posameznega dobavitelja. Modul omogoča tudi izpis raznih poročil, kot so

odprte obveznosti vseh ali enega dobavitelja in izpis odprtih postavk za usklajevanje stanj,

ter s tem omogoča sproten pregled nad odprtimi, zapadlimi in zaprtimi obveznostmi

(Microsoft, 2016c).

Podoben modul so terjatve, pri katerih imajo uporabniki pregled nad odprtimi, zapadlimi in

zaprtimi terjatvami. Modul omogoča management prodajnih dokumentov, kot sta izdajanje

računov ter kreiranje prodajnih nalogov, in delno ali celotno dobavo glede na željo kupcev.

Modul terjatve prav tako ponuja različna poročila, ki jih lahko izpišemo samo za enega

kupca ali pa za skupino kupcev, torej glede na različne kriterije (Microsoft, 2016c).

V modulu banka je možno nastaviti poljubno število bančnih računov podjetja glede na

različne valute. Na vsaki kartici bančnega računa se tako vodita promet in stanje premikov

denarnih sredstev (Microsoft, 2016c).

Pomemben modul je modul management zalog. V tem modulu sledimo izdelku od

prevzema na zalogo, vse njegove premike po različnih lokacijah, do njegove porabe ali

prodaje. V času, ko je artikel na zalogi, lahko pridobi dodatne odvisne stroške, kot so

skladiščenje, carina ali transportni stroški. Kot vsi moduli v sistemu AX tudi modul

management zalog ponuja izdelavo različnih analiz in poročil, kot je starostna struktura

zalog ali obrat zaloge glede na različne kriterije (Microsoft, 2016c).

Modul stroškovno računovodstvo omogoča spremljanje stroškov glede na dimenzije, kot

so stroškovno mesto, stroškovni nosilec in dodatne dimenzije, ki jih posamezno podjetje

opredeli pri uvedbi sistema. Stroškovno računovodstvo vsebuje vzporedno glavno knjigo,

ki vsebuje že vse knjižene finančne dogodke, na katere nato dodamo vkalkulirane stroške

in prihodke (Microsoft, 2016c).

Vsi moduli so v sistemu AX medsebojno povezani. Tako lahko kupca prek kartice stika

povežemo z dobaviteljem in imamo transparenten pregled, koliko imamo terjatev na eni

strani in koliko obveznosti na drugi strani.

2.3 Prednosti in slabosti

Kot že opisano, ima vsak sistem ERP svoje prednosti in slabosti. Sistem AX ni nobena

izjema. Pomembno je, da si podjetje pred uvedbo sistema ERP določi nabor sistemov in jih

prouči ter se na koncu odloči za tistega, ki mu najbolj ustreza.

Microsoft (2008, str. 2) kot glavne prednosti sistema AX navaja:

poenoteno podatkovno bazo za vsa podjetja v organizaciji,

povezavo med vsemi funkcijskimi moduli,

napredno trinivojsko okolje s plastno arhitekturo,

18

lahkotno dodajanje novih modulov in funkcionalnosti, prilagodljivost,

večvalutno in jezično okolje,

združljivost z drugimi Microsoftovimi orodji (Word, Excel, Outlook),

enkraten vnos podatkov in

nizke stroške vzdrževanja sistema.

Slabosti sistema AX pa lahko povzamem v naslednje:

Sistem je primeren le za večja mednarodna podjetja, saj so stroški uvedbe sistema v

srednja in mala podjetja previsoki.

Njegova obsežnost in zahtevnost je velik izziv za končne uporabnike, saj se lahko v

poplavi vseh funkcij izgubijo oziroma izgubijo pregled nad delovanjem sistema kot

celote.

Končni uporabniki se prevečkrat izobražujejo iz perspektive sistema AX, in ne iz

perspektive poslovnih procesov (PwC, 2012).

Takojšen prenos napak pri vnosu podatkov po celotni verigi poslovnih procesov zaradi

povezave med funkcijskimi moduli.

Glede na to, da se nove funkcionalnosti in moduli z lahkoto dodajajo, pa so stroški,

povezani s tem, relativno visoki, saj je treba vsak dodaten modul oziroma dodelavo

plačati.

3 METODOLOGIJA SURE STEP UVEDBE SISTEMA AX

Za uvajanje projektov in poslovnih sistemov obstajajo različne metode, ki nam lajšajo

uvedbo in nas vodijo skozi pasti različnih faz projekta. Pri uvedbi sistema Microsoft

Dynamics AX nam podjetje Microsoft predlaga uporabo svetovno znane metodologije, ki

se imenuje Microsoft Dynamics Sure Step. Ta metodologija se uporablja pri uvedbi vseh

Microsoftovih sistemov Dynamics, kot so Microsoft Dynamics AX, Microsoft Dynamics

CRM, Microsoft Dynamics NAV itd. V tej diplomski nalogi se bom osredotočila na tisti

del metodologije, ki pomaga pri uvedbi sistema Microsoft Dynamics AX.

Metodologija Sure Step je zelo prilagodljiva in se lahko uporablja ter prilagaja potrebam

naročnika, ki lahko izhaja iz majhnega, srednjega ali velikega podjetja. Vsako podjetje ima

svoje značilnosti in metodologija je dobra iztočnica, kako in kje začeti projekt ter kje nas

čakajo pasti pri različnih fazah projekta (Microsoft, 2016a).

Metodologija Sure Step velja za metodologijo celotnega življenjskega kroga projekta, saj

zajema vse njegove faze in ima šest osnovnih faz, to so (Microsoft, 2016a):

diagnostika,

analiza,

načrtovanje,

19

razvoj,

uvajanje in

izvajanje.

Faza diagnostike obsega predvidevanje rešitev ter ponuja vpogled v zmogljivost

posameznih sistemov, s poudarkom na področju poslovanja podjetja, ki ga zastopa

naročnik. Preostalih pet osnovnih faz predstavlja izvedbo in uvedbo izbranega sistema,

vključno z izvajanjem oziroma uporabljanjem sistema. Vse faze se logično in vsebinsko

dopolnjujejo, zato je pomembno, da se držimo smernic, ki nam jih posamezna faza ponuja

(Microsoft, 2016a).

Metodologija Sure Step vsebuje še dve dodatni fazi, in sicer (Microsoft, 2016a):

optimizacijo in

nadgradnjo.

Obe fazi nastopita po fazi uvedbe in izvajanja sistema. S fazo optimizacije uporabnikom

olajšamo uporabo ter izboljšamo odzivnost in hitrost v poslovanju. Faza nadgradnje pa

pride v poštev, ko so uporabniki že seznanjeni s funkcionalnostjo sistema in želijo nove

funkcionalnosti ali izboljšavo obstoječih (Microsoft, 2016a).

Vse osnovne faze in dodatni fazi metodologije Sure Step so podrobneje predstavljene v

nadaljevanju diplomske naloge in tudi na Slikah od 4 do 11 so prikazane posamezne

aktivnosti, značilne za obravnavano fazo.

3.1 Diagnostika

Po metodologiji Sure Step diagnostika predstavlja prvo fazo pri uvedbi novega sistema.

Diagnostika ima dva osnovna namena. Prvi je, da se naročnik okvirno spozna z vsemi

možnimi sistemi in ugotovi, kateri izmed njih je sploh pravi zanj. Drugi namen pa je, da

uvajalec pridobi okvirno informacijo o obsegu projekta in znanje o ključnih procesih v

podjetju (Microsoft, 2016a).

Diagnostika tako obsega hiter pregled ključnih procesov v podjetju, kot so finance,

prodaja, nabava, logistika in proizvodnja. S tem pridobimo znanje o trenutnem stanju

naročnika, njegovem poslovnem okolju in kritičnih področjih ter možnostih za njihove

izboljšave. Vse te informacije zbiramo, da lahko nato opredelimo obseg projekta, vire in

njihova znanja, časovno obdobje posamezne faze in celotnega projekta ter proračun

(Microsoft, 2016a).

Zelo pomemben dejavnik pri diagnostiki je pridobitev zaupanja naročnika. Uvajalec to

lahko doseže s svojim znanjem o sistemu, ki ga predstavlja. Njegova dodana vrednost pa je

v poznavanju podjetniškega okolja naročnika, njegove organizacije in procesov, situacije,

20

v kateri je, in razumevanju njihovih želja. S predlogami za izboljšavo in s predstavitvijo

pasti že v tej fazi naročniku omogočimo jasen vpogled, kaj ga čaka, če se odloči za uvedbo

novega sistema (Microsoft, 2016a).

Slika 4: Prikaz faze Diagnostika

Vir: Microsoft, Microsoft Dynamics Sure Step, 2016a.

Metodologija Sure Step vsebuje predloge dokumentov, po katerih se ravnata tako naročnik

kot tudi uvajalec. Ti dokumenti omogočajo natančno izvedbo diagnostike in smernic, kako

naj ta poteka.

Rezultat diagnostike je dokument, v katerem so po sklopih grobo opisani ključni procesi

podjetja. V dokumentu so zbrani vsi podatki, ki smo jih pridobili s pogovori z naročnikom

in z lastnim raziskovanjem. Obseg dokumenta je odvisen od velikosti podjetja in kako je

le-to organizirano. Več procesov je vpetih v podjetje, večji je obseg dokumenta diagnostike

(Microsoft, 2016a).

Če se naročnik po prejemu dokumentacije diagnostike odloči za nadaljevanje projekta,

sledi podpis pogodbe in nato se projekt nadaljuje s fazo analize.

Pri projektih se lahko zgodi, da fazo diagnostike v celoti preskočimo. V takem primeru se

v fazi analize izvedejo vsi postopki, ki smo jih preskočili. Po navadi se to zgodi pri

naročniku, ki ga že poznamo in vemo, kakšne so njegove zahteve ter pomanjkljivosti.

21

3.2 Analiza

Analiza predstavlja uradni začetek projekta uvajanja izbranega sistema po metodologiji

Sure Step. Ker sem v diplomski nalogi izbrala uvedbo sistema Microsoft Dynamics AX,

bom od sedaj naprej namesto besedne zveze »izbran sistem« uporabljala besedno zvezo

»sistem AX«.

Slika 5: Prikaz faze Analiza

Vir: Microsoft, Microsoft Dynamics Sure Step, 2016a.

Zelo velik poudarek v fazi analize je na sestavi projektne skupine in da jo sestavljajo pravi

ljudje. Od tega sta odvisni ustreznost in kakovost analize, ki ključno vpliva na nadaljnje

faze in na stroške uvedbe sistema AX.

Analiza se začne z odskočnim sestankom. Na tega se skličeta vodstvo naročnika in

predhodno oblikovana projektna skupina. Projektna skupina izvajalca predstavi ugotovitve,

pridobljene v fazi diagnostike, vizijo projekta, projektni načrt, način vodenja in cilje

projekta. Predstavijo se ključni dejavniki uspeha in prednosti sistema AX. Prav tako se

jasno določijo časovni okvir, mejniki, viri ter njihove vloge, obveznosti in cilji (NPS,

2008a).

22

Na odskočnem sestanku se določita značaj projekta in projektni načrt. Predstavi se dogovor

o načinu dela in kako se medsebojno izmenjujejo vse potrebne informacije. Dokončno se

določi projektna skupina, ki je sestavljena iz projektnega vodje uvajalca, projektnega vodje

naročnika, ključnih uporabnikov posameznih poslovnih področij s strani naročnika in

svetovalcev posameznih poslovnih področij s strani uvajalca. Vendar se brez potrditve

naročnika projekt ne more nadaljevati. Po potrditvi se izvede začetek celotnega projekta.

Faza analize je sestavljena iz dveh delov. Prvi del se osredotoča na pregled trenutnega

stanja in popis vseh ključnih procesov naročnika. V drugem delu pa se ponudijo predlogi

rešitev v skladu s sistemom AX in prenovo ali izboljšavo obstoječih poslovnih procesov.

Glavni cilj analize je izboljšati obstoječe poslovne procese in omogočiti avtomatizacijo

znotraj sistema AX (Microsoft, 2016a).

Analiza se izvaja na delovnih sestankih, na katerih se zberejo ključni uporabniki

posameznih poslovnih področij s strani naročnika in svetovalci posameznih poslovnih

področij s strani uvajalca, po potrebi pa tudi projektni vodji uvajalca in naročnika.

Svetovalci s strani uvajalca vodijo pogovor v smislu vprašanje – odgovor. Metodologija

Sure Step ima že vnaprej pripravljene vprašalnike in predloge rešitev s standardnih

področij, kot so finance, prodaja, nabava itd. Te rešitve so zbrane iz najboljših poslovnih

praks in omogočajo, da se projektna skupina bolj posveti nestandardnim poslovnim

procesom naročnika, kot so skladiščenje in logistika, opominjanje neplačnikov itd.

(Microsoft, 2016a).

Rezultat analize poslovnih procesov je Dokument funkcionalnih zahtev. V njem uvajalec

zapiše in predstavi ugotovitve analize z vseh poslovnih področij naročnika. Sestavljen je iz

določitev obsega projekta, analize poslovnih procesov, predlogov izboljšave poslovnih

procesov in analize vrzeli (angl. Gap-Fit analysis) (Microsoft, 2016a).

Analiza vrzeli določi razlike (angl. Gap) in skladnosti (angl. Fit) med standardnim

sistemom AX ter zahtevami naročnika. Zmanjšuje tveganja ob uvedbi sistema AX, ker

omogoča razumevanje pomembnih dejavnikov pri uvedbi in razvoju, s tem pa omejimo

dvome in spore glede uvedbe in razvoja sistema AX (Microsoft, 2016a).

Tako kot pri diagnostiki je tudi pri analizi velikost dokumenta odvisna od velikosti podjetja

in števila poslovnih procesov. Bolj kompleksno in svojevrstno je poslovanje podjetja, več

poslovnih procesov ima in zato je tudi obseg dokumenta večji.

Naročnik mora dokument funkcionalnih zahtev pregledati. Temu sledi zaključni sestanek,

na katerem izvajalec predstavi glavne ugotovitve analize in predloge za izboljšanje

poslovnih procesov izvajalca. S to predstavitvijo in pregledom dokumenta funkcionalnih

zahtev se mora naročnik strinjati in na koncu mora dokument funkcionalnih zahtev tudi

podpisati. Brez tega se projekt ne more nadaljevati.

23

3.3 Načrtovanje

Po potrditvi dokumenta funkcionalnih zahtev iz faze analize se po metodologiji Sure Step

preide na fazo načrtovanja. Uvajalec je v fazi načrtovanja že dodobra seznanjen s

poslovanjem in zahtevami naročnika. V tej fazi se določi potek nastavitve sistema AX, s

katero se zagotovijo vse tiste zahteve, ki so določene kot skladne v analizi vrzeli. Glavni

cilj faze načrtovanja je določiti, kako uvesti poslovne zahteve, ki so v fazi analize

ugotovljene kot razlike v analizi vrzeli. Tako ovrednotimo ugotovitve iz faze analize, ki so

zapisane v dokumentu funkcionalnih zahtev (Microsoft, 2016a).

Če ima naročnik posebne zahteve, je treba prilagoditi sistem. Prilagoditve so lahko

enostavne spremembe v sistema AX, kot je sprememba poročil ali uporabniškega

vmesnika, ali pa so zahtevnejše, kot je razvoj dodatne funkcionalnosti. Prilagajanje

vključuje tudi možno integracijo z zunanjimi sistemi in prenos podatkov.

Slika 6: Prikaz faze Načrtovanje

Vir: Microsoft, Microsoft Dynamics Sure Step, 2016a.

Če se sistem AX uvaja v podjetje, ki je pred tem že imelo informacijski sistem, je v

naslednji fazi potreben prenos podatkov. Zato se že v fazi načrtovanja napravi dokument,

imenovan Načrt prenosa podatkov (Microsoft, 2016a). V njem se določi, katere podatke je

treba prenesti. Svetovalci uvajalca svetujejo ključnim uporabnikom naročnika, kateri

24

podatki so tisti, ki so vredni prenosa. Po navadi je to priložnost, da se izvede čiščenje

podatkov in se v nov informacijski sistem prenesejo samo prečiščeni ključni podatki.

Svetovalci uvajalca pripravijo Excelove predloge, v katerih opredelijo, kateri podatki so

obvezni in kateri poljubni za osnovne šifrante in otvoritvene temeljnice. Metodologija Sure

Step prav tako vsebuje vse te predloge, s katerimi si uvajalci pomagajo. Naročnik ima

lahko tudi svoje zahteve, zato so te predloge prilagodljive. Predloge naročnik napolni s

podatki iz obstoječih podatkovnih virov. Uvajalec te podatke prenese v nov informacijski

sistem.

Poleg načrta prenosa podatkov v tej fazi nastane še Načrt razvoja funkcionalnosti, ki je

osnova za učinkovito izvedbo nadaljnjih razvojnih aktivnosti (Microsoft, 2016a). Skupaj s

fazo analize in dokumentom funkcionalnih zahtev imata ti dve fazi zelo pomembno vlogo

v nadaljevanju projekta. Če ti fazi nista popolno izvedeni oziroma vključujeta napake, so v

nadaljevanju potrebni popravki, s tem pa so povezani dodatni stroški, dodatne delovne ure

in nezadovoljen naročnik. Načrtovanje se zaključi, ko sta potrjena dokumenta Načrt

prenosa podatkov in Načrt razvoja funkcionalnosti (Microsoft, 2016a).

Treba je poudariti, da faza načrtovanja ne vključuje razvoja. V tej fazi se naredijo zgolj

načrti za prenos podatkov in načrt razvoja funkcionalnosti. Načrt je tista temeljna podlaga,

po kateri se izvaja razvoj od začetka do konca.

3.4 Razvoj

Po metodologiji Sure Step sledi faza razvoja (Microsoft, 2016a). Vse ugotovitve, ki so

zapisane v dokumentih iz faze načrtovanja in se nanašajo na procese za prenos podatkov,

prilagoditev sistema AX ter morebitne integracije z zunanjimi sistemi, se v fazi razvoja

pripravijo ali razvijejo. Poglaviten cilj te faze je načrtovanje projekta iz prejšnje faze

pripeljati do dejanske prilagoditve obstoječih ali razvoja novih funkcionalnosti v sistemu

AX (Microsoft, 2016a).

Kljub vsem predhodnim fazam, v katerih se dodobra seznanimo s stanjem in željami

naročnika, moramo fazo razvoja tudi primerno načrtovati. To je pomembno tako z vidika

stroškov kot tudi z vidika uspešnosti razvoja. Metodologija Sure Step ponuja različna

orodja, ki tako uvajalcu kot tudi naročniku omogočajo primerno časovno načrtovanje pri

razvoju.

Faza razvoja se v prvi vrsti začne s postavitvijo razvojnega okolja. V razvojnem okolju se

vzpostavi tudi testno okolje, v katerem se testirajo prilagoditve obstoječih ali na novo

razvitih funkcionalnosti. Glede na zahtevnost projekta se postavi tudi število testnih okolij

(Microsoft, 2016a). Bolj kot je projekt obsežen in zahteven, več testnih okolij se pripravi. S

tem omogočimo hitrejši razvoj in učinkovitejši razpored virov na izvajalčevi strani ter tako

prihranimo čas in zmanjšamo stroške faze razvoja.

25

Slika 7: Prikaz faze Razvoj

Vir: Microsoft, Microsoft Dynamics Sure Step, 2016a.

Razvojno okolje sistema AX se mora najprej nastaviti. Standardno delovanje sistema AX

je namreč odvisno od mnogih nastavitev. Te se nastavijo glede na naročnikovo željo, a s

pomočjo uvajalca. Vsako poslovno področje ima svoje nastavitve. V postavljeno razvojno

okolje se uvozijo ključni šifranti (kupci, dobavitelji, artikli, konti glavne knjige itd.).

Šifrante pripravijo ključni uporabniki na strani naročnika, s pomočjo ali brez pomoči

uvajalca. Ker v večini primerov naročnik nima dovolj znanja, da bi sam pripravil šifrante,

uvajalec pripravi delavnice glede na poslovna področja (nabava, prodaja, finance itd.) in s

tem omogoči pripravo kvalitetnih šifrantov. Kvalitetni šifranti bistveno olajšajo delo in

uporabo sistema AX.

Pomembna dejavnost v fazi razvoja je tudi prenos podatkov, ki so v obstoječih sistemih v

podjetju. Naročnik pripravi podatke za prenos v sistem AX. Pri tem mu pomaga uvajalec,

saj naročnik nima znanja, kako naj jih pripravi. Zato se tudi za pripravo podatkov, ki jim

rečemo otvoritvena stanja, pripravijo različne delavnice po posameznih poslovnih

področjih. Lahko se izvedejo v sklopu delavnic za šifrante ali povsem ločeno.

Poglaviten cilj faze razvoja je razvoj novih ali prilagoditev obstoječih funkcij, ki so bile

opredeljene v fazi načrtovanja (Microsoft, 2016a). Razvijalci morajo razumeti, kaj

naročnik hoče, in imeti morajo poglobljeno znanje standardnega delovanja sistema AX.

26

Standardni del sistema AX se minimalno spreminja, kajti vse nove funkcije se kličejo iz

standardnega programa.

Drugi cilj pa je testiranje delovanja prilagojenih oziroma na novo razvitih funkcij

(Microsoft, 2016a). Uvajalci in naročniki testirajo razvite in prilagojene funkcije. S tem ko

smo prenesli znane podatke v sistem AX, smo olajšali in omogočili hitrejše učenje in

testiranje sistema AX, saj se je na znanih podatkih lažje učiti kot na izmišljenih. Zato je še

toliko bolj pomembno, da so podatki pravilno preneseni še pred začetkom izobraževanja

končnih uporabnikov naročnika. To velja tako za šifrante kot tudi za otvoritvena stanja.

Otvoritvena stanja se sicer pozneje še lahko dopolnijo, a to se potem izvaja direktno v

produkcijskem okolju sistema AX. Ti podatki so odprte postavke kupcev in dobaviteljev,

stanje glavne knjige po kontih ter stanje zalog. V produkcijsko okolje so preneseni takoj po

zaključku uporabe starega sistema ERP.

Ob koncu faze razvoja nastane Tehnična dokumentacija, v kateri so popisane vse razvojne

podrobnosti, ki so se izvedle v fazi razvoja (Microsoft, 2016a). Faza razvoja je zaključena,

ko so nastavite nastavljene, prenos podatkov in šifrantov zaključen, razvite in dodelane vse

obstoječe ali nove funkcionalnosti in uspešno končana vsa testiranja. Odpravljene morajo

biti vse napake, ki so se pojavile v času testiranja. Ko naročnik potrdi Tehnično

dokumentacijo, potrdi pravilnost delovanja sistema AX in se s tem strinja, da je sistem AX

skladen z njegovimi željami. S tem pa se po metodologiji Sure Step preide v naslednjo

fazo.

3.5 Uvajanje

Celoten razvoj, testiranje novih funkcionalnosti, identificiranje napak in njihova odprava

mora biti do faze uvajanja zaključena. Če smo to dosegli, je nato treba pripraviti

produkcijsko okolje in kopijo produkcijskega okolja, v katerem se izvajajo izobraževanja

in testiranja s strani končnih uporabnikov (Microsoft, 2016a).

Faza uvajanja je faza, v kateri se ves vloženi trud in delo projektnih skupin skozi

predhodne faze združita v uspešen prehod na nov sistem Microsoft Dynamics AX. Tudi to

fazo je treba načrtovati, in sicer kdaj in koliko časa se bo porabilo za ključne dejavnosti

faze uvajanja. Slednje so izobraževanje končnih uporabnikov ter hkratno testiranje sistema

pod obremenitvijo in na koncu prehod na uporabo novega sistema AX oziroma zagon

produkcijskega okolja (Microsoft, 2016a).

Uvajalec v fazi uvajanja na delovne postaje naročnika namesti odjemalca, s katerim končni

uporabniki dostopajo do podatkov v sistemu AX. Število odjemalcev je odvisno od števila

licenc, ki jih je naročnik kupil. Število licenc pa je odvisno od števila sočasnih končnih

uporabnikov.

27

S tem ko imajo končni uporabniki nameščene odjemalce na svojih delovnih postajah, se

lahko izvede dokončno izobraževanje. Izobraževanje je zelo pomembno, kajti končni

uporabniki pridobijo znanja o vsakodnevnih postopkih, ki jih bodo uporabljali pri delu z

novim sistemom AX.

Slika 8: Prikaz faze Uvajanje

Vir: Microsoft, Microsoft Dynamics Sure Step, 2016a.

Najbolj zanesljivo in učinkovito je postopno izobraževanje po fazah. V prvi fazi se izvede

osnovno izobraževanje, pri katerem se uporabniki spoznajo z novim sistemom, njegovim

uporabniškim vmesnikom in s standardnimi funkcijami sistema AX znotraj posameznih

poslovnih procesov (finance, nabava, prodaja itd.), ki jih bodo uporabljali. V drugi fazi pa

se izvedejo podrobna izobraževanja glede na tipe uporabnikov znotraj posameznih

poslovnih procesov. V zadnji fazi izobraževanja se na testnih primerih, ki so vnaprej

pripravljeni, prikažejo utečeni procesi znotraj podjetja (Microsoft, 2016a).

Po končanem izobraževanju imajo končni uporabniki dovolj znanja, da lahko sami testirajo

posamezne funkcionalnosti sistema in po možnosti pregledajo nastavitve, ki zadevajo

posamezno poslovno področje. V tej fazi je nekatere nastavitve še vedno mogoče

prilagoditi in je zato izredno pomembno, da končni uporabniki razumejo njihov pomen.

Faza uvajanja se zaključi z zagonom sistema AX v živo. To pomeni, da so v

produkcijskem okolju vsi pomembni šifranti in otvoritveni podatki in da je sistem AX

28

uveden ter v celoti delujoč. Ključni uporabniki so poučeni, kako uporabljati sistem, in če se

pojavijo operativni problemi, mu jih uvajalec pomaga rešiti. Prvi mesec po zagonu v živo

se naročnik sam odloča o prisotnosti uvajalca. Po navadi je potrebna prisotnost samo

finančnega svetovalca. Sicer pa je potreba po prisotnosti odvisna glede na to, kako je bil

projekt pripravljen: bolje je bil pripravljen, manjša je potreba po prisotnosti uvajalca in

obratno. Vsa odprta vprašanja se rešujejo v naslednji fazi.

3.6 Izvajanje

Slika 9: Prikaz faze Izvajanje

Vir: Microsoft, Microsoft Dynamics Sure Step, 2016a.

Zadnja osnovna faza po metodologiji Sure Step je faza izvajanja. V tej fazi se najprej

razreši vsa odprta vprašanja, ki so se pojavila v predhodni fazi. Po možnosti se izvede še

dodatna izobraževanja končnih uporabnikov, kar pa oceni naročnik sam (Microsoft,

2016a).

Svetovalna skupina uvajalca je končnim uporabnikom v tej fazi ves čas na voljo. Če se

pojavijo težave ali napake v delovanju sistema AX, je njihova naloga, da te težave in

napake v čim krajšem času odpravijo.

29

Skozi celoten projekt uvedbe sistema AX se izoblikujeta dva dokumenta, in sicer tehnični

in uporabniški dokument. V zaključku te faze se ta dva dokumenta predata v podpis

naročniku. Prav to je razlog, da se skliče sestanek vseh projektnih skupin izvajalca in

naročnika. Na tem sestanku se uradno pokomentirajo ključni trenutki projekta, kot so

uspehi in neuspehi, razlogi za zamudo ali predčasno končanje projekta, kje so se pojavile

težave in kako bi jih lahko hitreje odpravili. Namen tega sestanka je ubesediti dejanja skozi

celoten projekt in kaj se lahko pri prihodnjih projektih spremeni, da ne bi prihajalo do

enakih težav. S tem se izognemo morebitnim dodatnim stroškom pri prihodnjih projektih.

Ko naročnik potrdi tehnični in uporabniški dokument, je projekt uradno potrjen in se

uvedba sistema AX tudi uradno zaključi. Sistem AX je uveden in delujoč in končni

uporabniki ga dnevno uporabljajo pri delu.

3.7 Optimizacija in nadgradnja

Osnovnim šestim fazam metodologije Sure Step se lahko dodata dve dodatni fazi:

optimizacija in nadgradnja sistema AX.

Slika 10: Prikaz faze Optimizacija

Vir: Microsoft, Microsoft Dynamics Sure Step, 2016a.

30

Tako faza optimizacije kot tudi faza nadgradnje sta lahko vsaka zase projekt v malem. Če

sta optimizacija ali nadgradnja zahtevni, je smiselno, da se ju lotimo z osnovnimi fazami

metodologije Sure Step. Da ugotovimo, kakšne narave je posamezna optimizacija oziroma

nadgradnja, se najprej lotimo načrtovanja in analize. V načrtovanju opredelimo, kaj želimo

optimizirati ali nadgraditi, v analizi pa, kakšno je stanje. S pridobljenimi podatki

ugotovimo zahtevnost projekta in na podlagi tega se odločimo, ali sta fazi dovolj zahtevni

za nov projekt ali ne (Microsoft, 2016a).

Fazi optimizacije in nadgradnje je prav tako treba načrtovati, in sicer razporeditev virov in

časovni okvir. Glede na predloge, kaj je treba optimizirati ali nadgraditi, se nato vse skupaj

razvije in izvede.

V fazi optimizacije poskušamo izboljšati delovanje sistema AX. Možnosti izboljšave so v

optimizaciji kode, arhitekturni optimizaciji in optimizaciji izvajanja poslovnih procesov

(Microsoft, 2016a). V času uporabe sistema AX končni uporabniki sami ugotovijo, da jim

neki proces vzame veliko časa in da lahko povzroča dodatne stroške. V želji po znižanju

stroškov in skrajšanju časa izvedbe delovnega procesa se obrnejo na ponudnika ali

vzdrževalca sistema AX. S skupnimi močmi se pride do izboljšav in optimizacije na

področjih, ki jih identificirajo.

Vsaka optimizacija je smiselna, če uporabniki s tem prihranijo čas, saj se potem lahko

posvetijo drugim poslovnim procesom, ki so jih zaradi zamudnega predhodnega procesa

prej zanemarjali.

V fazi nadgradnje sistema AX pa dodajamo in razvijamo nove funkcionalnosti v

obstoječem sistemu AX. Vsaka nadgradnja sistema AX pomeni dodaten strošek. Pripraviti

je treba specifikacijo razvoja, narediti časovni načrt in razporediti vire, glede na vse skupaj

se nato razvije nova funkcija. Po razvoju je treba končne uporabnike poučiti o delovanju

nove funkcionalnosti. V ta namen se zopet organizirajo izobraževanja (Microsoft, 2016a).

Vsaka nadgradnja je smiselna, če naročnik na dolgi rok z njo prihrani tako čas kot tudi

stroške ter če ti prihranki presegajo stroške nadgradnje. Z nadgradnjo naročnik želi

povečati svojo učinkovitost in s tem pridobiti konkurenčnost.

Glede na to, da uvedba sistema AX ne pomeni, da se sodelovanje med naročnikom in

uvajalcem zaključi, je smiselno, da se med njima sklene pogodba o vzdrževanju. V njej se

določi, koliko ur svetovanja in razvoja na mesec je vključeno v mesečni znesek. S tem se

njuno sodelovanje nadaljuje in se po možnosti zmanjšujejo stroški naročnika za manjše

optimizacije. Tako imata koristi iz vzdrževalne pogodbe oba – naročnik možnost dodelav,

izvajalec pa obdrži stranko.

31

Slika 11: Prikaz faze Nadgradnja

Vir: Microsoft, Microsoft Dynamics Sure Step, 2016a.

Na koncu vseh opisanih faz je pomembno poudariti, da se projekt lahko zaključi ali

prekine v kateri koli fazi metodologije Sure Step. Vzrokov za zaključek ali prekinitev

projekta je veliko. Kot bomo videli v nadaljevanju diplomske naloge, se je uvedba sistema

AX v izbranem podjetju, ki smo se je lotili po metodologiji Sure Step, končala v fazi

razvoja. To, kaj so bili razlogi in vzroki, ter podrobna analiza pa sledita v nadaljevanju

diplomske naloge.

4 UVEDBA SISTEMA MICROSOFT DYNAMICS AX V IZBRANEM

PODJETJU

4.1 Metodologija

V izbranem podjetju je bil uvajalec kot uvajalec in vzdrževalec sistema NAV prisoten že

od ustanovitve izbranega podjetja. Sama sem bila zaposlena na strani uvajalca, kot

finančna svetovalka in analitičarka najprej za sistem NAV in nato še za sistem AX.

Ko se je izbrano podjetje odločilo, da bo poizkusilo uvesti nov sistem, se je obrnilo na nas,

takratnega vzdrževalca obstoječega sistema NAV, in smo mu predlagali sistem AX. Stekle

32

so vse priprave za začetek projekta. Na uvajalčevi strani smo sestavili projektno skupino, v

kateri so bili vodja projekta, ki je bil hkrati tudi vodja razvoja, ključni svetovalci in

razvijalci, skupaj 12 ljudi. Sočasno se je projektna skupina oblikovala na strani naročnika,

in sicer je pri projektu aktivno sodelovalo 10 ljudi, preostali pa so bili vključeni po potrebi.

Projekt se je začel s fazo diagnostike junija 2008. V enem mesecu smo izvedli 6 sestankov,

na katerih je bilo prisotnih po poslovnih področjih 18 ljudi iz projektne skupine in dodatnih

6 ljudi, ki so bili strokovnjaki na svojem področju na strani naročnika. Uvajalec je nato

pripravil Dokument Diagnostike, ki je bil podpisan konec avgusta 2008.

Faza analize se je začela v začetku leta 2009. V njej so bili organizirani sestanki po

posameznih poslovnih področjih. Tabela 3 prikazuje poslovno področje, koliko sestankov

je bilo sklicanih za posamezno področje in koliko oseb je bilo prisotnih na sestankih.

Tabela 3: Število sestankov in prisotnih ljudi po poslovnih področjih

Poslovno področje Število

sestankov

Prisotnih na

strani uvajalca

Prisotnih na

strani naročnika

Skupaj

prisotnih

Nabava 5 3 3 6

Prodaja 3 2 4 6

Maloprodaja 3 2 3 5

Finance in računovodstvo 5 3 4 7

Blagovno poslovanje 4 3 2 5

Sistemske integracije 2 1 1 2

Skupaj sestankov 22

Nekateri sestanki so se izvajali sočasno, vendar ne vsi, ker so bili na strani uvajalca

svetovalci isti za različna področja. Na teh sestankih smo zbrali vse potrebne informacije o

delovanju obstoječega sistema in njegove glavne pomanjkljivosti. Podatke smo zbirali na

podlagi intervjujev ključnih zaposlenih po posameznih poslovnih področjih.

Sama sem aktivno sodelovala pri popisu poslovnih procesov na področju financ in

računovodstva, delno pa še pri maloprodaji, prodaji in nabavi. Poleg tega sem na podlagi

popisanih procesov podala predloge, kako spremeniti ali dodelati sistem AX v primeru

neskladnosti s poslovnimi procesi na omenjenih področjih.

Faza analize se je zaključila konec oktobra 2009 s podpisom dokumenta Funkcionalne

zahteve. Projekt pa se je prekinil januarja 2010.

Dodatno za diplomsko nalogo sem stopila v stik z vodjo projekta na uvajalčevi strani, da

sem preverila okoliščine za prekinitev projekta in ali so si dogodki sledili tako, kot sem

opisala.

33

4.2 Predstavitev izbranega podjetja

Izbrano podjetje je bilo ustanovljeno leta 2006 in je bilo leta 2014 tretji največji mobilni

operater na slovenskem trgu. Je najhitreje rastoče podjetje v panogi ponudnikov mobilne

telefonije in so imeli leta 2014 12,7 % tržni delež v Sloveniji. Svojo konkurenčno prednost

gradijo na ugodnih cenah, občutnih prihrankih in tehnološko najnaprednejših storitvah.

Število uporabnikov njihovih storitev se je v letu 2014 povzpelo na skoraj 295.000.

Pokritost njihovega mobilnega omrežja v Slovenji dosega 98,90 % prebivalstva. Konec

leta 2014 je imelo izbrano podjetje 192 zaposlenih (Izbrano podjetje, 2014).

Vizija izbranega podjetja je, da postanejo vodilna družba v segmentu mobilne telefonije.

Njihovo poslanstvo temelji na zagotavljanju najvišje ravni kakovosti storitev, pri čemer si

pomagajo s tehnološko naprednostjo. Njihove vrednote so transparentnost in zaupanje do

uporabnika, učinkovitost, kakovost, inovativnost in strokovnost ter odgovoren odnos do

okolja (Izbrano podjetje, 2014).

Leta 2014 je imelo izbrano podjetje (Izbrano podjetje, 2014):

9 lastnih poslovnih enot,

5 prodajnih mest v trgovinah Big Bang,

26 poslovalnic v supermarketih,

37 posredniških poslovalnic in

3 terenske posrednike.

4.3 Stanje sistema ERP in drugih sistemov

Izbrano podjetje uporablja sistem NAV že od začetka poslovanja. Z rastjo podjetja in

obsega poslovanja se zahteve do obstoječega sistema ERP večajo, tako glede obsega kot

tudi glede kompleksnosti novih zahtevkov in povezovanja z drugimi informacijski sistemi.

Podjetje deluje v razvojno intenzivni telekomunikacijski industriji in za nemoteno

delovanje ter nadaljnjo širitev potrebuje močno informacijsko podporo.

Sistem NAV ima osrednje mesto pri povezovanju vseh sistemov v podjetju naročnika, to

prikazuje tudi Slika 12, in vsebuje vse finančne podatke ter analitike pomožnih

knjigovodstev. Najbolj pomembna zunanja sistema sta sistem za sledenje porabe mobilnih

storitev, kot so klici iz mobilnih omrežij ter pošiljanje tekstovnih (v nadaljevanju SMS) in

podatkovnih (v nadaljevanju MMS) sporočil, ki so podlaga za izdajanje računov mobilnim

uporabnikom (na Sliki 12 označen z BRM), in na drugi strani identični sistem, ki pa sledi

porabi fiksnih storitev (na Sliki 12 označen z DCP), kot so klici iz stacionarnih omrežij.

Sistema sta povezana s sistemom NAV, kamor se s pomočjo vmesnikov prenesejo podatki

za izdajanje računov mobilnih in fiksnih storitev. Prav tako pomembna je aplikacija za

management odnosov s kupci (na Sliki 12 označena s CRM), v kateri se shranjujejo nove

34

stranke ter razne interakcije med strankami in izbranim podjetjem. Poleg tega pa se iz

sistema NAV v aplikacijo CRM prenašajo podatki o odprtih postavkah in saldih strank.

MERIDIO je dokumentni sistem, v katerem se shranjujejo vsi vhodni dokumenti, kot so

računi, opomini, pogodbe in druga pošta.

Slika 12: Stanje vseh informacijskih sistemov v podjetju in vplivi med njimi

Vir: NPS, Diagnostika (interno gradivo), 2008b.

MERIDIO s sistemom NAV ni povezan in uporabniki ročno pregledujejo, kateri

dokumenti so potrjeni in kateri ne. V posredniškem portalu se shranjujejo pogodbe strank

mobilnih in fiksnih storitev ter njihove reklamacije. Na portal za sodišča so sporočene

stranke, ki so neplačnice in so prišle v postopek izvršbe. Prav tako se uporabljajo bančni in

drugi portali, v katere dnevno vnašajo plačila ali pa se sporočajo različni podatki, ki jih

zahteva Finančna uprava Republike Slovenije (v nadaljevanju FURS). Portali niso

povezani s centralnim sistemom NAV, ampak se podatki pripravljajo ročno.

Dinamika razvoja, pridobivanje novih strank, razširjanje ponudbe z vedno novimi

storitvami in ne nazadnje potreba po vpogledu in posredovanju analitičnih podatkov

pomenijo vedno večjo obremenitev vseh obstoječih sistemov, vključno s sistemom NAV.

Zaradi tega uporabniki namenjajo vedno več časa za izvedbo potrebnih obdelav, to pa v

prvem koraku pomeni časovni zamik na dnevni ravni, z nadaljnjim širjenjem obsega in

pomanjkanja časa pa tudi zamike na tedenski ali mesečni ravni (NPS, 2008b).

Negativen vpliv na poslovanje imajo ročni posegi oziroma ročne obdelave podatkov.

Ročno delo povečuje nevarnost potencialnih napak, saj so podatki shranjeni v različnih

sistemih, ki niso povezani, in to povzroča časovno potratnost in dodatno obremenitev

človeških virov v izbranem podjetju, ki se s časom lahko le povečuje.

35

Tako so se uporabniki v izbranem podjetju srečevali s problemi, ki so imeli tako

kratkoročno kot tudi dolgoročno vpliv na izbrano podjetje in njegovo učinkovitost. Ključni

problemi so tako bili (NPS, 2008b):

neučinkovite izterjave,

neučinkovita integracija informacijskih sistemov,

ogromno ročnega dela,

oteženo sledenje zalogam in

neustrezen oziroma pomanjkljiv nadzor nad izdajanjem dobropisov.

Izbrano podjetje stremi k vedno bolj podrobnemu evidentiranju in knjiženju podatkov, to

pa povzroča ogromno težav, saj nadaljnja rast števila naročnikov neposredno vpliva na

povečanje obsega podatkov in obdelav ter s tem povečan obseg dela za zaposlene.

Obračuni telekomunikacijskih storitev temeljijo na evidentiranju in vrednotenju vsakega

posameznega poslovnega dogodka (telefonskega klica, SMS/MMS-a, prenosa podatkov,

aneksa itd.). Vsaka SIM-kartica (poslovna entiteta) ima na mesečni ravni tudi več tisoč

poslovnih dogodkov. Evidentirani dogodki so osnova za vsakdanje kontrole v realnem

času, poročanje ter izdelavo ustreznih dokumentov. Pri tem delu je pomembno sodelovanje

vseh poslovnih sistemov v podjetju, to praktično pomeni njihovo integracijo,

sinhronizacijo šifrantov in skupno rabo oziroma deljenje podatkov med vsemi vpetimi

aplikacijami.

4.4 Potek uvedbe sistema AX

Zaradi rasti podjetja in njegovega poslovanja se je podjetje odločilo, da poišče nov sistem,

ki bo omogočil boljši nadzor nad poslovanjem in izvajanjem poslovnih procesov brez

odvečnega ročnega dela. Ker so že uporabljali sistem NAV in imeli ponudnika, ki jim je ta

sistem vzdrževal in dodeloval, so se obrnili nanj. Ponudnik je predlagal sistem AX, vendar

je bilo treba predhodno izvesti vse faze po metodologiji Sure Step.

Najprej je bila opravljena diagnostika, ki je posnela stanje poslovnih procesov nabave,

skladišča in blagovnega poslovanja, prodaje, financ in računovodstva ter sistemskih

integracij (NPS, 2008b). Diagnostika je bila hitra, saj sta imela naročnik in uvajalec že

predhodno dobro poslovno sodelovanje. Dokument Diagnostika je bil potrjen in tako smo

lahko prešli na fazo analize.

V teoretičnem delu diplomske naloge sem omenila, da je analiza temelj za vse nadaljnje

faze pri uvedbi sistema ERP. Zato se je uvajalec analize lotil temeljito. Najprej je bilo treba

sestaviti projektno skupino in jo uradno potrditi. Projektna skupina je bila sestavljena iz

vodje projekta na uvajalčevi strani in vodje projekta na strani naročnika. Skupino so

sestavljali še svetovalci za posamezna poslovna področja na strani uvajalca in ključni

36

uporabniki po posameznih poslovnih področjih na strani naročnika. Zaupanje v projektni

skupini je bilo na visoki stopnji, saj smo že imeli uspešno zgodovino sodelovanja.

Drugi korak v fazi analize je bil podroben pregled obstoječih poslovnih procesov. Podlaga

za to je bil dokument Diagnostika, vendar je poleg poslovnih procesov, omenjenih v

diagnostiki, uvajalec popisal še procese maloprodaje in spletnega poslovanja. Hierarhija na

najvišji ravni je predstavljena na Sliki 13.

Slika 13: Hierarhija na najvišji ravni

Finančno-računovodska funkcija v izbranem podjetju obsega evidentiranje, likvidaturo in

knjiženje prejetih računov, plačilni promet, blagajniško poslovanje, izdajanje izhodnih

računov, evidentiranje in reševanje reklamacij, spremljanje terjatev in obveznosti,

opominjanje neplačnikov, spremljanje blagovnega poslovanja in zalog, knjigovodstvo

osnovnih sredstev in drobnega inventarja, evidentiranje potnih nalogov, načrtovanje

denarnega toka, finančno načrtovanje, poročanje (notranje in zunanje) in kontroling ter

konsolidacijo. Ugotovili smo, da so njihovi ključni problemi v neusklajenih šifrantih med

različnimi informacijskimi sistemi in posledično nepovezanost med njimi. Srečujejo se z

velikimi problemi, kako izterjati terjatve, saj zaradi nepovezanosti sistema NAV in

zunanjih sistemov težko izvajajo opominjanje in posledično izterjave. Podjetje se je

odločilo, da ohrani obstoječe zunanje sisteme za sledenje mobilnih storitev in fiksnih

storitev ter dokumentni sistem, vendar je treba te zunanje sisteme povezati s sistemom AX

in poenotiti šifrante v vseh sistemih (NPS, 2008c).

Nabava v podjetju vključuje naslednje poslovne procese: načrtovanje nabave, sklepanje

pogodb z dobavitelji, naročanje blaga (ki je predstavljeno tudi na Sliki 14), osnovnih

sredstev, drobnega inventarja ter storitev, izvajanje analize nabave in zalog ter poročanje

(notranje in zunanje), pa tudi likvidaturo prejetih faktur. Tudi tu se srečujejo s problemi, ki

so povezani z neenotnimi šifranti, s tokom vhodnih dokumentov (vneseni, potrjeni,

zavrnjeni …), ter nimajo zadostnega pregleda nad obstoječimi zalogami in zato tudi

37

zamujajo pri naročanju novih zalog. Prav tako se srečujejo s problemi za zunanje

poročanje, saj v obstoječem sistemu v šifrantih nimajo pravih parametrov, po katerih bi

lahko samo s klikom prišli do želenih podatkov. Vse to bi jim sistem AX omogočil (NPS,

2008c).

Prodaja se ukvarja z načrtovanjem prodaje, ustvarjanjem novih storitev in proizvodov v

sodelovanju s produktnim marketingom, sklepanjem pogodb s poslovnimi uporabniki ter

izdajanjem računov poslovnim uporabnikom, obdelavo in reševanjem reklamacij,

spremljanjem terjatev, opominjanjem neplačnikov ter poročanjem (notranje in zunanje).

Največ težav imajo pri načrtovanju prodaje, saj se vse skupaj vodi ročno, izven sistema

NAV in zato prihaja do netočnosti. Sistem AX ima podprto načrtovanje in primerjanje z

dejanskim stanjem, tako da bi s tem rešili večino problemov prodaje. Prav tako pa bi lahko,

ker je sistem AX povezan, imeli nemoten dostop do načrtov nabave in tako bi bili njihovi

podatki konsistentni (NPS, 2008c).

Velik del prodaje v podjetju predstavljata tudi maloprodaja in spletno poslovanje.

Vsebujeta naslednje ključne podprocese: naročanje blaga in spremljanje zalog, prodajo in

knjiženje računov, blagajniško poslovanje, reševanje reklamacij, izvajanje inventure,

spremljanje statistike in poročanje. Za izvajanje vseh teh podprocesov se uporablja več,

med seboj ločenih in nepovezanih sistemov, to pa onemogoča tekoče spremljanje realnih

podatkov. Ker je toliko ročnega dela, prihaja do neusklajenosti podatkov med sistemi. V

sistemu AX bi uporabljali maloprodajno vertikalno rešitev LSPOS.NET in naredili

povezavo s spletno trgovino, da ne bi bilo toliko ročnega dela (NPS, 2008c).

Skladiščno in blagovno poslovanje obsega naslednje podprocese: načrtovanje zalog,

nabavo in prevzem zalog, proizvodnjo in pakiranje paketov, prodajo in vračilo trgovskega

blaga, reševanje reklamacij glede dobave blaga, izdajo blaga na konsignacijo in reverz,

interno prodajo, inventuro in usklajevanje zalog. Zaradi povečanega obsega blagovnega in

materialnega poslovanja se je naknadno vpeljala podpora skladiščnemu poslovanju v

sistem NAV, ki ni bilo dokončno izvedena in zaradi tega spremljanje stanja zalog ni

optimalno. Uporabniki niso seznanjeni s celotno funkcionalnostjo skladiščnega modula in

ga zato ne izkoriščajo popolnoma. Prav tako jim poročila ne omogočajo izpisa vseh želenih

podatkov. V sklopu uvajanja novega sistema AX bi uporabnike primerno poučili o uporabi

sistema in jim s tem zagotovili primerno znanje za nadaljnje delo (NPS, 2008c).

Ker se je podjetje odločilo, da bo obdržalo zunanje sisteme za sledenje mobilnih in fiksnih

storitev, dokumentni sistem, aplikacijo CRM, aplikacijo za spletno trgovino, posredniški

portal, na katerem se vnašajo podatki o naročnikih in njihovih pogodbah, ter portal sodišč,

smo morali popisati tudi stanja teh sistemov in kakšen je njihov vpliv na sedanji sistem

ERP. Vse te sisteme bi povezali s centralnim sistemom AX. Vstopna točka za management

odnosov s kupci bi bil sistem Microsoft Dynamics CRM, v katerem bi potem vmesniki

prenesli potrebne podatke do posameznih sistemov (NPS, 2008c).

38

Slika 14: Proces naročanja blaga in povezave med oddelki

39

Na podlagi vseh popisanih poslovnih procesov je uvajalec pripravil Dokument

funkcionalnih zahtev; naročnik ga je pregledal in podpisal. Po metodologiji Sure Step sledi

faza načrtovanja, nato razvoj in uvajanje. Vendar se uvajalec v tem primeru ni držal takega

vrstnega reda. Preskočil je fazo načrtovanja in se posvetil fazi razvoja. Kot opisano v

teoretičnem delu, bi v fazi načrtovanja uvajalec moral ovrednotiti ugotovitve iz analize in

narediti načrt, kako bo uvedel poslovne zahteve, ki so v analizi označene kot neskladne.

Uvajalec je to storil že sproti v fazi analize in s tem skrajšal čas uvedbe sistema AX in

prihranil stroške naročniku.

Hkrati z izvajanjem analize je uvajalec že izvajal faze razvoja. Postavil je razvojno in

testno okolje. Ker je bil uvajalec že do takrat skrbnik sistema NAV, je imel dobro znanje o

tem, kakšne podatke in ključne šifrante je treba prenesti v sistem AX. Sicer je bilo vse

izvedeno v dogovoru z naročnikom, vendar precej hitreje, kot če bi se naše sodelovanje

šele začelo.

Ker sistem AX takrat še ni bil prilagojen lokalnim zahtevam, smo se na uvajalčevi strani

ukvarjali predvsem z lokalizacijo. Prevedli smo celoten sistem AX v slovenski jezik in

razvili smo funkcionalnosti, ki jih slovensko podjetje potrebuje. Tu predvsem mislim na

poročila, ki so lokalno zakonsko zahtevana, kot so poročanje o DDV in intrastatu. Prav

tako smo že razvijali vmesnike, ki bi povezali obstoječe sisteme s sistemom AX, ko se je

projekt ustavil. Glavne razloge, zakaj se je projekt ustavil, bom podala v nadaljevanju

diplomske naloge.

4.5 Ključni dejavniki za prekinitev projekta

V teoretičnem delu diplomske naloge sem opisala ključne dejavnike uspeha, na katere se

bom opirala v tem delu diplomske naloge, v katerem bom iskala glavne razloge, zakaj je

propadel projekt uvedbe sistema AX v izbrano podjetje. Predvsem se bom osredotočila na

tiste ključne dejavnike uspeha, za katere menim, da so imeli vpliv na prekinitev projekta.

Najprej bi pogledala, ali je naročnik izbral pravega uvajalca sistema ERP. Glede na to, da

smo poslovno sodelovali že od začetka ustanovitve izbranega podjetja, se je to zdela

smiselna odločitev. Uvajalec je do tega projekta uvajal samo sisteme NAV in izkušenj z

uvedbami sistemov AX ni imel. Vendar takrat izkušenj s sistemom AX v Sloveniji ni imel

še nihče, tako da naročnik ni imel dosti izbire. Izbrali so uvajalca, ki je imel veliko

izkušenj s projektnim delom in uvajanjem poslovnih sistemov, sočasno pa so se ključni

kadri na strani uvajalca sproti učili novega programa. Sklepam, da izbira uvajalca ni

vplivala na prekinitev projekta, se je pa stopnja tveganja uvedbe sistema ERP povečala

zato, ker se je naročnik prvi v Sloveniji podal v uvedbo sistema AX.

Ker je bil to prvi projekt na sistemu AX v Sloveniji, je bilo treba narediti lokalizacijo

sistema AX, to je tudi eden izmed KDU. Sistem AX je prilagojen srednjeevropskim

40

zahtevam, vendar pa v času uvajanja sistema v izbrano podjetje ni bil preveden v slovenski

jezik in ni imel vključenih lokalnih posebnosti, kot je prilagojeno poročanje za FURS

(DDV in intrastat). Uvajalec je prevedel celoten sistem AX in razvil lokalne specifike, zato

menim, da to ni razlog za prekinitev projekta. Možnost za prekinitev projekta pa so pritiski

na strani uvajalca s strani lastnikov in managementa na projektno skupino, da se projekt

izvede. Če bi bil projekt uspešen, bi Microsoft Slovenija dodelave, povezane z lokalizacijo,

vključil v svojo standardno ponudbo.

Naslednji KDU, ki je vplival na prekinitev projekta, so nejasni cilji in namen projekta.

Zaposleni v izbranem podjetju so bili z obstoječim sistemom NAV zadovoljni kljub temu,

da so imeli ogromno ročnega dela, saj so ga znali uporabljati, novega sistema AX pa niso

poznali in so se ga branili. Sestanki so jim bili odveč in niso imeli jasnega skupnega cilja,

zakaj si želijo oziroma zakaj podjetje želi uvesti nov sistem ERP. Tu poleg nejasnih ciljev

vidim tudi pomanjkanje komunikacije, ki je prav tako eden izmed KDU. Ker cilji niso bili

jasno in učinkovito preneseni do vseh zaposlenih, lahko povzamem, da sta se tu združila

dva KDU, ki sta vplivala na prekinitev projekta.

Sestava projektne skupine je še eden izmed KDU, opisanih v teoretičnem delu diplomske

naloge. Vsi vključeni v projektno skupino so se že poznali in zato so si zaupali. V času

razvoja je projektno skupino zapustil vodja projekta na uvajalčevi strani in skoraj sočasno

je vodja projekta na strani naročnika odšla na predčasen porodniški dopust. Prekinitev

projekta je lahko posledica odhoda dveh ključnih oseb v projektni skupini. Vodja projekta

na naročnikovi strani je bila tudi sponzorka projekta, to je tudi eden izmed opisanih KDU v

teoretičnem delu diplomske naloge. Z njenim odhodom je tako izbrano podjetje izgubilo še

sponzorja in že tako ali tako nizka morala ter motivacija za izvedbo projekta sta padli pod

kritično raven.

Tveganje pri uvedbi sistema AX v izbranem podjetju so bili tudi obstoječi sistemi in

njihovo upoštevanje pri nadaljnjem izvajanju poslovnih procesov. Izbrano podjetje je

želelo obdržati obstoječe sisteme za izdajo računov mobilnih in fiksnih storitev,

dokumentni sistem, aplikacijo CRM, aplikacijo za spletno trgovino, posredniški portal in

portal sodišč. Ti obstoječi zunanji sistemi so bili vir vsega ročnega dela. Ključna izboljšava

bi bila njihova medsebojna povezava v sistemu AX. Ne morem trditi, da so bili obstoječi

sistemi razlog za prekinitev projekta, so pa zagotovo povečevali tveganje projekta, če bi

prišlo do dejanske izvedbe.

Ključni dejavniki uspeha vplivajo na projekt uvedbe sistema ERP in tudi v izbranem

primeru se je to jasno pokazalo. Projekt se je prekinil, kajti v pogodbi o projektu je bilo

navedeno, da mora biti vodja projekta na uvajalčevi strani oseba, ki je zapustila uvajalca.

To je bil pogoj naročnika in tudi glavni razlog za prekinitev projekta. Korist celotnega

projekta je bil popis vseh poslovnih procesov v izbranem podjetju in nastali dokument.

Kljub temu da je bila izvedena celotna lokalizacija sistema AX, je Microsoft Slovenija ni

vključil v standardno ponudbo. Po prekinitvi projekta je izbrano podjetje še naprej

41

uporabljalo obstoječ sistem NAV, uvajalec pa je imel velike likvidnostne težave in kmalu

zatem je lastnik celotno podjetje prodal svojemu glavnemu konkurentu.

SKLEP

Podjetja si v želji po konkurenčni prednosti želijo izboljšav tako v poslovnih procesih kot

tudi informacijski tehnologiji. Sama tehnologija jim konkurenčne prednosti ne zagotavlja,

jim jo pa s prenovo poslovnih procesov in izboljšanjem vizije ter sledenjem strategiji

omogoča (Botta-Genoulaz, Millet, & Grabot 2005, str. 515). Podjetja se prav zato odločajo

za prenovo sistemov ERP in s tem tudi prenovo poslovnih procesov. Uvedba sistemov ERP

je zahteven in dolgotrajen projekt, s katerim so povezani tudi visoki stroški. Vsak

neuspešen projekt prinese podjetju veliko izgubo in nobenih koristi. Statistika pravi, da je

na propad pri uvedbi sistemov ERP obsojenih med 55 in 75 % projektov (Deloitte, b.l.). Na

drugi strani pa uspešno izveden projekt lahko prinese veliko prednosti.

Izbrano podjetje se je odločilo, da bo poizkusilo uvesti sistem AX. Izbira sistema je bila

dokaj smiselna, saj so predhodno že imeli sistem istega ponudnika in bi s tem ohranili

delno investicijo starega sistema. Na začetku projekta je bila sestavljena projektna skupina

in izvedeni so bili sestanki v sklopu analize po metodologiji Sure Step. Uvajalec se

metodologije ni držal čisto po navodilih in je hkrati izvajal fazo analize in fazo razvoja,

fazo načrtovanja pa je preskočil. To se v praksi pogosto dogaja, razlogi pa so različni. Eden

izmed njih so pritiski časovnega okvira projekta, drugi so povezani s stroški projekta.

Vedno pa je treba prisluhniti željam naročnika in njim prilagoditi metodologijo.

Glede na teoretično podlago o ključnih dejavniki uspeha pri uvedbi sistemov ERP lahko

sklepamo, da v izbranem primeru drži, da so ključni dejavniki uspeha resnično pomembni

pri projektu uvedbe sistema ERP. Pri izbranem primeru sem pokazala, da je bilo 6 od

naštetih 18 ključnih dejavnikov uspeha po mnenju Ngai et al. (2008, str. 551–560) povod

za prekinitev projekta uvedbe sistema ERP. Eden glavnih vzrokov za prekinitev projekta je

bila sestava projektne skupine, v kateri sta dve glavni osebi izstopili iz projekta, ena izmed

njih je bila tudi sponzor projekta. Pomembni so bili tudi nejasna komunikacija, nejasni cilji

projekta, zapleteni obstoječi sistemi in v trenutku uvajanja še lokalno neprilagojen sistem.

Omejitve, s katerimi sem se srečevala, so zaupnost projekta uvedbe sistema ERP v izbrano

podjetje in zaupni podatki. Dodatno omejitev vidim pri literaturi, ki se nanaša izključno na

metodologijo uvajanja sistemov ERP v podjetje. Možnost za nadaljnje delo je še bolj

poglobljena raziskava, zakaj in na podlagi katerih ključnih dejavnikov uspeha je projekt

uvedbe sistema AX v izbrano podjetje propadel.

42

LITERATURA IN VIRI

1. Al-Mashari, M., Al-Mudimigh, A., & Zairi, M. (2003). Enterprise resource planning: A

taxonomy of critical factors. European Journal of Operational Research, 146(2), 352–

364.

2. Botta-Genoulaz, V., Millet, P. A., & Grabot, B. (2005). A survey on the recent research

literature on ERP systems. Computers in Industry, 56(6), 510–522.

3. Chaudhari, S., & Ghone, A. (2015). World ERP Software Market – Opportunities and

Forecasts, 2013–2020. Allied Market Research. Najdeno 25. marca 2016 na spletnem

naslovu https://www.alliedmarketresearch.com/ERP-market

4. Deloitte. (b.l.). Your guide to a successful ERP journey: Top 10 change management

challenges for Enterprise Resource Planning implementations. Najdeno 15. aprila 2016

na spletnem naslovu http://www2.deloitte.com/content/dam/Deloitte/pa/Documents/

human-capital/2015-01-Pa-HumanCap-Top10ChallengesERP.pdf

5. Dezdar, S., & Sulaiman, A. (2009). Successful enterprise resource planning

implementation: Taxonomy of critical factors. Industrial Management & Data Systems,

109(8), 1037–1052.

6. ErpSearch. (b.l.). Microsoft Dynamics AX Software Review. Najdeno 25. marca 2016

na spletnem naslovu http://www.erpsearch.com/dynamics-ax-review.php

7. Forbes. (2014). Gartner's ERP Market Share Update Shows The Future Of Cloud ERP

Is Now. Najdeno 22. marca 2016 na spletnem naslovu

http://www.forbes.com/sites/louiscolumbus/2014/05/12/gartners-erp-market-share-

update-shows-the-future-of-cloud-erp-is-now/#5e7b8eee74a1

8. Gartner. (2015). Magic Quadrant for Single-Instance ERP for Product-Centric

Midmarket Companies. Najdeno 30. marca 2016 na spletnem naslovu

https://www.gartner.com/doc/reprints?id=1-2N5QXC1&ct=150916&st=sb

9. Glover, F., & Klingman, D. (1988). Layering strategies for creating exploitable

structure in linear and integer programs. Mathematical Programming, 40(1), 165–181.

10. Grandhi, S., & Chugh, R. (2012). Implementation Strategies for ERP Adoption by

SMEs. Computer Applications for Communication, Networking, and Digital Contents,

350, 210–216.

11. Holland, C. P., & Light, B. (1999). A Critical Success Factors Model For ERP

Implementation. IEEE Computer Society, 16(3), 30–36.

12. Infor. (b.l.). About Infor: Infor Company Overview and Resources. Najdeno 30. marca

2016 na spletnem naslovu http://www.infor.com/company

13. Izbrano podjetje (2014). Letno poročilo izbranega podjetja. Ljubljana: Izbrano

podjetje.

14. Johansson, B., Alajbegovic, A., Alexopoulos, V., & Desalermos, A. (2015). Cloud

ERP Adoption Opportunities and Concerns: The Role of Organizational Size. 48th

Hawaii International Conference on system Sciences (str. 4211–4219). Kauai: IEEE

Computer Society.

43

15. Klaus, H., Rosemann, M., & Gable, G. G. (2000). What is ERP? Information Systems

Frontiers, 2(2), 141–162.

16. Kovačič, A., & Bosilj Vukšić, V. (2015). Management poslovnih procesov – Prenova

in informatizacija poslovanja. Ljubljana: GV Založba.

17. Microsoft. (2008). Microsoft Dynamics AX 2009, Development I (training materials).

Najdeno 20. septembra 2015 na spletnem naslovu https://partner.microsoft.com/en-

us/training

18. Microsoft. (2015). Dynamics AX Milestones. Najdeno 19. septembra 2015 na spletnem

naslovu http://social.technet.microsoft.com/wiki/contents/articles/5812.dynamics-ax-

milestones.aspx

19. Microsoft. (2016a). Microsoft Dynamics Sure Step. Najdeno 20. januarja 2016 na

spletnem naslovu https://mbs.microsoft.com/customersource/northamerica/SureStep

20. Microsoft. (2016b). Microsoft Dynamics ERP. Najdeno 09. marca 2016 na spletnem

naslovu http://www.microsoft.com/sl-si/dynamics/ERP.aspx

21. Microsoft. (2016c). Introduction to Microsoft Dynamics AX functionality. Najdeno 11.

marca 2016 na spletnem naslovu https://msdn.microsoft.com/en-

us/library/aa496588(v=ax.10).aspx

22. Morton, N. A., & Hu, Q. (2008). Implications of the fit between organizational

structure and ERP: A structural contingency theory perspective. International Journal

of Information Management, 28(5), 391–402.

23. Ngai, E. W. T., Law, C. C. H., & Wat, F. K. T. (2008). Examining the critical success

factors in the adoption of enterprise resource planning. Computers in Industry, 59(6),

548–564.

24. NPS d.o.o. (2008a). Sure Step metodologija (interno gradivo). Ljubljana: NPS d.o.o.

25. NPS d.o.o. (2008b). Diagnostika (interno gradivo). Ljubljana: NPS d.o.o.

26. NPS d.o.o. (2008c). Dokument funkcionalnih zahtev (interno gradivo). Ljubljana: NPS

d.o.o.

27. Oracle. (b.l.). Oracle's History: Innovation, Leadership, Results. Najdeno 29. marca

2016 na spletnem naslovu http://www.oracle.com/us/corporate/history/index.html

28. PwC. (2012). The challenges of implementing Microsoft Dynamics AX. PwC internal

survey of AX projects 2010–2012. Najdeno 25. marca 2016 na spletnem naslovu

http://pwc.blogs.com/files/the-challenges-of-implementing-microsoft-dynamics.pdf

29. Saatçıoğlu, Ö. Y. (2009). What determines user satisfaction in ERP projects: benefits,

barriers or risks? Journal of Enterprise Information Management, 22(6), 690–708.

30. Sage. (b.l.). Enterprise Resource Planning (ERP) Software - Sage ERP. Najdeno 30.

marca 2016 na spletnem naslovu http://www.sage.com/us/erp

31. Shang, S., & Seddon, P. B. (2000). A Comprehensive Framework for Classifying the

Benefits of ERP Systems. AMCIS 2000 Proceedings,2(39), 1005–1014.

32. SAP. (b.l.). SAP: A 44-year history of success. Najdeno 25. marca 2016 na spletnem

naslovu http://go.sap.com/corporate/en/company/history.html

44

33. Somers, T., & Nelson, K. (2001). The Impact of Critical Success Factors across the

Stages of Enterprise Resource Planning Implementations. 34th

Hawaii International

Conference on system Sciences (str. 3775–3784). Maui: IEEE Computer Society.

34. Trkman, P. (2010). The critical success factors of business process management.

International Journal of Information Management, 30(2), 125–134.

35. Umble, E. J., Haft, R. R., & Umble, M. M. (2003). Enterprise resource planning:

Implementation procedures and critical success factors. European Journal of

Operational Research, 146(2), 241–257.

36. Uwizeyemungu, S., & Raymond, L. (2005). Essential characteristics of an ERP system:

conceptualization and operationalization. Journal of Information and Organizational

Science, 29(2), 69–81.

37. Zhu, Y., Li, Y., & Wang, J. (2010). What leads to post-implementation success of

ERP? An empirical study of the Chinese retail industry. International Journal of

Information Management, 30(3), 265–276.