kljuČni dejavniki uspeha uvedbe sistema erp v … · ključne dejavnike uspeha; nato predstavim...
TRANSCRIPT
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.