uvedba celovite programske reŠitve microsoft … · ( c rm ) administracija, ( ] v oµ Î ,...

Diplomsko delo visokošolskega strokovnega študija Organizacija in management informacijskih sistemov

UVEDBA CELOVITE PROGRAMSKE REŠITVE MICROSOFT DYNAMICS NAV2013R2

Mentor: viš. pred. dr. Gregor Lenart Kandidat: Žiga Jamnik

Kranj, maj 2017

ZAHVALA Rad bi se zahvalil dr. Gregor Lenartu za pomoč pri pisanju in iskanju podatkov za mojo diplomsko nalogo. Posebej bi se rad zahvalil za moralno pomoč partnerki Nastji Černivec, moji ter njeni družini. Hvala tudi Tini Vehovec za lektoriranje diplomskega dela.

POVZETEK

V diplomskem delu so predstavljene celovite programske rešitve, njihovi začetki in njihove značilnosti. Predstavljen je projekt uvedbe celovite programske rešitve v organizacijo, na kaj mora biti ta pozorna in kritični dejavniki uspeha uvedbe. V praktičnem delu diplome je predstavljeno podjetje, v katerega je bila uvedena programska rešitev Microsoft Dynamics Nav, podrobnejši pregled izvoza iz EXIM rešitve in uvoz podatkov v MS Dynamics Nav, ki je ključen za uspešno uvedbo. Naredili smo analizo obstoječega stanja in prikazali, kaj organizacija pridobi z uvedbo. Na koncu diplomske naloge smo analizirali mnenja prodajnega referenta in regionalnega vodje prodajnih področij o novo uvedeni ERP rešitvi.

KLJUČNE BESEDE:

- Celovite programske rešitve - Poslovni informacijski sistem - Microsoft Dynamics Nav - Uvedba - Uvoz podatkov

ABSTRACT Diploma thesis presents enterprise resource planning solutions, their beginnings, features and their global market. We also present important characteristics of ERP implementation and point out success factors for implementation of enterprise resource planning solutions. Practical part of diploma thesis introduced examined organisation in which Microsoft Dynamics Nav is being implemented. Data migration process from old ERP system Exim to a new ERP system Microsoft Dynamics Nav is really important for successful implementation. An analysis of current state and the future state is presented along with benefits which the organisation gets when implementing new ERP system. At the end of diploma thesis we analyse opinions of two business users from sales department about newly implemented ERP system.

KEYWORDS:

- Enterprise Resource Planing - Business Information System - Microsoft Dynamics NAV - Implementation - Data import

KAZALO 1. UVOD ................................................................................................................. 1

1.1. PREDSTAVITEV PROBLEMA .......................................................................... 1

1.2. METODOLOGIJA .......................................................................................... 1

1.3. OMEJITEV DIPLOMSKEGA DELA ................................................................... 1

2. CELOVITE PROGRAMSKE REŠITVE .......................................................... 2

2.1. ZAČETKI CELOVITIH PROGRAMSKIH REŠITEV ............................................... 4

2.2. ZNAČILNOSTI CELOVITIH PROGRAMSKIH REŠITEV ....................................... 5

2.3. TRG CELOVITIH PROGRAMSKIH REŠITEV ..................................................... 5

2.4. UVAJANJE CELOVITIH PROGRAMSKIH REŠITEV ............................................ 7

2.5. KORAKI UVEDBE CELOVITE PROGRAMSKE REŠITVE ...................................... 9

2.5.1. PRIPRAVLJALNA FAZA ......................................................................... 9

2.5.2. FAZA PRIPRAVE SISTEMA .................................................................. 12

2.5.3. FAZA UVAJANJA IN TESTIRANJA ....................................................... 12

2.5.4. SKLEPNA FAZA PROJEKTA ................................................................ 12

2.6. KRITIČNI DEJAVNIKI USPEHA IMPLEMENTACIJE ......................................... 12

2.6.1. DEJAVNIKI S STRANI REŠITVE ERP .................................................. 13

2.6.2. DEJAVNIKI S STRANI DOBAVITELJA OZIROMA UVAJALCA ............. 13

2.6.3. DEJAVNIKI ORGANIZACIJE ................................................................. 14

2.6.4. DEJAVNIKI VODENJA PROJEKTA ...................................................... 14

3. PREDSTAVITEV PODJETJA ............................................................................ 15

4. MICROSOFT DYNAMICS NAV ....................................................................... 16

5. ANALIZA OBSTOJEČEGA STANJA .................................................................. 18

5.1. OBSTOJEČE STANJE .................................................................................. 19

5.1.1. USTVARJANJE PRODAJNEGA NAROČILA V EXIMU ..................... 21

5.2. PREDLAGANA REŠITEV .............................................................................. 29

5.2.1. USTVARJANJE PRODAJNEGA NAROČILA V MICROSOFT DYNAMICS NAVU .......................................................................................... 33

6. PROJEKT UVEDBE CELOVITE PROGRAMSKE REŠITVE V PODJETJE ................. 41

6.1. MIGRACIJA PODATKOV .............................................................................. 46

6.2. MIGRACIJA POSLOVNIH PARTNERJEV ........................................................ 47

6.3. MIGRACIJA PLAČILNIH POGOJEV ............................................................... 56

6.4. UVEDBA AGENTURE .................................................................................. 63

7. VREDNOTENJE UVEDBE CELOVITE PROGRAMSKE REŠITVE ............................ 64

7.1. KOMENTARJI UPORABNIKOV ..................................................................... 64

7.2. MOŽNOSTI NADALJNJEGA RAZVOJA .......................................................... 64

8. PRIPOROČILA ............................................................................................... 65

8.1. SKLEP ....................................................................................................... 65

LITERATURA IN VIRI ................................................................................................ 66

KAZALO SLIK ........................................................................................................... 68

KRATICE IN AKRONIMI ............................................................................................. 69

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Žiga Jamnik: Uvedba celovite programske rešitve Microsoft Dynamics Nav2013R2 stran 1

1. UVOD

1.1. PREDSTAVITEV PROBLEMA Diplomska naloga proučuje primer podjetja X (v nadaljevanju podjetje), ki mu konec leta 2017 poteče sistemska podpora za trenutno celovito programsko rešitev Exim. Odločili so se, da ga nadomestijo z novo programsko rešitvijo, in sicer z Microsoft Dynamics NAV2013R2. Trenutno uporabljajo Exim kot njihov glavni program, ki pokriva področje prodaje nabave, tehnologije in vzdrževanja. Poleg Exima uporabljajo še Microsoft Excel za potrebe planiranja proizvodnje, planiranja rezanja, vodenje reklamacij in vračil. Espro, ki pokriva procese skladiščenja surovin, gotovih in negotovih izdelkov, QM-DOC uporabljajo za vodenje dokumentov in še nekaj drugih programov, kar ovira delovanje organizacije. Za sistemsko podporo Exima so imeli zaposlenega informatika, ki pa se je konec leta 2014 upokojil. Ker je to star program (deluje namreč še v MS Dosu), informatikov za podporo ni več, tako da je podjetje primorano menjati celovito programsko rešitev. Prvotno naj bi bila rešitev Microsoft Dynamics NAV2013R2 vpeljana že v letu 2014 in bi z njo uspešno začeli poslovanje v letu 2015, vendar zaradi spleta okoliščin to ni bilo mogoče.

1.2. METODOLOGIJA Pri diplomski nalogi smo uporabljali metodo študije primera in primerjalno analizo informacijske tehnologije. V študiji primera smo opisali potek projekta uvajanja celovite programske rešitve v proučevanem podjetju. Pri pisanju diplomske naloge smo si pomagali z domačimi in tujimi viri iz strokovne literature.

1.3. OMEJITEV DIPLOMSKEGA DELA Diplomska naloga proučuje primer uvedbe celovite programske rešitve v resničnem podjetju, ki ne želi biti imenovano, zato se v diplomi uporablja izraz podjetje X ali krajše podjetje. Sprva je bila diplomska naloga snovana kot opis uvedbe celotnega sistema v podjetje, vendar se je kasneje cel projekt uvedbe izbrane ERP rešitve ustavil oziroma precej upočasnil. Diplomsko delo bo zato osredotočeno na prodajni proces. Podrobno bo prikazano trenutno stanje prodajnega procesa in kasneje prodajni proces po uvedbi nove celovite programske rešitve. Zavedati se moramo, da celovita programska rešitev ne sme biti prezahtevna, saj jo bodo uporabljali ljudje, ki po izobrazbi niso informatiki, verjetno pa tudi starejši ljudje, ki niso toliko vajeni informacijske tehnologije.



2. CELOVITE PROGRAMSKE REŠITVE Rešitev ERP (ERP – angl. Enterprise Resource Planning) lahko opredelimo kot celovito povezan in na poslovnem modelu organizacije temelječ sistem, ki ob uporabi sodobne informacijske tehnologije vsem poslovnim procesom, tako same organizacije kot tudi z njo povezanih poslovnih partnerjev, zagotavlja optimalne možnosti načrtovanja, razporejanja virov in ustvarjanja dodatne vrednosti (Kovačič in Bosilj, 2005). ERP omogoča celosten pregled na vse procese v podjetju v realnem času, uporablja skupno podatkovno bazo in jih vzdržuje s sistemom za upravljanje podatkovnih baz. S pomočjo le-tega imamo neprestan pregled nad viri podjetij, kot so denar, surovine, zmogljivosti proizvodnje in statusa poslovnih obveznosti: nalogi, naročilnice in izplačane plače. Enterprise system software je programska oprema, ki omogoča podjetju, da s pomočjo enega orodja upravlja vse procese v podjetju, torej: nabavo, prodajo, finance, planiranje, proizvodnjo, skladiščni sistem in kadrovski oddelek. Na Sliki 1 vidimo skupno, centralno bazo za vse oddelke. Različni oddelki črpajo podatke iz te baze in so tako podatki enaki za vse oddelke. Še ena prednost je, da so podatki vedno ažurni za vse (Dahlén in Elfsson, 1999).



Centralna baza

podatkov

Moduli za izdelavo različnih poročil

Prodajni in distribucijski

moduli

Storitveni moduli

Moduli za upravljanje zalog

in nabaveModuli za

upravljanje s človeškimi viri

Proizvodni moduli

Finančni moduli

Prodajna služba,

marketing, upravljanje s strankami

(CRM)

Administracija, finančna služba,

delavci

Kadrovska služba

Vodstvo, lastniki

Kupci Dobavitelji

Slika 1: Diagram ERP modulov



2.1. ZAČETKI CELOVITIH PROGRAMSKIH REŠITEV Sami začetki celovitih programskih rešitev sistemov segajo že v leto 1990, ko je The Gartner Group prvič uporabil kratico ERP. Prve programske rešitve so bile sistemi točk ponovnega naročanja (ROP), namenjene kontroliranju in upravljanju zalog, ki so bile vezane na točno določenega uporabnika. Kasneje so ustvarili še sistem za načrtovanje proizvodnih materialov (MRP). MRP jim je omogočal izračun količine materialov, ki so bili potrebni za uresničitev njihovega proizvodnega načrta (Enterprise resource planning, 2016). MRP rešitve so računalniško podprti informacijski sistemi, ki temeljijo na tehnikah, ki uporabljajo podatke kosovnic, zalog in glavni proizvodni načrt za izračun potreb po materialih. Izračun količin materiala je odvisen od podatkov o načrtovanih količinah proizvodnje iz glavnega proizvodnega načrta. Količina potrebnih sestavnih sklopov in materialov za izdelavo izdelkov se določi iz podatkov kosovnic, pri tem se upošteva časovne roke. S t. i. eksplozijo kosovnic in upoštevanjem obstoječih zalog, že naročenih količin ter z zamikanjem ustreznih začetnih časov posameznih proizvodnih operacij dosežemo časovno naravnano načrtovanje materialov (Jeromel, 2010). MRP II je računalniško podprt informacijski sistem za načrtovanje proizvodnih materialov. Omogočajo operativno načrtovanje proizvodne količine in vrednosti ter podpirajo simulacije za potrebe odločanja v najbolj dodelanih izvedbah. So naslednik MRP rešitev v zaprti zanki. Od MRP se razlikujejo v tem, da omogočajo načrtovanje proizvodnih kapacitet in zbiranje informacij o stanju proizvodnega procesa ter uvajajo principe povratnih zank za opozarjanje nezmogljivosti materialov (Jeromel, 2010). ERP sistemi so se močno razširili v letu 1990. Ker je bila v letu 2000 uvedena nova denarna valuta, so se obstoječi sistemi soočali z motnjami v delovanju. To so številna podjetja izkoristila kot priložnost zamenjave starih sistemov z ERP. Podjetja so se sprva osredotočala na avtomatizacijo funkcij zalednih področij, ki niso bile neposredno povezane s strankami in javnostjo. V upravljanje odnosov, trgovanje s strankami, e-upravo, e-finance in e-telekomunikacije pa so sistem vpeljali kasneje, ko je bil ta že preizkušen. ERP II pa je bil prvič omenjen v članku Gartner z naslovom ERP is Dead-Long Live ERP II, kjer opisuje spletno programsko opremo, ki v realnem času omogoča dostop do sistemov tako zaposlenim kot tudi partnerjem. Razvijalci se trudijo predvsem povezati mobilne naprave z ERP-jem, tako kot tudi ostalim poslovnim aplikacijam. ERP tako zajema več funkcij in vlog, med drugim tudi odločanje, preglednost in globalizacijo.



2.2. ZNAČILNOSTI CELOVITIH PROGRAMSKIH REŠITEV ERP sistemi imajo naslednje lastnosti (Dajčbauer, 2009):

- so gotove programske rešitve,

- skladno s konceptom odjemalec/strežnik,

- obdelujejo večino transakcij v podjetju,

- uporabljajo podatkovno bazo na ravni organizacije, v kateri je vsak

podatek zapisan samo enkrat,

- omogočajo dostop v realnem času.

Omogoča implementacijo le tistih modulov, ki so potrebni za nemoteno delovanje podjetja.

2.3. TRG CELOVITIH PROGRAMSKIH REŠITEV Slika 2 prikazuje globalne tržne deleže celovitih programskih rešitev. Na trgu obstaja kar nekaj ponudnikov ERP rešitev, najbolj priljubljenih 10 pa je Yonyou z 1 % trga, Totvs, IBM, Concur z vsak po 2 % trga, Kronos s 3 % trga, Microsoft s 5 % trga, Infor in Sage s 6 % trga, Oracle z 12 % trga in pa vodilni SAP s 24 % deležem trga. Skupaj pokrivajo kar 63 % trga, to pomeni, da imajo ostali ponudniki ERP sistemov majhen odstotek (Gartner's ERP Market Share Update Shows The Future Of Cloud ERP Is Now, 2016).



Slika 2: Grafični prikaz deleža vrednosti ERP ponudnikov



Leta 2013 so zabeležili, da svetovni trg EPR rešitev dosega vrednost 25,4 milijarde USD. V samo enem letu je ta vrednost zrastla za 3,8 %.

Vse bolj pa se pojavlja ideja, da bi ERP sisteme preselili v t. i. oblak. Do datotek, ki jih shranimo v oblak, lahko dostopamo kjerkoli in kadarkoli, potrebno je le, da imamo internetno povezavo. Smiselna razloga, zakaj izbrati storitve v oblaku sta visoka hitrost interakcije in vse večja količina podatkov. Spletna stran podjetja Gartner celo napoveduje, da naj bi do leta 2018 vsaj 30 % podjetij, ki se ukvarjajo s storitvami, preselilo ERP aplikacije v oblak. Predvidevajo, da bodo ti hibridni ERP sistemi, kot jih je poimenoval Gartner, že nekaj osnovnega v roku pet let. Sprva naj bi ti hibridni ERP sistemi zadovoljevali potrebe financ in proizvodnje. Dolgoročno pa naj bi v oblak selili več modulov sistemov in tako pokrili vse oddelke v podjetju, tako kot jih sedaj pokrivajo današnji ERP sistemi. V zadnjih letih je tudi v Sloveniji opaziti razširjeno uvajanje celovitih programskih rešitev. Pri tem so še posebej intenzivne velike organizacije. Vse večji interes pa je zaznati tudi pri srednjih in malih organizacijah. Organizacije skušajo namreč vse bolj zmanjševati stroške poslovanja. Poleg stalnih razvojnih aktivnosti in inovacij, visoko kakovostnih izdelkov in storitev ter dobrega odnosa s poslovnimi partnerji in strankami predstavlja zmanjševanje stroškov poslovanja z uvajanjem sodobnih programskih rešitev pomemben element pri doseganju konkurenčnosti na trgu (Lenart, Pucihar, Sudzina, 2009). Slovenskih ponudnikov ERP rešitev je precej, vendar imajo težko konkurenco. Večji evropski ali svetovni ponudniki v Sloveniji nimajo odprtih podružnic, zato obstaja kar nekaj slovenskih podjetij, ki imajo v svoji ponudbi tudi ERP aplikacije SAP, Microsoft in Oracle, ki sodijo med najboljše ERP aplikacije.

2.4. UVAJANJE CELOVITIH PROGRAMSKIH REŠITEV Projekt prenove, zamenjave oziroma uvajanja nove celovite programske rešitve je eden najbolj kompleksnih projektov vsake organizacije. Projekt ne vključuje samo spremembe v vodstvu organizacije, vendar zadeva vse oddelke v določeni organizaciji. Pred vsakim uvajanjem je treba najprej izbrati najboljšega ponudnika ERP sistemov. Raziskave so pokazale, da je 35 % vseh projektov uvajanj prekinjenih pred zaključkom uvedbe, 55 % jih ni zaključenih v določenem roku ali s predvidenimi stroški, 10 % vseh uvedb pa je bilo uspešno uvedenih (Cotterell in Hughes, 1995). Ta projekt lahko poteka v več smereh. Uporaba informacijske tehnologije ima vsako leto večji delež v stroškovnem smislu, računalniške zmogljivosti se večajo, njihove cene se nižajo, kar pa je pripeljalo precej podjetij do zaprtja računalniških centrov in so prešla na bolj ali manj med seboj povezane računalnike. Druga podjetja se odločijo za outsourcing – v t. i. skupnih računalniških centrih. Vse bolj se zavedajo, da jim urejen informacijski sistem prinese precejšno primerjalno prednost (Kovačič, 2005). Znane metode za uvedbo celovite programske rešitve so:



- lasten razvoj rešitev,

- nakup rešitve,

- najem rešitve,

- prilagoditev obstoječe rešitve,

- zunanje izvajanje storitev (outsourcing).

Zgoraj omenjeni lasten razvoj rešitve je mogoč s pomočjo celovitih informacijskih orodij. Podjetje mora imeti za to metodo standardizacijo poslovnega modela podjetja. Za tehnološke oddelke v podjetju je treba nabaviti celovito informacijsko orodje, ki vključuje integrirano orodje CASE, ter s posodobitvijo obstoječe strojne arhitekture v večslojno arhitekturo. Za prenovo kadrovske službe je dovolj izobraževanje ljudi, ki delajo v IT oddelku, in drugih uporabnikov. Treba je vzpostaviti novo bazo podatkov, ki bo vsebovala vsa poslovna pravila in s tem skrajšala razvoj in zmanjšala obseg vzdrževanja programskih rešitev. Ta proces predstavlja 70–90 % vseh stroškov informatike (Zebec, 2011). Slabost te metode je, da razvijamo programsko rešitev z najnovejšimi informacijskimi orodji, ki po navadi pokrivajo celotno podjetje, vse oddelke, predela tudi obstoječe rešitve z novimi koncepti orodij. Druga metoda je nakup ali najem celovite programske rešitve. Obveljalo je nekakšno nenapisano pravilo, da se organizaciji splača spustiti v nakup rešitve v primeru, da ta pokriva vsaj 80 % informacijskih potreb obravnavanega področja (Kovačič, 2002). Z nakupom ali najemom celovite programske rešitve si lahko organizacija močno skrajša čas razvoja in implementacije rešitve ter zniža tveganje o neuspehu končnega rezultata. Z nakupom lahko prejmemo zunanje, tuje znanje poslovanja, imenovane tudi »najboljša praksa«. Nakup predstavlja precej visok strošek programske rešitve in stroške lastništva (licence). Drug problem lahko, ni pa nujno, predstavlja prilagoditev rešitve informacijskim potrebam uporabnikov ter prenosu znanja, za katerega je potreben razvoj in pa samo vzdrževanje. Podjetje lahko tudi najame strojno opremo od ponudnikov storitev ASP (angl. Application Service Provider) in se s tem izogne stroškov lastništva (Kovačič, 2005). Dogradnja obstoječe rešitve oziroma nadaljevanje lastnega razvoja rešitve na obstoječi informacijski arhitekturi je precej vprašljiva, ampak prisotna v podjetjih. Ta metoda ni vprašljiva, če podjetje ne namerava prenavljati poslovnih procesov oziroma so z njimi zadovoljni. Za uvedbo celovite programske rešitve po tej metodi morajo biti v podjetju izpolnjeni naslednji pogoji: dokumentiranje obstoječih uporabniških programskih rešitev ter podatkovne baze, zagotovitev ustreznega vzdrževanja, kot sta odprava napak in dopolnjevanje obstoječih rešitev, zagotovitev možnost nemotene nadgradnje obstoječe opreme ob vključevanju novih uporabniških rešitev in širitvi obsega poslovanja, standardizacija in poenotenje vseh podatkov, zagotovitev ustrezne varnosti in zanesljivosti delovanja obstoječe opreme. Prednosti vidimo predvsem v prenovi informatike na obstoječi informacijski arhitekturi: v delu z uporabniku znanim programskim okoljem, potrebnem relativnem kratkem času za



uvedbo nove informacijske tehnologije, posameznih rešitev, manjšem obsegu in postopnosti sprememb. Slabosti pa vidimo predvsem v nenačrtovanem in ne celovitem pristopu: vzdrževanje je zahtevno, drago in problematično, nizka kakovost in neustreznost uporabniških programskih rešitev, nenatančna ažurnost podatkov na nivoju podjetja in ne zagotovljena varnost podatkov (Kovačič, 2005). Podjetja se najpogosteje odločajo kar za nakup standardnih rešitev, saj tako, v primerjavi z razvojem lastnega informacijskega sistema, prihranijo ogromno časa in energije. Te celovite programske rešitve po navadi ponujajo tudi angl. Best Practice ali podporo, ki jim omogoča že uveljavljene in izpopolnjene načine poslovanja, ki jih lahko organizacija tudi uporabi in ob njih zgradi čisto svoj poslovni sistem. Za nakup standardne rešitve se je odločilo tudi naše podjetje. Ti načini poslovanja pa niso vedno najboljša rešitev, saj se organizacije med seboj zelo razlikujejo. Največkrat je treba celotno rešitev precej prilagoditi organizaciji, ki jo vpeljuje. Organizacija mora ob prenovi oziroma uvedbi razmisliti tudi o prenovi poslovnih procesov, saj samo tako lahko doseže boljšo kvaliteto, boljše rezultate poslovanja skrajša oziroma izboljša procese in zniža njihove stroške.

2.5. KORAKI UVEDBE CELOVITE PROGRAMSKE REŠITVE Uvajanje ERP lahko razdelimo v več podprocesov oziroma faz, ki si sledijo zaporedno (Povalej, 2007):

1. pripravljalna faza projekta, 2. faza priprave sistema, 3. uvajanje in testiranje, 4. sklepna faza.

2.5.1. PRIPRAVLJALNA FAZA V pripravljalni fazi projekta moramo jasno določiti namene, cilje in pričakovane rezultate. Najprej je treba podrobno analizirati obstoječe stanje, analizirati procese. Bolj, ko je analiza podrobna, boljša bo predlagana rešitev. To je ena bolj pomembnih faz uvajanja celovite programske rešitve. Takrat ima organizacija tudi priložnost prenoviti ali spremeniti obstoječe procese. Obstaja več vrst načinov oziroma metodologij uvedbe celovite programske rešitve v podjetje. Najpomembnejši sta Waterfall in Agile. Kljub temu da metoda Waterfall velja za najpogostejšo uporabljeno, se agilna metoda v zadnjih letih kar precej širi, saj vrne boljše rezultate, posebej pri potrebah programske opreme. Model Waterfall (model slap) je zaporeden proces uvedbe, ki napredek ponazarja v obliki slapa. Delo poteka enakomerno skozi vse faze. Ta razvojni model izvira iz predelovalne in gradbene industrije, pri kateri pa so vse spremembe drage ali včasih celo nemogoče. Na Sliki 3 je lepo vidno, da se pri modelu Waterfall napredek stalno opazi, v vsaki fazi (Nicholas Lorente in Nicholas Lorente, 2013).



Slika 3: Prikaz modela Waterfall

Uvedba Microsoft Dynamics Nav je uspešna, ko sledimo fazam uvedbe, ki so predprodaja, pridobitev potreb, analiza, razvoj, uvajanje in podpora. V tem primeru faza analize ne more steči preden pridobimo potrebe in razvoj ne more steči preden so vse potrebe analizirane. V prvo in drugo fazo je po navadi porazdeljenega 20-40 % časa, 30-40 % časa je posvečenega programiranju oziroma prilagajanju sistema, preostali čas pa je namenjen uvedbi in testiranju (Waterfall model, 2017). Ta model teoretično podjetjem prinaša več varnosti. Na ta način je po prejeti zahtevi mogoče določiti obseg projekta, lažje pa je tudi določiti strošek in končni datum. Ampak to je samo teoretično, v praksi se izkaže, da so zahteve, ki jih prejme ekipa, ki uvaja Microsoft Dynamics Nav, napačne, ker v prejšnjih fazah kupec ne pozna sistema dovolj dobro, da bi razmišljal o vseh drugih možnih zahtevah, ki se porodijo kasneje. Agilna metodologija (Slika 4) daje poudarek predvsem zmanjševanju stroškov in zagotavljanju vrednosti. Za razliko od Waterfall metodologije ta metodologija podpira konstantno prilagajanje in kontroliranje. Poudarek daje tudi ekipnemu delu, sami organizaciji in odgovornosti za delo.



Pri tej metodologiji se kupcu čim prej poda delujočo kodo oziroma delujoč sistem, potem pa se ga popolnoma prilagodi kupčevim potrebam. Prednost, da se lahko spremeni le del kode in ni potrebe po spreminjanju celotne kode, daje veliko konkurenčno prednost pred drugimi metodologijami. Naročnik in končni uporabniki na eni strani ter ponudnik oziroma razvojna ekipa tesno sodelujejo že od samega začetka. Določi se ključne uporabnike, omogoči se jim testno (delovno) okolje in se od njih pričakuje, da bodo motivirani do te mere, da bodo naloge pravočasno in kvalitetno opravili. Ključni uporabniki imajo ves čas podporo razvojne ekipe, s katerimi lahko neposredno pridobivajo informacije. Na rednih delovnih sestankih se preverja napredek in delujočo programsko opremo (Agilne metode razvoja programske opreme, 2016).

Slika 4: Agilna metodologija Za agilno metodo je značilno, da se bodo faze ponavljale, krožile med seboj toliko časa, dokler programska oprema ne bo dodelana po naročnikovih zahtevah. Če je pripravljalna faza uspešno zaključena, je kasneje malo nesporazumov, ki so pomemben vir težav pri uvedbi (Nicholas Lorente in Nicholas Lorente, 2013).



2.5.2. FAZA PRIPRAVE SISTEMA

V tej fazi se zgradi že delujoč sistem, ki je pripravljen na uvedbo in njegovo testiranje. V sistem se prenesejo vsi podatki iz prejšnjega sistema, da lahko potem ključni uporabniki začnejo uporabljati sistem in s tem odkrivajo morebitne napake pri delovanju sistema, iščejo rešitve za poslovne scenarije in pomagajo pri nastavitvi samega sistema. Zunanji sodelavci, ki skrbijo za uvedbo, ne poznajo delovanja organizacije, zato je zelo pomembno, da ključni uporabniki testirajo čim več aplikacij in delovanja sistema. Pripravijo pa se tudi navodila in izobraževanje ne samo ključnih, vendar vseh operativnih uporabnikov sistema.

2.5.3. FAZA UVAJANJA IN TESTIRANJA Usposabljanje vseh uporabnikov je zelo pomembno, saj je od tega zelo odvisen uspeh celotne uvedbe sistema. Več težav oziroma napak odkrijemo v tej fazi, lažji bo prehod iz starega na nov sistem, ki bo bolj izpopolnjen. 2.5.4. SKLEPNA FAZA PROJEKTA Na koncu potrdimo, da smo pripravili ustrezno delujoč sistem in lahko preidemo v redno delovanje. V trenutku prehoda na nov sistem moramo poskrbeti za zadnji prenos aktualnih podatkov iz dosedanjih starih sistemov v novega. Takoj se začnejo tudi redno vzdrževanje, odpravljanje težav in pomoč uporabnikom. Ne smemo pozabiti na vzpostavitev postopkov za arhiviranje, uvajanje novih uporabnikov, administriranje sistema, dopolnitve. S stališča projekta opravimo formalni zaključek in ocenimo uspešnost svojih prizadevanj. Zelo koristno je, da poleg druge dokumentacije zberemo tudi vse ocene, predloge, opažanja, ki nam bodo prišla prav v času vzdrževanja sistema ali kasnejšega novega ciklusa postavljanja celovitega informacijskega sistema (Povalej V., 2007).

2.6. KRITIČNI DEJAVNIKI USPEHA IMPLEMENTACIJE Projekt uvajanja rešitev ERP sodi po svoji kompleksnosti med najzahtevnejše projekte, ki potekajo v sodobnih organizacijah (Kumar et al., 2001). Za uspešno zaključen projekt uvedbe celovite programske rešitve je potrebno, da se pričakovanja končnih uporabnikov in procesi organizacije uskladijo z danostmi izbrane rešitve. Neskladnost je povzročila, da je neuspeh uvedbe ERP sistema po nekaterih virih enak tri četrtini poskusov vseh uvedb organizacij. Neuspeh pa ne pomeni nujno, da organizacija ni uvedla izbrane celovite programske rešitve, pomeni pa, da je organizacija ni uvedla v sprva načrtovanem časovnem obdobju ali pa je sama uvedba prekoračila predvidene stroške. Uspeh pa ne pomeni vedno samo odlično. Nekateri projekti so dobili status uspešno že samo zaradi tega, ker so zaživeli, ni pa omenjeno, koliko težav so imeli in koliko jih še imajo ob zagonu. Nekatere organizacije se po uvedbi celovite programske rešitve odločijo še za revizijo le-te, da dobijo presojo uspešnosti.



Dejavnike uspeha lahko z namenom njihovega obvladovanja razdelimo po različnih merilih (Kovačič in Boslij-Vukšić, 2005):

- dejavniki s strani rešitve ERP,

- dejavniki s strani dobavitelja oziroma uvajalca,

- dejavniki organizacije,

- dejavniki projekta.

2.6.1. DEJAVNIKI S STRANI REŠITVE ERP Merilo za izbiro ERP se kot največkrat uporablja sama funkcionalnost rešitve, tako da bi lahko rekli, da je funkcionalnost odločilen vpliv uspeha projekta. Organizacije na začetku, v fazi izbire najboljšega ponudnika ERP rešitev, naredijo obsežno raziskavo in primerjavo vseh ponudnikov rešitev in ob tem ustvarijo vrednotenje več rešitev in medsebojno primerjavo. S tem organizacije pridobijo najboljšo celovito programsko rešitev. Izberejo tisto, ki jim ponudi pokrivanje želenih procesov, na žalost pa primerjava ne prikaže, kako kakovostno procese podpira željen ERP. Drug dejavnik s strani rešitve ERP je ugled proizvajalca rešitve, ki po eni strani povečuje možnost, da bo imel uveden ERP sistem podporo po uspešni uvedbi še kar nekaj časa, po drugi strani pa lahko organizacija z nakupom uveljavljene ERP rešitve vpliva na rast lastnega ugleda in vrednosti. Tretji dejavnik s strani rešitve ERP je dejavnik zanesljivosti delovanja rešitve, ki se po navadi pokaže šele po uspešni uvedbi rešitve. Študija je ugotovila, da je imelo težave z zanesljivostjo delovanja programske opreme, po tem, ko so jo začeli uporabljati, kar tretjina projektov. K dvigu učinkovitosti in kakovosti poslovanja podjetja lahko pripomore tudi, če organizacija v poslovanje vključi tudi poslovno znanje, kar jim omogočajo skoraj vse standardne programske rešitve. Lokalizacija ali prilagajanje celovite programske rešitve lokalni zakonodaji in praksi pomeni ogromne stroške pri uvedbi. Ta problem se pogosto izkaže v svetovnem merilu, še posebej pa pri nas v Sloveniji. 2.6.2. DEJAVNIKI S STRANI DOBAVITELJA OZIROMA UVAJALCA Pri projektu uvedbe celovite programske opreme so neprecenljive izkušnje, ki jih je uvajalec pridobil čez čas in preko precejšnje število predhodnih uvedb. Bolj ko je uvajalec izkušenj, hitrejša postaja uvedba v organizacijo, ker se po navadi uporabijo že preizkušeni prijemi in rešitve. Pomemben je odnos med organizacijo, ki je naročnik uvedbe in med organizacijo, ki uvaja ERP rešitev. Uspešni so le takrat, ko obe strani izpolnita začrtane cilje. Pri organizacijah, ki pričakujejo ogromno prilagoditev in spremembo programske opreme je ključno, da stranka zaupa usposobljenosti izvajalca in uspehu projekta.



2.6.3. DEJAVNIKI ORGANIZACIJE Da bi bil projekt uvedbe nove ERP rešitve uspešen, mora le-ta imeti podporo vrhovnega managementa organizacije. Šele ta oblika podpora je dejavnik uspeha. Primer dobre aktivne podpore managementa je odobritev zamenjava trenutno uporabljene pred nedavnim kupljene strojne opreme za novo, drago opremo, zaradi tega, da bi ERP deloval optimalno. Široka podpora projektu na različnih nivojih organizacije. V literaturi večkrat omenjen dejavnik, ki omogoča ustvariti ugodno podnebje za projekt. Ustvari se z ustreznim ravnanjem vodstva, ki mu uspe to vzdušje pripraviti, in med tekom projekta s profesionalnim pristopom ter kakovostjo opravljenega dela (Kovačič in Boslij-Vukšiić, 2005). Študije ugotavljajo, da je kar nekaj projektov utrpelo posledice zaradi stabilnosti poslovanja podjetja, predvsem zaradi fluktuacije zaposlenih. Veljalo naj bi, da je treba ob odhodu že usposobljenega človeka, najti nekoga novega, ki ga je treba tudi naučiti določenih znanj. Najslabši čas za menjavo ljudi je med fazo menjave ali uvedbe ERP sistema. Predpogoj za uspešno uvedbo ERP sistema v organizacijo je seveda tudi dobra opremljenost z IT in pa obvladovanje IT-ja. Če organizacija nima urejene informacijske tehnologije, je bolje, da se ne loti uvedbe nove rešitve. Projekt menjave oziroma uvedbe ERP sistema ni odvisen od posameznika, vendar je to skupinski projekt, zato je uporaba sodobnih načinov komuniciranja in skupinskega dela obvezna. Pomembno je tudi, da pri projektu ne sodeluje le najvišji nivo organizacije, ampak v ta projekt vključijo več nivojev. Sodelovanje vseh zaposlenih pri odločanju v projektu lahko ustvari ogromno razliko med uspešno in neuspešno uvedbo celovite programske rešitve. 2.6.4. DEJAVNIKI VODENJA PROJEKTA Projekt uvedbe poteka s pomočjo izbrane metodologije, za izvedbo katere mora poskrbeti vodja projekta. Nekateri pravijo, da zasluge za uspešno in učinkovito uveden ERP sistem lahko pripisujemo urejenemu in učinkovitemu vodenju. Drug dejavnik je obseg in kakovost usposabljanja zaposlenih. Obstajajo različne metode usposabljanja zaposlenih. Nekatere uporabnike usposobijo že na samem začetku projekta, da jih lahko vključijo v sam projekt uvedbe. Po navadi tako usposobijo samo ključne uporabnike, ki kasneje usposabljajo še ostale uporabnike v organizaciji in tako naredijo usposabljanje, stroškovno gledano, najugodnejše. Kot ključni dejavnik uspeha je tudi tip prehoda na novo rešitev. Poznamo postopen prehod ali pa prehod »vse naenkrat«. O tej temi se ni izoblikovalo jasno mnenje, kateri pristop je boljši. Pomembno pa je, da poznamo tako uspešno kot neuspešne primere na obeh straneh. Pri času projekta je pomembno, da si zastavimo realno časovno obdobje za



uspešno uvedbo ERP sistema. Pretesen plan bo negativno vplival na sam projekt in povišal verjetnost, da bo uvedba neuspešna.

3. PREDSTAVITEV PODJETJA Podjetje se namerava razviti v enega bolj prepoznavnih evropskih specialistov za proizvodnjo ne masovnih brezlesnih nizko gramskih papirjev. Podjetju nenehna rast omogoča visoka raven storitev in prilagodljivost kupcem. Podjetje prodaja 90 % vsega proizvedenega papirja v države EU, nekaj tudi izven EU. Velike količine papirja grejo v Turčijo, Nemčijo, Francijo, Veliko Britanijo, Avstrijo, Italijo in Poljsko. Približno 10 % vse prodaje prodajo tudi Sloveniji, kjer so potrebe po papirju manjše. Podjetje ima tudi ISO certifikate, in sicer: ISO 9001:2008, ISO 14001:2004, FSC in PEFC. Podjetje ima 210 zaposlenih ljudi, nekaj imajo tudi študentov. Gre za proizvodno podjetje, ki pa se ukvarja tudi z logistiko oziroma dostavo lastnih izdelkov do kupcev. Za varnost informacijskega sistema in njegovo nemoteno delovanje skrbijo HP-jevi strežniki Proliant. Podjetje ima v lasti 7 takih strežnikov, za potrebe nove celovite programske rešitve pa nameravajo dokupiti še dodaten strežnik. Poleg strežnikov imajo v lasti 140 osebnih in 15 prenosnih računalnikov. Do podjetja imajo internetno povezavo dveh različnih ponudnikov interneta hitrosti 10 Mb/s, povezava pa v podjetje pride preko UTP-kabla. V podjetju so napeljani optični kabli, ki skrbijo za hiter prenos podatkov. Za komunikacijo ljudi, zaposlenih v podjetju, poskrbi Microsoftov Outlook za e-poštno odjemanje, imajo pa tudi klasično centralno telefonijo. Do sedaj so uporabljali celovito programsko rešitev Exim, ki je pokrivala prodajni proces, nabavni proces in finance, za druge procese v podjetju skrbijo drugi programi, ki so prilagojeni podjetju. Za skladiščno poslovanje uporabljajo program Skladko SVS, za prečno rezalne stroje pa program podjetja Iplus (prilagojen za podjetje). Veliko si pomagajo z Microsoftovim Excelom, kjer so vpisani vsi načrti proizvodnje. Te Excelovi dokumenti so naloženi na strežnik in vsebujejo ogromno podatkov, zato je odpiranje le-teh zamudno. Problem nastane pri osveževanju dokumentov, ki jih je treba sproti shranjevati, da so ažurirani. Podjetje se je za menjavo celovite programske rešitve odločilo že na začetku leta 2014. Odločali so se med Microsoft Dynamics Navom, SAP-om in Pantheonom. Izbira ni bila lahka. Na koncu so se odločili za rešitev Microsoft Dynamics Nav. Projekt je dobil zeleno luč, določili so, da naj bi se testna različica novega sistema zagnala že 1. 1. 2015, vendar se to kasneje zaradi določenih oteženih razmer ni zgodilo. Ustavilo naj bi se pri planiranju proizvodnje, ki naj ga ne bi pokrivala rešitev Microsoft Dynamis Nav, ampak naj bi ga pokrilo drugo podjetje z MES sistemom



(angl. Monitoring Execution System). Datum je prestavljen na zagon nove celovite programske rešitve na 1. 3. 2017. Za celotno uvedbo celovite programske rešitve bo skrbelo podjetje, ki ni želelo biti imenovano.

4. MICROSOFT DYNAMICS NAV Kot smo že omenili so celovite rešitve nastale predvsem kot posledica povezovanja različnih oddelkov. Kot glavno značilnost ERP sistemov bi lahko šteli prav ta celovit prenos funkcionalnosti in podatkov, ki so shranjeni v centralni bazi podatkov. Microsoft Dynamics Nav je rešitev ERP za podporo poslovnim procesom v majhnih in srednje velikih podjetjih (10–250 uporabnikov). Dynamics Nav je na voljo v več kot 40 lokaliziranih različicah (lokalizacija pomeni prilagoditev rešitve na specifične zahteve določene regije/države – poslovne zahteve, običaji, zakonodaja, davčni predpisi) (Erjavec, Popovič in Trkman, 2013). Velika prednost le-tega pa je možnost prilagajanja specifikam in potrebam podjetij. Vsak uporabnik posebej si lahko izbere tiste module, ki jih potrebuje za svoje delo, seveda pa je treba upoštevati njihovo soodvisnost. Microsoft Dynamics Nav je torej funkcija za zagotavljanje podpore v:

- vodenju financ, ki je osrednje jedro rešitve,

- prodaji in trženju; hrani vse podatke o kupcih, naročilih in cenikih,

- nabavi; hrani vse podatke o dobaviteljih in skrbi za obdelavo

dokumentacije,

- skladišču; skrbi za prevzem, popis in hrambo materiala,

- proizvodnji; vsebuje podatke o materialu, kosovnicah in načrtovanju

proizvodnega procesa,

- načrtovanju virov, katerega predmet so lahko tako ljudje kot tudi stroji,

- projektih; vsebuje planiranje virov,

- servisih; razne poprodajne aktivnosti,

- kadrovski evidenci; vsebuje seznam zaposlenih,

- administraciji, ki spremlja delovanje podjetja in ureja splošne zadeve

(Erjavec, Popovič in Trkman, 2013).

Na Sliki 5 je prikazana primer vstopne strani celovite programske rešitve Microsoft Dynamics Nav 2013R2.



Slika 5: Vstopna stran Microsoft Dynamics Nava



5. ANALIZA OBSTOJEČEGA STANJA P

od

jetj

e X

kup

ec

PR

OD

AJA

PR

OIZ

VO

DN

JAN

AB

AV

A

Do

bav

ite

lj

Sprejme povpraševanje

Povpraševanje

Preverjanje roka dobave

Preverjanje razpoložjivosti

izdelkaPotrditev naročila

Dobavi iz proizvodnje

Dobavni rokPotrditev

dobavnega roka

Sprejetje naročila

Ne

Da

Prejem naročila za izdelavo izdelka

Preverjanje zalog surovin

Izdelek se proizvedeSurovine so na zalogi

Oblikovanje MRP liste

Surovin ni na zalogi

Nabava surovin Prevzem surovin

Dobava izdelka

Naročilo Potrditev naročila Dobavnica in račun

Dobava surovinNaročilo surovin

Naročilo proizvodnji

Slika 6 Model prodajnega procesa podjetja X



Na sliki 6 je opisan prodajni proces opisane organizacije. Običajno se proces začne s povpraševanjem kupca. V prodaji referenti obdelajo povpraševanje, preverijo dobavni rok ter ga sporočijo kupcu. Kupec pošlje naročilo, referenti preverijo, ali lahko dobijo izdelek iz zalog ali ne. Če je izdelek na zalogi, se po navadi preetiketira in dobavi kupcu. Če izdelka ni na zalogi, mora izdelek v proizvodnjo. Tam se preveri, če imamo za ta izdelek dovolj surovin. Če surovin ni, nabavni oddelek nabavi surovine, drugače se naročilo uvrsti v načrt in se izdela. Po proizvodnji se lahko izdelek dobavi. Ob dobavi se kupcu izda skladiščna dobavnica ter račun.

5.1. OBSTOJEČE STANJE V naši diplomski nalogi smo se osredotočili na prodajo in trženje. Prodajni oddelek je sestavljen iz dveh prodajnih vodij in petih prodajnih referentov. Prodajni vodji večinoma opravljata svoje delo na terenu, kjer iščeta nove kupce ter le-tem predstavita prodajne pogoje. Za nemoteno opravljanje svojega dela morata imeti dostop do podatkov ter pregled nad njimi. Naročila vnašajo prodajni referenti, ki prejmejo povpraševanja, obdelajo naročila, reklamacije in izdajajo račune. Vsak izmed njih skrbi za agente v določeni državi, med seboj se tudi nadomeščajo, saj so postopki dela povsod enaki. Podjetje večinoma prodaja svoje izdelke, lahko pa za svoje stranke tudi dodela papir za druge dobavitelje. V 90 % poslujejo s tujci, obstoječih strank je med 500 in 1000. Za vnos novega kupca uporabimo poseben obrazec za vnos podatkov, ki ga nato posredujejo v računovodstvo, kjer odprejo novo šifro kupca in označijo, ali gre za prejemnika ali plačnika. Tudi v primeru kasnejših sprememb uporabimo ta obrazec. Kupce nato odpirajo v FRS. Za vsako državo ima podjetje svoj cenik, na katerega so vezani rabati in skonti. Popusti na takojšnje plačilo oziroma kasa skonte pa izdajajo ročno in jih tako uskladijo s slovensko zakonodajo. Avansnih postopkov v večini ne uporabljajo, saj je večina kupcev iz tujine. Boljšim in kupcem z večjim potencialom dodelijo možnost kreditnih limitov. Kontrolo opravljajo s pomočjo sistema Exim, kjer lahko vedno pogledajo saldo odprtih postavk in količino odprtih nalogov. Obseg letnega načrta proizvodnje je odvisen od letnega načrta prodaje oziroma od kupcev ter količine naročenega papirja. Mesečni načrt dobimo z letno procentualno delitvijo po mesecih z nekaj odstopanja. Upoštevati je treba, katere vrste papirja je kupec naročil in na podlagi tega organiziramo proizvodnjo le-tega. Predvsem nas zanima, kdaj se bo delala določena vrsta papirja, zaporedje dela in čas proizvodnje. V proizvodnji se po navadi naredijo kontingenti, kar pomeni, da se rezervira obdobje, ko se bo istočasno delala podobna vrsta papirja, ki je takrat v proizvodnji. Zelo pomemben je pravilni vrstni red proizvodnje in pa priprava na možne zastoje. Podjetje tako tudi čez mesec sprejema nova naročila in jih uvrsti v proizvodnjo v skladu z načrtom kontingentov. Na ta račun se lahko proizvodnja podaljša ali skrajša za kak dan. Ko je proizvodnja zaključena, je treba papir zaviti v zvitke in nato



izrezati v format. Podjetje prodaja končne izdelke v treh oblikah: zvitki, razrezan papir na pole in papir zavit v rise. Kot smo že omenili, naročila prejemajo referenti, ki najprej pregledajo zaloge za želeni papir. Če le-tega ni na zalogi, se preveri, če je trenutno v proizvodnji ter razpoložljivost transporta do kupca. V primeru, da izdelka nimajo na zalogi, se z vodjo proizvodnje dogovorijo za možni datum dobave in odgovor skupaj s ceno pošljejo kupcu v obliki ponudbe. Če kupec potrdi ponudbo, referent izdela naročilo proizvodnji, s katerim pridobi potrditev s strani proizvodnje, da bodo papir izdelali. Nato je njegova naloga, da še enkrat zadevo preveri in kupcu potrdijo naročilo. Na povpraševanje referenti odgovorijo še isti dan, na potrditev pa je treba počakati dva do tri dni. Na dokumente nabave in prodaje se pogoji izpišejo ročno kot klavzule na dokumentu. Oštevilčenje samih dokumentov je samodejno, zaporedno. Nekateri kupci oddajo naročilo s klavzulo, ki ni prosto za proizvodnjo, kar pomeni, da se naročilo doda v planiranje proizvodnje, po navadi se določi rok, do kdaj mora kupec naročilo sprostiti za proizvodnjo (približno 7-10 dni pred proizvodnjo) in se potem izdelek izdela. Na prodajnem nalogu se poleg običajnih podatkov vnaša še:

- vrsta prodaje (kontiranje in DDV),

- levi in desni podpisnik,

- referent: šifra agenta,

- objekt: vrste etiket, ki so možne,

- klavzule dokumentov.

Pri vrstici (poziciji) prodajnega naloga pa se vnaša: - Način pakiranja proizvoda,

- več drugih polj: razni certifikati, vrsta embalaže, količina embalaže ...

Za transport izdelkov do kupca v veliki večini organizira podjetje. Približno 90 % vseh prevozov poteka preko fiksnih transportnih organizacij, 10 % pa preko borze za iskanje prevozov. Organizacija ima s transportnimi podjetji sklenjene pogodbe. Logistične poti izbira podjetje samo. Trenutno uporabljajo skladiščni program SVS. Veliko odpreme se kombinira tako, da se peljejo polni kamioni. Odprema je skoncentrirana na ponedeljek in petek, sreda in četrtek pa sta po navadi namenjena prekomorskim odpremam. Prevozniki večinoma izdelujejo vsako fakturo posebej za vsak prevoz, nekaj faktur pa imajo tudi zbirno. Podjetje se poslužuje hišnega carinjenja, izvajajo pa tudi intrastat poročanje. Prodajajo v veliki večini preko agentov, ki za svoje posredovanje dobijo določen odstotek provizije, ki se odšteje s fakture potem, ko se odšteje tudi prevoz. Odstotek provizije je enak za vse agente in za vse izdelke. V podjetju je zaposlena oseba, ki skrbi za to, da agenti dobijo točne, preverjene zneske. Tabelo faktur in plačil se spremlja v Microsoftovem Excelu. Opominjanje glede plačil se izvaja telefonsko oziroma preko e-pošte. Želja je, da se to podpre z novim ERP sistemom.



Zamudnih obresti za zdaj ne zaračunavajo, stranke so večinoma v tujini, približno 60 % faktur je plačanih v roku 30 dni. CRM rešitev se trenutno ne uporablja, ker jim sistem Exim tega niti ne omogoča, želijo pa, da bi jim nov ERP sistem pomagal vpeljati in podpreti tudi CRM rešitve. V rešitvi Exim, ki jo trenutno uporabljajo, je veliko podvajanja vnosov in posledično ročnega dela (odstranjevanja in preverjanja), ki se ga podjetje želi znebiti. Podjetje je izrazilo željo, da bi agenti imeli možnost vnesti naročilo sami, vendar bodo to opcijo verjetno uvedli po uspešni uvedbi celovite programske rešitve Microsoft Dynamics Nava. Mag. Goran Čop (osebna komunikacija, 22.5.2014) 5.1.1. USTVARJANJE PRODAJNEGA NAROČILA V EXIMU Za delo z Eximom uporabljamo samo nekaj tipk na tipkovnici:

- PF1 - tipka na tipkovnici »num lock« nam odpre šifrante, ki so možni za

določeno mesto na naročilu,

- PF2 – tipka na tipkovnici »/« nam omogoča, da se premikamo po straneh

naprej po določenem dokumentu,

- PF3 – tipka na tipkovnici »*« nam omogoča, da se premikamo po vrsticah na

določenem dokumentu,

- PF4 – tipka na tipkovnici »-» nam omogoča, da se vračamo po straneh na

določenem dokumentu,

- še ostale tipke za tiskanje in urejanje dokumentov.

Začeli bomo z opisom izdelave prodajnega naročila v Eximu.



Slika 7: Vstopna stran Exima

Ko se prijavimo v Exim, nas pričaka izbirni meni, kot je razvidno na Sliki 7. Za razliko od Microsoft Dynamics Nava Exim še ne omogoča, da bi uporabnik imel pravice dostopati samo do želenega oddelka, ampak dovoljuje vsem uporabnikom spreminjati dokumente katerega koli oddelka. Pomeni, če je nekdo zaposlen v prodajnem oddelku, lahko z istim uporabniškim imenom in geslom ustvari tudi nabavno naročilo. Izberemo prvo izbiro »PRODAJA EXIM«.

Slika 8: Premikanje po direktorijih Exima



Prišli smo v prodajno področje Exima. Naštete so vse funkcije, ki jih je možno urejati na področju prodaje. Najbolj uporabljeni sta druga in tretja. Za kreiranje novega dokumenta izberemo B ali »Vzdrževanje dokumentov«.

Slika 9: Eximovo prodajno področje

Glede na to, da je Exim že precej star program, ima presenetljivo veliko pokritje oddelkov. Pokriva področje prodaje, nabave, del proizvodnje, finance. Exim nudi preko 400 različnih funkcij oziroma programov v podmenijih. Pogrešamo skladiščni sistem, sistem planiranja in pa proizvodni sistem. Problem Exima pa je zakompliciran izvoz in urejanje podatkov. Izberemo prvi program na Sliki 9, ki nas pripelje do kreiranja novega prodajnega naročila ali potrditve naročila, kot je to zavedeno v Eximu. Dokument prodajnega naročila Exim poimenuje PNN.



Slika 10: Obstoječa naročila v Eximu

Na Sliki 10 lahko vidimo že ustvarjene prodajne naloge za leto 2016. Številčno serijo določa program sam. Možno je tudi izbrisati določen PNN in kreirati novega. Na tej poziciji pritisnemo na tipkovnici tipko »insert« in tako ustvarimo nov, prazen PNN, ki ga je treba izpolniti.

Slika 11: Prva stran prodajnega naročila v Eximu

Prva stran pri ustvarjanju novega prodajnega naročila. To je ena pomembnejših strani pri ustvarjanju le-tega. Exim je za to naročilo določil zaporedno številko 196.



Ko se postavimo na št. kupca (1), se s PF1 odpre šifrant kupcev, kjer lahko izberemo kupca. Datumi se vnesejo sami, načeloma se jih ne spreminja. Pri tipu prodaje lahko izberemo »D« kot domači ali »T« kot tuji. Uporablja se za prodajo na slovenskem trgu ali za trg izven Slovenije. To zadeva finančni oddelek. Prav tako lahko vidimo na Sliki 11 pod številko 2 – vrsta prodaje. 101 pomeni prodajo znotraj Slovenije, 201 prodajo znotraj EU in pa 301 za prodajo izven EU. Pri naročilu se vezni dokument pusti prazen. Lahko pa bi bil na primer vezni dokument ponudba, vendar Exim nima možnosti ponudbe. Vezni dokument omogoča, da se prenesejo podatki s predhodnega dokumenta na trenutni dokument. Zelo uporabna stvar, ko se ustvarja skladiščna odpremnica. Pri ustvarjanju skladiščne odpremnice vnesemo vezni dokument PNN številko prodajnega naročila in nam potem program sam prenese vse podatke na odpremnico. Po odpremnici pa se pri ustvarjanju računa vnese vezni dokument odpremnico in prenese podatke iz odpremnice na račun. Pri številki 3 na Sliki 11 lahko vidimo podpisnike. Exim ima možnost dveh podpisnikov, in sicer levega, ki je ustvarjalec naročila in pa desnega, ki je oseba, ki prejme dokument v proizvodnji oziroma planiranju in ta dokument potrdi. Referent pri naročilu pomeni agenturo, agenta, ki skrbi za naročila določenega kupca. Številka 7 pomeni direktna prodaja – prodaja brez agenture. Pri številki 4 vidimo prevzemno mesto ali prejemnika. Prav tako kot pri izbiri kupca lahko na tem mestu pritisnemo PF1 in se nam odpre šifrant kupcev/prejemnikov. Dejanski naslov/pošta/država se prenese iz šifranta. Na tej, prvi strani dokumenta lahko vstavimo še plačilni rok, popuste, rabate ... Pri objektu lahko odpremo nov šifrant, to pa je šifrant etiket. Šifra etikete oz objekta je sestavljena iz 3 znakov:

1. znak: določa vrsta etikete,

2. znak: določa število etiket na izdelku,

3. znak: določa, ali bo na etiketi napisan kupec ali prejemnik.



Slika 12: Določanje plačilnih klavzul na prodajnem naročilu v Eximu

Premikamo se na naslednjo stran naročila s tipko PF2. Odpre se nam okence “Klavzule”, kamor lahko vnašamo določene plačilne klavzule ali pa kakšno drugo besedilo, ki je že vnaprej napisano in nam ga ni treba vedno znova pisati na dokument, lahko ga vnesemo s pomočjo klavzule. Taka klavzula je na primer “Blago”, ki prikazuje besedilo na naročilu, da je blago last podjetja, dokler ni plačano.

Slika 13: Druga stran prodajnega naročila v Eximu



Druga stran prodajnega naročila nam omogoča vnos paritete in kraja, lego kraja, države izvoza in pa nastavitev glede izpisa prodajnega naročila, v katerem jeziku naj bo izpisano naročilo, katera banka itd.

Slika 14: Tretja stran prodajnega naročila v Eximu

Pri tretji strani prodajnega naročila preidemo na dodajanje pozicij proizvodov na naročilo. V pozicijo vstopimo s tipko PF3 ali “*”.

Slika 15: Vstavljanje postavk na naročilo v Eximu

Vsak proizvod na naročilu je treba natančno pregledati in opisati. Kodo, to je 10-mestna šifra proizvoda, lahko odpremo tudi s šifrantom PF1. Na kodo sta vezani še



poziciji Naziv (ki ga lahko tudi poljubno spreminjamo, čeprav se prenese s šifranta privzet naziv) in Dimen. Pri DN lahko odpremo nov šifrant, določamo pa, ali bo proizvod na paletah ali v zvitkih brez palet. Pri opisu lahko vpišemo poljubno 25-mestno besedilo, po navadi po željah kupca. Ta opis se tudi izpiše na etiketi. Določamo lahko 2 datuma, in sicer “D. Dob”, ki je datum, kdaj mora biti proizvod na zalogi in pa “D. Pred”, ki je datum, kdaj naj bi bil proizvod pri kupcu. “B. Cen” določa vejico pri ceni proizvoda. Sledi okvirček še za drugo poljubno 25- mestno besedilo, ki se tudi izpiše na etiketi. Na naslednji poziciji vnesemo količino in pa seveda ceno proizvoda. Spodaj Exim že izračuna celoten znesek, ki bo izpisan na potrditvi naročila. Upoštevan je tudi popust s prve strani naročila.

Slika 16: Komentarji na prodajnem naročilu v Eximu

Zadnja stran prodajnega naročila vsebuje komentarje, ki bodo izpisani na naročilu. To je besedilo, ki ga lahko vsakič poljubno oblikujemo za razliko od klavzul. V vrsti št. 4 vidimo znak “#”, ki loči besedilo, ki je vidno na potrditvi naročila za kupca, in besedilo, ki je vidno samo za proizvodni oddelek, namreč iz tega prodajnega dokumenta je možno izpisati 2 različna dokumenta; naročilo za proizvodnjo in pa “potrditev naročila” (angl. Confirmation). Razlikujeta se v nekaj stvareh. Na dokumentu “Naročilo proizvodnji” je razvidno, za katero vrsto proizvoda gre, količina, pakiranje proizvoda, dejanski naziv proizvoda (in ne spremenjen naziv, če



ga spremenimo), ne vidimo cen, paritete. Vidimo pa samo poljubno besedilo, ki je na tej zadnji strani dokumenta za znakom “#”. Na dokumentu “Potrditev naročila” so razvidne cene proizvoda, količina, naziv proizvoda (spremenjen, če je spremenjen), vidimo besedilo, ki je na zadnjem posnetku zaslona pred znakom “#” in pa prejemnika oz. dostavno mesto. Ne vidimo pakiranja, razen če ga napišemo kot besedilo. Ko je naročilo končano, ga potrdimo in natisnemo. Natisnjeno naročilo se izdela tudi v PDF obliki, ki se ga potem preko spletne pošte pošlje v oddelek planiranja.

5.2. PREDLAGANA REŠITEV V Microsoft Dynamics Navu ločijo ne knjižene in knjižene dokumente. Knjiženi so tisti dokumenti, ki nastajajo v zaključku prodajnih dogodkov, ne knjiženi pa služijo evidentiranju sprememb v fazi prodajnega postopka. V prodaji je osnovni dokument prodajni nalog, ki lahko nastane na podlagi povpraševanja kupca ali pa se neposredno vnese na podlagi kupčevega naročila. Microsoft Dynamics Nav pozna tudi okvirni nalog, ki nastane na podlagi pogodbe oziroma napovedi naročila. Ko nalog dobavimo, poknjižimo knjiženo dobavnico. Ko je nalog poknjižen, ga lahko zaračunamo s knjiženjem naloga do knjiženega računa. Poknjižimo lahko tudi oba dokumenta sočasno. Pri storitvenih računih dobavnica ni potrebna in lahko prodajni proces začnemo tudi z izdelavo ne knjiženega računa, ki ga za tem knjižimo. V primeru, da pride do reklamacije kupca, Microsoft Dynamics Nav pozna vračilni nalog, iz katerega ob prevzemu zavrnjenega blaga od stranke s knjiženjem ustvarimo knjiženo vračilno prevzemnico, nato pa moramo še vrednostno urediti odnos s stranko s knjiženjem vračilnega naloga do knjiženega dobropisa.

Ko enkrat knjižimo kateri koli dokument, ta postane arhivski dokument in ga ni več mogoče spreminjati. Lahko pa ga seveda kadar koli storniramo z nasprotnimi prodajnimi dokumenti, kot sta vračilni nalog ali dobropis, ki ga poknjižimo, knjižen dobropis pa potem z novim nalogom ali računom, ki ga poknjižimo. Prodajni postopek se lahko tudi nadgradi z zahtevo po potrjevanju ne knjiženih dokumentov, kar pomeni, da se program da nastaviti, da ko kupec preseže kreditni limit, ne more odpreti novega prodajnega naročila, vendar se za to opcijo oziroma nadgradnjo v podjetju niso odločili. Prodajni modul je povezan s proizvodnim modulom na več načinov, tako lahko uporabnik iz prodajnega naloga poizve preko funkcionalnosti zagotavljanja, kdaj je najzgodnejši rok dobave za artikle na zalogi oziroma najhitrejši možni rok dobave, v primeru, da artikla nimajo na zalogi in ga je treba proizvesti. Lahko ustvari ločen delovni nalog za vsako posamezno vrstico prodajnega naloga, ustvari skupino proizvodni delovni nalog za vse vrstice prodajnega naloga ali pa ustvari več delovnih nalogov naenkrat s pomočjo delovnega lista načrtovanja.



Do zdaj se je naloge ročno izpisovalo iz Exima in potem pošiljalo v oddelek planiranja preko e-pošte, Microsoft Dynamics Nav omogoča orodje za razpisovanje proizvodnih nalogov v smislu »porini« iz prodaje v proizvodnjo ali pa »potegni«, če želijo prodajni referenti spremeniti nalog. Načrte proizvodnja pa periodično masovno obdela nova naročila. Referenti lahko s tem orodjem v vsakem trenutku pridobijo informacijo o stanju posameznega naročila. Posameznemu artiklu lahko določimo ločeno ceno za vse kupce, lahko pa tudi z določeno cenovno skupino kupca (posamezen cenik). Cenike se da tudi časovno omejiti, tako da se zmanjšajo napake ročnega vnašanja cen, kot je bilo to prej v celoviti programski rešitvi Exim. Cena je lahko v več denarnih valutah in lahko se postavi za različne merske enote. Vsaki postavki na naročilu lahko določimo, ali se na ceno pusti dodajanje vrstičnih popustov ali pa to onemogočimo. Cenikov je v rešitvi Nav lahko poljubno mnogo in lahko se postavi cenik za vsakega kupca posebej. Popust se lahko obesi tudi na vsak artikel ločeno ali pa na skupino artiklov, ni nujno, da ga obesimo samo na kupca. Priporočeno je, da se uporablja samo en cenik za vse kupce, potem pa se razlikuje samo popust za vsakega kupca posebej. Če je cenikov več, lahko pride do zmešnjave in se v določenem trenutku na istem kupcu znajde več različnih popustov. V takem primeru bo Microsoft Dynamics Nav na prodajnem dokumentu samodejno izbral popust, ki je za kupca najbolj ugoden. Kasaskonti so podprti standardno, slovenskih kupcem pa je treba ročno izdati dobropis za kasaskonto. Microsoft Dynamics Nav ponuja tudi določanje kreditnega limita za vsakega kupca. To funkcijo ima že star ERP sistem, ampak nas je pri starem ERP sistemu samo opozorilo, da je kupec šel preko določenega kreditnega limita. V Navu obstajata dva načina glede tega. Lahko se nastavi, da nas sistem samo opozori, da z novim ustvarjenim prodajnim nalogom presežemo kupčev kreditni limit, ob tem pa si lahko tudi ogledamo promet kupca, ali pa nastavimo sistem tako, da nastavimo dodatnega potrjevalca (nadrejenega), da nam ta vsakič znova odobri prodajno naročilo, ko gre le-to čez kreditni limit. Planiranje prodaje se bo izvajalo preko Nava, in sicer na letnem nivoju po vrsticah proizvodov in mesečnih operativnih načrtov v obliki na roke na mesece oziroma tedne razdeljenih količin vrst izdelkov na podlagi letnega načrta in dejanskih okvirnih in prodajnih nalogov glede na zahtevan datum dostave po končnih izdelkih s pomočjo standardnih orodij za planiranje in integracijo med prodajnimi in proizvodnimi nalogi. Ta načrt bo podlaga za MES sistem, ki bo izvedel bolj podrobno planiranje med prodajnimi in proizvodnimi nalogi, vključno z optimizacijami. Skladiščno poslovanje in organizacija transporta bosta še naprej podprta z zunanjim programom SVS Skladko, s katerim bo zagotovljena integracija s pomočjo spletnih servisov (prenos preko ASCII datotek).

V rešitvi Nav ni modula za organizacijo transporta, izvedbeni del transportnega procesa je rešen v SVS Skladko. Za samo organizacijo transporta predlagamo naslednje: doda se modul za organizacijo prevozov, ki se ga doda z novo entiteto kartico prevozov z osnovnimi podatki iz novih šifrantov – prevozniki, vozila in



vozniki. Vsakič, ko bomo želeli odpremiti izdelke, bomo odprli novo kartico prevoza, ki bo dobila svojo referenčno številko in njen status se spremeni v »v pripravi«. Številka prevoza se vpiše na prodajni nalog in pri knjiženju prenese tudi na knjižene dokumente. Po prejemu potrditve prevoza se bodo na kartici prevoza evidentirali podatki o datumu prevoza. Ko transportna organizacija pošlje račun za opravljen prevoz, se ob knjiženju nabavnega računa arhivira tudi pripadajoč prevoz. Zaradi uporabe SVS se bo skladiščno dobavnico v Navu uporabilo kot vezni dokument med Nav in SVS. Na eno skladiščno dobavnico v Navu bo mogoče vezati več prodajnih nalogov. SVS bo skladiščne dobavnice prebral in omogočil, da na podlagi več dobavnic uporabnik organizira en transport. SVS se bo malenkost nadgradilo, saj trenutno ne omogoča tiskanje nakladnic, dobavnic CMR listin in prodajnega naloga. Do zdaj je bilo treba za tiskanje teh dokumentov uporabljati Exim. Za optimizacijo transportnih poti in organizacijo prevozov obstajajo druge različne namenske rešitve, ki omogočajo integracijo z Microsoft Dynamics Nav, vendar se za to podjetje ni odločilo. Podjetje se poslužuje prodaje preko agentov oziroma posrednikov, ki jih Nav ne podpira. Ponuja pa omejeno funkcionalnost za ugotavljanje provizij lastnim prodajnim referentom. Za ta namen so pripravili opcijsko provizijo agentom. Na kartico kupca se lahko doda polje »št. agenta«, ki je povezana s šifrantom dobaviteljev. Lahko se doda polje, kamor se vpiše odstotek provizije agenta, tako nam omogoča pregled prodaje posameznega agenta in izračuna določen odstotek provizije. Pomembno je še, da se od računov najprej odbije vrednost transporta in šele potem se izračuna provizija za agenta.

Podjetje uporablja hišno carinjenje, ima osebo, zaposleno v podjetju, ki skrbi za lastno carinjenje prodanih izdelkov v tujino izven EU. Intrastat poročanje se bo izvajalo z rešitvijo Nav, ki deluje na podlagi podatkov iz knjiženih dobavnic. Za intrastat poročila se podatki zbirajo mesečno s statističnimi obrazci neposredno od poročevalskih enot. Podjetje je zavezano za mesečno poročanje carinski upravi o prodaji in nabavi blaga in osnovnih sredstev z državami EU in v obeh primerih presega statistični prag in je zavezanec za poročanje po statistični vrednosti. Obvezni podatki za poročanje so:

- pariteta dobave,

- vrsta transakcije oziroma posla,

- način prevoza,

- neto/bruto teža,

- carinska tarifa,

- mesto vstopa/izstopa,

- statistična vrednost za poročanje nabave,

- statistična vrednost za poročanje prodaje: poroča se fakturna vrednost, ki

se zmanjša za stroške transportov. Na izdanem računu se navede prodajna

vrednost, ki je odvisna glede na pariteto dostave. V kolikor je pariteta

FCA, se kupcu ne zaračunavajo transportni stroški.



Do zdaj podjetje ni uporabljalo nobene rešitve kar se tiče opominjanja kupcev za plačilo. Opozarjali so jih ročno, preko e-pošte. Zdaj se bodo za to uporabljale funkcionalnosti rešitve Microsoft Dynamics Nava. Kupcem, ki jih želimo zajeti v proces opominjanja, je treba določiti metodo opominjanja z izbiro »šifre pogojev opomina«, pri odpiranju novega kupca. Opozarja se jih lahko večkrat in na več nivojih. Po navadi se uporablja 2- ali 3-nivojsko opominjanje, na primer:

1. opomin – blagi,

2. opomin – ostrejši,

3. opomin pred tožbo.

Lahko jih pripravimo paketno ali za vsakega kupca posamezno kot nepotrjen opomin. Ko stanje kupca in opomin pregledamo, ga potrdimo in pošljemo stranki. Kupcu lahko zaračunamo tudi pavšalni strošek za izstavitev opomina, ki ga po želji tudi samodejno knjižimo v glavno knjigo. Microsoft Dynamics Nav ponuja tudi možnost, da sočasno z opominom zaračunamo tudi zamudne obresti. Lahko se določi tudi znesek, pod katerim stranke ne bomo opominjali. Na analogen način se pripravljajo tudi bremepisi za zamudne obresti, pri čemer je treba kupcu nastaviti »šifro pogojev za bremepis«.

V standardni rešitvi Microsoft Dynamics Nav so trženjske aktivnosti podprte z različnimi funkcionalnostmi, ki so vključene v licenco, vendar ker trenutno te aktivnosti še niso zahtevane in ker so prioritete projekta najprej zagotoviti osnovne funkcionalnosti ERP sistema, predlagamo, da se te funkcionalnosti uvede postopoma in po koncu prvotnega projekta razen osnovne funkcionalnosti uporabe šifranta stikov, predlog in sinhronizacije podatkov med šifranti stikov, kupcev in dobaviteljev. Microsoft Dynamics Nav ponuja modul za upravljanje odnosov s strankami, njegove značilnosti so:

- Celovito upravljanje s stiki in dodatnimi segmentacijami in alternativnimi

naslovi. Stiki so lahko podjetja ali osebe, ki pripadajo podjetju ali ne.

- Celovito beleženje vseh interakcij s stiki (dokumenti ali samo telefonski

klic).

- Beleženje novih priložnosti in njihovo vodenje do faze ponudbe in

pridobitve naročila kot predprodajni postopek z ocenjevanjem utežene

vrednosti v smislu ocenjevanja vrednosti prodajnega procesa.

- Formalno vodenje prodajnega postopka po vnaprej določenih delovnih

tokovih.

- Uporaba vprašalnikov na podlagi iz Microsoft Dynamics Nav pridobljenih

podatkov ali ročno vnesenih podatkov. Tovrstne podatke lahko združimo

tudi v ocenjevalne indekse (meritve zadovoljstva kupcev).

- Integracija z Microsoftovim Outlookom.

- Vodenje trženjskih kampanj s posebnimi prodajnimi pogoji.



Microsoft Dynamics Nav omogoča integracijo z Microsoftovim Excelom in tako

ponuja vrsto običajnih poročil o prodaji po kupcih in artiklih. Po želji se podatke

lahko analizira tudi po drugih dimenzijah. Microsoft Dynamics Nav brezplačno

ponuja tudi Jet Reports Express, ki omogoča enostaven zajem podatkov v Excelu.

Mag. Goran Čop (osebna komunikacija, 22.5.2014)

5.2.1. USTVARJANJE PRODAJNEGA NAROČILA V MICROSOFT DYNAMICS NAVU

Kreiranje prodajnega naročila v Microsoft Dynamics Navu poteka popolnoma drugače. Za razliko od Exima se tukaj, kot glavna vhodna enota, ne uporablja tipkovnica, ampak računalniška miška. Seveda se enote vnašajo tudi s tipkovnico, vendar pa je samo premikanje po dokumentu mogoče z miško.

Slika 17: Gumb do seznama prodajnih naročil v Microsoft Dynamics Navu

Ko se prijavimo v sistem, nas pričaka domači zaslon, levo zgoraj pa lahko kliknemo na gumb “Prodajni nalog” in se s tem odpre novo izbirno okno.



Slika 18: Ustvarjanje prodajnega naročila v Microsoft Dynamics Navu

Enako kot pri Eximu tudi tukaj najprej izberemo številko kupca. Prednost je ta, da lahko začnemo kar s pisanjem v okence Št. kupca, samodejno se nam odpre šifrant kupcev, po katerem lahko brskamo po vsakem stolpcu posebej. Nastavi se lahko tudi privzeti stolpec, da nam ni treba vsakič spreminjati iskanja po želenem stolpcu.



Slika 19: Dodajanje pozicij na naročilo v Microsoft Dynamics Nav

Ko izberemo kupca oz. številko kupca, nam sistem sam določi zaporedno številko ustvarjenega dokumenta, izpolnijo se tudi vsi ostali podatki kupca. Vsi potrebni datumi se vnesejo samodejno, mi moramo vnesti še zahtevani datum dostave, št notranjega dokumenta, kar pomeni št. kupčevega naročila. Vnesemo še šifro prodajalca, v tem primeru ŽJ - Žiga Jamnik. Na desni strani lahko vidimo vso zgodovino prodaje temu kupcu, koliko ponudb smo mu izdali, koliko naročil smo že proizvedli zanj, skratka statistika za vse dokumente trenutnega kupca. Pod to tabelo pa lahko vidimo podrobnosti vrstice. Prikazuje nam razpoložljivost artikla, izbranega v vrstici.



Slika 20: Obdelava drugih pomembnih podatkov v naročilu

Ko smo izpolnili vse v zavihku Splošno, lahko preidemo na zavihek Vrstice. Sem se vnašajo postavke na prodajnem naročilu. Lahko vnesemo eno ali več postavk, ni omejitev. Imamo tudi možnosti kopiranja vrstic iz prejšnjih prodajnih naročil. Razlika med Eximom in Microsoft Dynamics Navom je ta, da se je pri Eximu samodejno prenesla samo vrstica ali več vrstic predhodnega dokumenta. Pri Microsoft Dynamics Navu pa lahko sami izberemo, iz katerega poljubnega dokumenta želimo prenesti vrstico. Omogoča nam tudi, da ne prenesemo samo vrstic prodajnega naročila, ampak lahko prenesemo vrstico iz katerega koli dokumenta – prodajnega, nabavnega, računa, dobavnice ... Pri polju “Vrsta” izberemo, da želimo prodati artikel, pri polju “Št.” se nam ponovno odpre šifrant vseh artiklov, znova lahko nastavimo, po katerem stolpcu želimo iskati. Ko izberemo artikel, se nekateri podatki, ki opisujejo izdelek, avtomatsko vnesejo v to vrstico. Eden takih podatkov je tudi opis, ki ga seveda lahko po želji tudi spremenimo. Veliko kupcev zahteva spremembo naziva izdelka (opis, ki bo napisan na etiketi izdelka), Microsoft Dynamics Nav omogoča tudi to, da je opis izdelka prirejen določenemu kupcu, da nam ga ni treba vsakič posebej spreminjati, ko ustvarjamo naročilo za določenega kupca.



Enako, kot z opisom, je tudi s ceniki. Cene ni treba vnašati ročno. Cenike se da nastaviti na določen izdelek, določenemu kupcu. Za spreminjanje cen lahko nastavimo nadzor, kar pomeni, da moramo za vsako spremembo cene pridobiti dovoljenje nadrejenega. Lahko pa nam tudi onemogoči ročno spreminjanje cen. Vnesemo želeno količino.

Slika 21: Opozorilna kartica pomanjkanja zaloge v Microsoft Dynamics Navu Odpre se pojavno okno – preveri razpoložljivost. Sistem nam javi, da je trenutna zaloga želenega proizvoda 0 kg in da bo stanje po končanem nalogu enaka -100 kg, ni mogoče. Pomeni, da bo sistem poslal naročilo v proizvodnjo. Ponudi nam tudi nadomestni proizvod, vendar jih za ta proizvod ni. Če se strinjamo, potrdimo.



Slika 22: Sledenje prodajnemu nalogu v Microsoft Dynamics Navu

V vrstici lahko vidimo tudi, kolikšno količino smo že odpremili in pa kolikšna količina še preostaja za fakturiranje. Vnesemo še želene datume, kdaj želimo, da je artikel na zalogi in pa načrtovani datum dobave. Sistem že sam iz 10-mestne govoreče kode potegne kar nekaj informacij in jih vnese v vrstico. Lahko jih tudi poljubno spreminjamo. Microsoft Dynamics Nav ima funkcijo, ki se ji reče navzkrižno sklicevanje. To pomeni, da skoraj vse podatke lahko prilagodimo glede na kupca in proizvod.



Slika 23: Spreminjanje podatkov na vrstici v Microsoft Dynamics Navu

Po vrstici se premikamo z drsnikom levo in desno, dokler ne izpolnimo vseh obveznih stolpcev. Izberemo načina pakiranja, vrsto etikete, število etiket, na koga naj bo etiketa na artiklu naslovljena ...



Slika 24: Določevanje plačnika na prodajnem naročilu v Microsoft Dynamics Navu

Premaknemo se na naslednji zavihek »Dodatno besedilo«, kjer lahko vnesemo poljubno besedilo, ki ga potem izpiše na izpisanih dokumentih. Pri stolpcu možnosti tiskanja lahko izberemo, ali se besedilo izpiše na materialnem ali finančnem dokumentu. Lahko pa izberemo, da se besedilo izpiše na obeh. Pri zavihku fakturiranje se večino podatkov prenese že iz šifre kupca. Izberemo samo šifro plačilnega pogoja z odprtjem šifranta za plačilne pogoje. Na koncu prodajnemu naročilu spremenimo status »odprto« v »izdano« in ga pošljemo v SVS in MES.



6. PROJEKT UVEDBE CELOVITE PROGRAMSKE REŠITVE V PODJETJE Da bi nadvse popolno izvedli uvedbo celovite programske rešitve Microsoft Dynamics Nav v podjetje, smo najprej morali analizirati obstoječe stanje in analizirati obstoječe procese. Bolj ko je analiza podrobna, boljša je predlagana rešitev. To je ena izmed najpomembnejših faz uvajanja celovite programske rešitve, saj ima s tem organizacija tudi priložnost prenoviti ali spremeniti obstoječe procese. Najprej smo določili projektno vodjo, ključne uporabnike in analiste, ki bodo sodelovali v projektu uvedbe. Kot projektno vodjo smo določili tehničnega direktorja podjetja, ključni uporabniki so bili izbrani posamezniki vsakega oddelka v podjetju, analisti pa so bili vsi končni uporabniki oziroma delavci v oddelkih, ki so lahko vsako spremembo testirali in jo ocenili. Dogovorili smo se za način dela in kako bomo medsebojno komunicirali. Najprej smo se dobivali na rednih tedenskih sestankih, nato smo komunikacijo prenesli na spletno pošto in Atlassian JIRO. Določili smo naloge in terminski načrt in se tako omejili, da se projekt uvedbe ne bi zavlekel. Terminski načrt nam omogoča, da imamo pregled nad celotno uvedbo, tako smo točno vedeli, če smo zamujali s kakšno fazo. Zelo pomembno je zastaviti naloge ter zadolžitve, tako da smo vsi vključeni v projekt točno vedeli, kaj, kdaj in kako morajo biti naloge opravljene. Določili smo tudi datum go-live, ki je bil takrat nastavljen na 1. 1. 2015, vendar smo ga morali najprej zaradi številnih ovir prestaviti na 1. 1.2017, nato pa na 1. 3. 2017.



Slika 25: Terminski načrt projekta



Z našimi ključnimi uporabniki in poslovnimi partnerji podjetja, ki uvaja Microsoft Dynamics Nav, smo pripravili analizo obstoječega stanja, iz katerega so poslovni svetovalci pripravili predlog rešitve za organizacijo, v katerem so bili podrobno opisani poslovni procesi podjetja, in sicer: finance in računovodstvo, prodaja in trženje, nabava, proizvodnja, skladiščno poslovanje, servis in vzdrževanje ter kadrovski proces. Po podrobnem pregledu pripravljene predloge smo po nekaj popravkih dosegli sporazum glede predlagane rešitve. Na strežnik podjetja so nam vzpostavili testno okolje oziroma standardno verzijo Microsoft Dynamics Nava, ki pa takrat še ni bila prilagojena našemu podjetju. Ko smo se ključni uporabniki prvič prijavili v sistem, smo počasi ugotavljali, kaj vse bo treba spremeniti, da bi sistem prilagodili našemu delovanju. Vse ideje za spremembe smo si zapisali in o njih na tedenskih sestankih poročali poslovnim svetovalcem podjetja, ki uvaja, ki so tako postopoma izpopolnjevali celovito programsko rešitev. Ker je bilo treba spremembe za nemoteno delovanje opraviti hitro, smo uvedli dnevne sestanke, saj so nam bili tako zagotovljeni ažurni popravki. Pri tem smo si pomagali z Atlassian JIRO, saj nam je omogočala lažjo komunikacijo in bolj ažurne spremembe podatkov tudi v primeru, če tisti dan nismo imeli sestanka. Ko smo celovito programsko rešitev izpopolnili v tej meri, da smo jo lahko uporabljali, smo začeli z migracijo podatkov (ki je podrobneje opisana v naslednjem poglavju), plačilnih pogojev in poslovnih partnerjev, ki je ena ključnih stvari pri prehodu z obstoječe celovite programske rešitve na novo. Ker so v proizvodnem podjetju osnova proizvodni postopki in kosovnice, smo uvedbo morali začeti tukaj. S tem se meri poraba in tako računa lastna cena proizvodov. Za tem smo lahko začeli polniti šifrante proizvodov, dodali smo vse artikle, saj organizacija proizvaja 19.188 artiklov. Za proizvodni del je bil odgovoren MES, potrebno je bila še integracija z MES sistemom. Po integraciji z MES sistemom smo naredili še integracijo s SVS-jem, ki je dobro skrbel za potrebe skladiščenja, in se odločili, da ga bomo uporabljali tudi naprej. Treba je bilo prenoviti in uvoziti šifrante pakiranj in etiket. Exim je bil vpeljan 30 let nazaj, zato smo imeli drugačno logiko šifriranja v podjetju. Ker pa sistem takrat ni omogočal zapletenih sprememb, so šifranti ostali taki, kot so bili ustvarjeni na začetku, spreminjalo pa se jih ni. Na prodajni strani smo lahko po uvozu kupcev in prejemnikov ustvarili prvo prodajno naročilo z dejanskim artiklom, ki ga proizvaja podjetje. Seveda je bilo pred tem treba vsem kupcem nastaviti plačilne pogoje. Prodajnega naročila nismo veliko spreminjali, ker je že standardni Nav pokril precej potreb prodajnega procesa v organizaciji, treba pa je bilo dodelati skladiščno dobavnico, ki je v Navu sicer mišljen kot skladiščni in ne prodajni dokument. Gola skladiščna dobavnica ni ponujala veliko.



Slika 26: Skladiščna dobavnica pred predelavo



Slika 27: Skladiščna dobavnica po predelavi



Dodati smo morali komentarje, ki se izpišejo na skladiščni dobavnici, ko jo natisnejo v skladišču, in komentarje, ki se dodajo na tovornem listu. Na skladiščni dobavnici nismo videli kupca, prejemnika in dostavnega mesta, zato smo morali dodati tudi to. Glede na to, da prodaja podjetja poteka v večini preko agentov, smo morali dodati tudi agenturo, ki je opisana je v poglavju 6.4. Na žalost Microsoft Dynamics Nav nima modula, ki bi pokrival proces reklamacij, zato jih bo podjetje moralo obravnavati enako, kot so jih obravnavali do zdaj, preko Excelovih listov. Reklamacije, ki zahtevajo vračilo proizvodov, bodo pokrite z Microsoft Dynamics Nav funkcijo vračilnih nalogov. Večkrat je bilo treba urediti izpise vseh dokumentov. Takoj po izdelavi prvega prodajnega naročila smo lahko natisnili izpis potrditve naročila, naročila proizvodnji, računa, dobropisa in vračilnega naloga, vendar so se izpisi po nekaj mesecih precej razlikovali, ker smo dodajali stvari, ki jih potrebujemo za potrebe podjetja, in odstranjevali stvari, ki jih podjetje ne potrebuje. Vsak dan smo opažali pomanjkljivosti oziroma prednosti, ki bi olajšale delo zaposlenim in ga s tem stalno izboljševali in izpopolnjevali.

Slika 28: Januarski graf odprtih in rešenih nalog v Atlassian JIRI

6.1. MIGRACIJA PODATKOV Stvar je precej preprosta, treba je prenesti oziroma migrirati določene podatke (stike, kupce, prejemnike, plačilne pogoje) iz starega v nov sistem. Problem nastane, ko je eden od sistemov iz leta 90 in drug sistem 20 let mlajši. Vse podatke se da preprosto izvoziti iz Exima v MS Excel in potem prenesti v nov sistem preko istega Excelovega dokumenta, vendar pa je nov sistem drugačen. Podatke moramo



spremeniti, prilagoditi, preden se jih vnese v nov sistem. Preveriti in posodobiti smo morali okoli 1000 različnih kupcev/prejemnikov.

Slika 29: Diagram poteka izvoza in uvoza podatkov

V Eximu obstaja samo 1 šifrant poslovnih partnerjev, ki vsebuje vse: kupce, prejemnike, nabavne partnerje, kar je pomenilo, da ne glede na to, kateri dokument smo ustvarili, smo lahko uporabili katerokoli dostavno mesto. Microsoft Dynamics Nav pa ima drugačno logiko. Za prodajna in nabavna naročila uporablja skupni šifrant, za prejemnike pa uporablja svojega, ki je povezan s šiframi kupcev in nabavnih partnerjev. Ko izberemo novo prodajno naročilo, lahko izberemo kateregakoli kupca in potem s preprostim »drop-down« menijem izberemo prejemnika oziroma dostavno mesto, ki pripada kupcu, ki smo ga izbrali. Prednosti uvoza poslovnih partnerjev v Microsoft Dynamics Nav2013R2 so:

- Vsi poslovni partnerji bodo ažurirani (partnerji, ki so v sistemu starejši od

1. 1. 2013, se ne bodo prenašali, ampak se bodo, v primeru, da

organizacija ponovno začne sodelovati z njimi, ponovno odprli).

- Vsi podatki o poslovnih partnerjih bodo ažurirani (vsi podatki od partnerjev

– ime, naslov, davčne številke – se bodo preverili in po potrebi osvežili).

- Lažja izdelava novih naročil v novem sistemu.

6.2. MIGRACIJA POSLOVNIH PARTNERJEV Podjetje se je odločilo, da prenesemo samo poslovne partnerje, ki so mlajši od 1. 1. 2013. Prenašali bomo naslednje podatke vsakega partnerja:

- šifra partnerja, ki je določala zaporedno številko partnerja v Eximu (ID),

- država partnerja,

- pošta,

- TRR,

- naziv 1,

- naziv 2,

- naslov,

- kraj,

- IDDV,

Izvoz podatkov iz

Exima v Excelov

dokument

Pregled in obdelava podatkov

Uvoz podatkov v Microsoft Nav Vision



- davčni zavezanec (da/ne).

Po končanem sestanku in narejeni raziskavi poslovnih partnerjev se je izkazalo, da je vseh partnerjev v Eximu 12.107. To je zelo obsežen šifrant, vsebuje vse partnerje, tudi tiste, ki niso bili aktivni več let. Odstranili smo še tiste partnerje, ki so bili starejši od 1. 1. 2013. Seznam smo precej oklestili in se tako rešili ogromno nepotrebnih vrstic v Excelu. Iz 12.107 vrstic (vsaka vrstica je vsebovala podatke o enem poslovnem partnerju) smo prišli na 2.378 vrstic. Šifrant se je zmanjšal za 5-krat. 9.729 neaktivnih partnerjev je ostalo v Eximu, vendar se jih ni preneslo v Microsoft Dynamics Nav. Šifrant partnerjev je bil uporabljen s strani nabavnega in prodajnega oddelka in glede na to, da je bil šifrant samo en, je sledilo urejanje šifranta po štirih dejavnikih (izdan račun kupca, izdan račun prejemnika, prejeti račun, izdana naročila). S tem smo pridobili dvoje: ugotovili smo, kateri partnerji zadevajo nabavni proces in kateri zadevajo prodajni proces. Tisti, ki so imeli kljukico pri »izdan račun kupca« so bili kupci, tisti, ki so imeli »izdan račun prejemnika« so bili prejemniki in pa tisti, ki so imeli kljukico pri »prejeti račun« so bili nabavni partnerji. Kljub temu da je bilo v šifrantu partnerjev kar 5-krat manj, jih je bilo še vedno ogromno, zato smo se odločili, da razdelimo šifrant in vsak oddelek je preveril »svoje« partnerje. Nabavni oddelek je v pregled podatkov prejel 1.187 partnerjev, prodajni oddelek pa razliko: 1.191 partnerjev. Sledilo je dolgo preverjanje podatkov partnerjev. Treba je bilo pregledati vsakega posebej, da bi bili podatki nadvse ažurni. V prodaji smo si prodajni referenti šifrant razdelili med seboj – po državah, tako kot je tudi razdeljeno redno delo. Primer: prodajni referent, ki dela z nemškimi partnerji, je prejel v pregled nemške partnerje. Treba je bilo še razdeliti kupce in prejemnike. Ugotovili smo, da je kar nekaj partnerjev podvojenih, Exim žal ni imel zaščite, da bi preprečeval podvajanje podatkov, sicer so referenti sproti, ob odprtju novih partnerjev preverjali, ali mogoče tak partner že obstaja – da bi preprečili podvajanje. Pri prenosu podatkov v nov sistem smo naleteli na problem. Star sistem ni imel nobenih varoval glede imena, naslova ali poštne številke stikov, zato se je v seznam lahko vnašalo vse, brez omejitev. Pri tem pa so nastajale določene napake. Poštne številke se razlikujejo od države do države, zato je tukaj nastalo največ napak. Precej poštnih številk je vsebovalo pike ali ničle, ker je prišlo do primera, ko je imel isti naziv kraja v različnih državah. Microsoft Dynamics Nav ima svoj šifrant poštnih številk in jih je bilo zato potrebno vsako posebej prilagoditi. V Eximu je bil sistem tak, da je bila vnesena posebej država, poštna številka, mesto. V novem sistemu pa je logika malce drugačne, poštna številka se namreč zapiše v naslednjem vrstnem redu: šifra države, pomišljaj, poštna številka. Primer: SI-1000, kar določa državo in pa poštno številko v tej državi. Ko so bili podatki urejeni in posodobljeni, smo prejeli od podjetja, ki uvaja, Microsoft Excelov dokument, ki je bil v bistvu obrazec (predloga), v katerega smo potem kopirali urejene podatke iz Exima. To je bil obrazec, ki je poenostavil vnos partnerjev v nov sistem. Microsoft Dynamics Nav ima seveda možnost posameznega



vnosa novega partnerja, kar pa bi nam vzelo kar precej časa. Zato smo zapolnili Excelov dokument in so potem oni uvozili podatke v nov sistem in nam tako prihranili ogromno časa. V Eximu je imel vsak partner svojo šifro, »primarni ključ«, po katerem se jih je dalo iskati. Te šifre so bile od začetka zgolj naključne, sčasoma se jih je odpiralo po nekem ključu in tako so se odpirale tudi nove šifre kupcev/prejemnikov – naključno. Šifre so bile 5–mestne, in sicer od 1 do 99999. Ko nekaj časa delaš z vedno istimi partnerji, se šifer naučiš na pamet in uporabljaš samo še partnerjeve šifre. Exim je imel način, da je bilo pri kreiranju novega naročila treba vnesti njegovo šifro in ne ime, ki ga je potem sistem sam prekopiral iz šifranta. Pri uvozu podatkov v novo celovito programsko rešitev pa so se te šifre zamenjale.

Slika 30: Šifrant poslovnih partnerjev v Eximu, ki je bil izvožen v MS Excela



Slika 31: Izvožen šifrant iz Exima v MS Excel



Slika 32: Uvožen šifrant kupcev v Microsoft Dynamics Nav



S tem pa uvažanje poslovnih partnerjev še ni končano, kajti na ta način smo uvozili samo kupce, še vedno pa nismo imeli uvoženih prejemnikov. V Eximu smo imeli skupni šifrant za kupce ter prejemnike, v Microsoft Dynamics Navu pa smo morali vsakemu kupcu določiti njegova dostavna mesta. Na spodnji Sliki 33 vidimo Excelov dokument, ki nam ga je uvajalna ekipa pripravila za vnos prejemnikov, le-ta je bil malenkost drugačen od prejšnjega dokumenta. V prvi stolpec smo morali vpisati številko kupca (nova šifra – v novem sistemu), v naslednje pa določene podatke o prejemniku. Vsak kupec ima lahko enega ali več prejemnikov. Na srečo smo imeli možnost izvoziti podatke o tem, kateri kupec je imel katerega prejemnika do zdaj. Vseh prejemnikov oz. dostavnih mest skupaj je bilo 1009.



Slika 33: Dokument za uvažanje dostavnih mest



Tako smo imeli Eximov seznam kupcev in njihovih dostavnih mest, ki jih je bilo treba vnesti v novo programsko rešitev s tem, da so morali imeti kupci nove šifre kupcev. Treba je bilo sinhronizirati stare šifre kupcev z novimi, potem pa jim dodati dostavna mesta. Potem ko sta se nov in star seznam kupcev ujemala, smo samo še skopirali prejemnike v seznam prejemnikov. Ponovno je nastal problem pri poštnih številkah, ki smo ga morali odpravili tako, da smo poštne številke spremenili ročno – vsako številko posebej. Po končanem uvozu poslovnih partnerjev smo imeli sestanek glede ažuriranja poslovnih partnerjev. Vsak dan se odpre več novih šifer kupcev oziroma prejemnikov. Za odpiranje novega poslovnega partnerja ali pa spreminjanje le-tega je bil ustvarjen dokument (obrazec), ki se ga natisne in izpolni. Obrazec lahko vidimo na Sliki 34. Na obrazcu se izpolni:

- ime,

- naslov,

- naslov 2,

- poštna številka,

- mesto,

- šifra države,

- davčna številka (v primeru, da gre za kupca)

- podpis,

- datum.



Slika 34: Obrazec za odpiranje oziroma spreminjanje poslovnega partnerja

Izpolnjen obrazec se pošlje po telefaksu v oddelek računovodstva, kjer najprej preverijo vse podatke, potem pa odprejo novo šifro kupca/prejemnika. Postopek traja približno 5–10 minut, odvisno od tega, ali smo »odprli« novega kupca ali prejemnika. Pri prejemniku načeloma ni veliko preverjanja, pri kupcu pa preverijo še davčno številko (če je kupec v območju EU).



Odločili smo se, da bomo, glede na to, da Microsoft Dynamics Nava še ne uporabljamo, odpirali šifre poslovnih partnerjev enako, kot smo jih odpirali do zdaj, torej s pomočjo obrazca. Šifre novih kupcev in prejemnikov se bodo še naprej odpirale v Eximu, v nov sistem pa bomo vnesli samo šifre novih kupcev, novih šifer prejemnikov pa ne. Ker želimo imeti ažurirana oba sistema, bodo šifre novih prejemnikov enkrat mesečno, na začetku meseca, uvožene iz Exima v novo celovito programsko rešitev.

6.3. MIGRACIJA PLAČILNIH POGOJEV Zaradi velikega števila kupcev in prejemnikov podjetje uporablja precej različnih plačilnih pogojev, ki so se dodajali zaporedoma več let. Skoraj vsakič, ko smo odprli novega kupca, smo odprli tudi nov plačilni pogoj oz. poimenovali smo jih kar plačilne klavzule. Kar nekaj kupcev lahko za plačilo uporablja tudi enake klavzule. V Eximu se te klavzule vpiše v različne vrstice, kot je to razvidno na Sliki 35. Razlog, zakaj so ene klavzule zapisane v eni vrstici druge v dveh in pa nekatere v treh je, da je v vsako vrstico posebej mogoče napisati določeno število znakov, potem pa je treba odpreti novo vrstico in vanjo vpisati besedilo, ki se nadaljuje. Naročila, fakture, dobropisi se izpišejo v dveh jezikih: slovenščini in angleščini, kar je pomenilo, da smo morali vsako klavzulo odpreti v dveh različnih jezikih.

Slika 35: Primer izvoženih plačilnih klavzul

Plačilne klavzule smo, tako kot smo šifrant kupcev in prejemnikov, izvozili v Excel in začeli z urejanjem le-teh. Po izvozu vseh klavzul v Excel smo ugotovili, da je vseh skupaj 420. Tudi tukaj smo se odločili, da prenesemo samo tiste podatke, ki so se uporabljali po 1. 1. 2013. Pri izvozu pa smo naredili tudi manjšo analizo število uporabljenih klavzul, pri kateri se je izkazalo, da se je precej klavzul uporabljalo zelo malo. 138 klavzul se je na primer uporabilo v dokumentih samo enkrat, 53 klavzul se je uporabilo dvakrat in 60 se jih je uporabilo zgolj dva do petkrat. Naredili smo poizvedbo klavzul oziroma vrstic klavzul, ki so se uporabile po 1. 1. 2013, aktivnih je bilo 204 vrstic, ki so bile uporabljene v 99 različnih plačilnih klavzulah.



Slika 36: Prvi izpis plačilnih klavzul iz Exima v Excel



Slika 37: Urejanje klavzul po aktivnostih (starejše od 1. 1. 2013)



Nova celovita programska rešitev Microsoft Dynamics Nav prinaša v podjetje inovacijo, kar se tiče plačilnih pogojev. Enako kot v Eximu lahko dokumente kopiramo v več jezikih (slovenskem in angleškem), vendar za to ne potrebujemo podvojenih plačilnih klavzul s podvojenim besedilom, samo v drugem jeziku. Preprosto se vnese klavzula, komentar klavzule pa se doda v dveh verzijah: v slovenskem in angleškem komentarju. Število urejenih plačilnih klavzul, pripravljenih za uvoz v nov sistem se je zato znižal skoraj na tretjino. Vseh klavzul, potrebnih za uvoz je bilo namreč po urejanju 77. Na Sliki 38 si lahko ogledamo urejene plačilne klavzule, ki so bile pripravljene na uvoz v nov sistem.



Slika 38: Za uvoz pripravljene urejene plačilne klavzule



V Eximu te plačilne klavzule niso imele funkcije. Samo natisnjene so bile na papir, ker Exim ni znal sam izračunati datuma glede na plačilno klavzulo. Pri novem sistemu pa so te klavzule imele zelo pomembno funkcijo. Spet smo podatke migrirali s pomočjo uvajalne ekipe, ki nam je pripravila Excelov list za uvoz podatkov v nov sistem, vendar so se lahko prenesli podatki:

- ime klavzule,

- slovenski komentar,

- angleški komentar.

Vsako plačilno klavzulo je bilo treba še sprogramirati, na primer plačilna klavzula BERNARDI pomeni, da ima kupec za plačilo 90 dni neto, če pa plača v naslednjih 14 dneh pa plača s popustom –2 %. V Microsoft Dynamics Nav smo morali vnesti v stolpec “formula datuma zapadlosti” 90D – kar pomeni 90 dni, v stolpec “izračun datuma popusta” smo vnesli 14D – kar pomeni, da se popust obračuna, če je plačano v 14 dneh in pa v stolpec “Popust %” smo morali za to klavzulo vnesti 2. Tako nam torej sistem omogoča, da sam obračuna popust, če je faktura plačana v 14 dneh ali prej - vse to lahko vidimo spodaj.



Slika 39: Vnesene plačilne klavzule v Microsoft Dynamics Nav



Problem je nastal pri klavzulah, ki so bile vezane na ladijske dokumente “Bill of Lading”. Sistem namreč ne ve, kdaj je bil izdan ladijski dokument B/L. Odločili smo se, da bomo pri tej klavzuli upoštevali 30-dnevni plačilni rok, ter 10 dni za izdajo ladijskega dokumenta. Torej 40 dni od datum izdaje fakture. Ko smo v celovito programsko rešitev migrirali vse podatke, smo lahko nadaljevali s preizkušanjem in dopolnjevanjem potreb oziroma, katere funkcije še potrebujemo, da bo program pripravljen za naše poslovanje.

6.4. UVEDBA AGENTURE Program agenture standardno ni podprt v Microsoft Dynamics Navu, zato ga je bilo treba dodelati. Podjetje v veliki večini prodaja preko posrednikov oziroma agentov. To pomeni, da naročila prihajajo s strani agentov, oni pa si pri tem zaračunajo določen odstotek provizije. Na kartico dobaviteljev smo dodali okvirček za označbo, ali je dobavitelj tudi agent. Vsem kupcem, ki poslujejo preko agentov, smo morali označiti, kdo je njihov agent (številko dobavitelja). Na kartico kupcev smo dodali okvirček, kamor lahko vpišemo povprečno ceno transporta na kilogram papirja, ker naše prodajne cene vsebujejo tudi strošek prevoza in se mora potem ta odbiti od prodajne cene, da se jim lahko izračuna provizija. Pri vsakem kupcu je bilo treba določiti tudi odstotek provizije za vsakega agenta. Upoštevati smo morali, da mora biti knjižen izdan račun tudi plačan, preden je bil agent upravičen do svoje provizije. Program je bil uvožen v Microsoft Dynamics Nav, zagnali smo »Agent provision«, določili, za katerega agenta želimo in tako nam je program odprl nabavno naročilo, ki ga pošljemo agentu v pregled. Ko agent potrdi, se mu lahko izplača provizija.



7. VREDNOTENJE UVEDBE CELOVITE PROGRAMSKE REŠITVE Čas uvedbe Microsoft Dynamics Nava je bil v tem primeru (pre)dolg. Podaljšal se je predvsem zaradi težav na strani proučevanega podjetja. Projekt smo začeli že leta 2014 in upajmo, da bo organizacija realizirala »go-live« s 1. 3. 2017. Zanimivo je, kako smo standardno ponujeno različico Microsoft Dynamics Nav dodelali do te mere, da jo lahko že uporabljamo in da je konkretno prilagojena podjetju.

7.1. KOMENTARJI UPORABNIKOV Uporabnik 1: »Nova celovita programska rešitev je v primerjavi s starejšo veliko bolj uporabna in pregledna. Najpomembnejša prednost je opozarjanje delavca na mogoče napake. V primeru, da ob vnosu naročila v sistem vnesem včerajšnji datum, me program opozori in samodejno popravi napako. Najbolj mi je všeč funkcionalnost, navzkrižno sklicevanje, ki mi olajša vnašanje podatkov za enakega kupca vedno znova. Preprosto izberem kupca, izberem artikel in vnesem, katere podatke sistem vedno vnese pri naročilu za tega kupca in tega proizvoda.« Uporabnik 2: »Kot vodja prodajnega področja najbolj opazim razliko med novim in starim sistemom, da lahko kakršnokoli informacijo dobim iz sistema kadarkoli. Poročanje v Microsoft Dynamics Navu je precej lažje, kot smo ga imeli v Eximu. Tam je bilo treba narediti izpis, ga izvoziti na računalnik iz programa po določenem protokolu in ga potem odpreti v Microsoftovem Excelu. Podatke je bilo treba še ločiti, ker so bili med seboj povezani s podpičjem. Po tem, ko smo podatke uvozili v Microsoft Excel, pa smo šele lahko začeli z obdelovanjem le-teh. Pri Microsoft Dynamics Navu se samo pomaknem na zavihek »poročanje« in že lahko obdelujem podatke. Drug, mogoče še lažji način je, da kliknem na želenega kupca, na tipkovnici pritisnem »ctrl« + »e« in se mi odpre vsa zgodovina kupca v Microsoftovem Excelu. Prihrani mi ogromno časa in živcev. Moti pa me, da se nismo uskladili glede cenikov, kajti naš proces prodaje je kompliciran. Prepričan sem, da bi artikle uspeli zbrati v skupine in potem kot skupinam določili cene in tako lažje nadzorovali, saj se tako izognemo napakam izpod človeških rok.«

7.2. MOŽNOSTI NADALJNJEGA RAZVOJA Organizacija namerava v kratkem zamenjati tudi spletno stran, na katero bi lahko dodali še možnost prijave kupcev oziroma agentov in jim s tem omogočili, da bi naročila vnašali v proizvodnjo kar sami, seveda bi se morala ta naročila preverjati, Microsoft Dynamics Nav pa bi jih lahko vstavil v proizvodnjo sam, glede na razpoložljivost. Organizaciji je bil ta modul ponujen, vendar se za to nismo odločili.



8. PRIPOROČILA

8.1. SKLEP Še kar nekaj časa in dela bo potrebno, da bo Microsoft Dynamics Nav v celoti vpeljan in bo zadostil vsem zahtevam organizacije. Organizacija bi rada sistem uvedla kvalitetno in se s tem izognila kasnejšim problemom. Najbolj problematičen del je integracija z MES sistemom, ki skrbi za proizvodnjo in planiranje le-te. S strani prodaje je obvezna dodelava cenikov. Na žalost nam uvajalna ekipa ni mogla razvrstiti artiklov v skupine, da bi lahko določili cene po kupcih na določene skupine artiklov. Glede na to, da se cene spreminjajo kvartalno, bi bilo mnogo preveč dela, da bi spreminjali ceno 6.588 artiklom, ki se jih prodaja. Zagotovo pa se bo uredilo tudi to.



LITERATURA IN VIRI Agilne metode razvoja programske opreme (2016).

https://sl.wikipedia.org/wiki/Agilne_metode_razvoja_programske_oprem

e (27. 11. 2016)

Aptean (2016), By virtually any measure, ERP software sales are healthy and

growing: http://www.aptean.com/additional-crm-and-erp-related-links-

pages/erp-resources-folder/erp-software-sales, (10. 1. 2016)

BPMlab (2016), Celovite programske rešitve:

http://www.bpmlab.si/index.php?option=com_content&view=article&id=

56:celoviteprogresitve&catid=37:mpp-izvedba&Itemid=57, (10. 1. 2016)

Cotterell, M. in Hughes, B. (1995). Software project management, International

Thomas Computer Press, London.

Dahlén, C. in Elfsson, J. (1999). An Analysis of the current and future ERP Market,

Master's Thesis Industrial Economics and. Management.

Datacor (2016), ERP and CRM: http://datacorinc.com/articles/news/erp.pdf,

(10. 1. 2016)

Dajčbauer, L. (2009). Primerjalna analiza ERP sistemov Microsoft Dynamics Nav in

SAP-a (Diplomsko delo). Ekonomsko-poslovna fakulteta, Maribor.

Enterprise resource planning (2016).

https://en.wikipedia.org/wiki/Enterprise_resource_planning, (27. 11.

2016)

Erjavec, J., Popovič, A. in Trkman, P. (2013). Uporaba poslovno-informacijskih

rešitev, Copis, Ljubljana.

Finance (2016), Pospešiti inovacije, prebuditi rast:

https://beta1.finance.si//files/2006-03-22/sap_057_mar_2006.pdf, ,

(8. 2. 2016)

Gartner's ERP Market Share Update Shows The Future Of Cloud ERP Is Now (2016).

https://www.forbes.com/sites/louiscolumbus/2014/05/12/gartners-erp-market-

share-update-shows-the-future-of-cloud-erp-is-now/#4d6d6e7d1fae,

(27. 11. 2016)

Jeromel, T. (2010). Uvajanje informacijske rešitve Microsoft Dynamics Nav na

primeru podjetja Gozdno gospodarstvo Slovenj Gradec (Diplomsko delo).

Ekonomsko-poslovna fakulteta, Maribor.

https://sl.wikipedia.org/wiki/Agilne_metode_razvoja_programske_opreme%20(27

https://sl.wikipedia.org/wiki/Agilne_metode_razvoja_programske_opreme%20(27



Kovačič, A. in Bosilij-Vukšić, V. (2005). Management poslovnih procesov: prenova in

informatizacija poslovanja s praktičnimi primeri, GV Založba, Ljubljana.

Kovačič, Andrej et al. (2002). Prenova in informatizacija poslovanja, Ekonomska

fakulteta, Ljubljana.

Lenart, G., Pucihar, A., Sudzina, F. (2009). Znacilnosti podjetij pri uvajanju

celovitih poslovnih programskih resitev. Nove Tehnologije, Novi Izzivi, 862-

868.

Nicolàs Lorente, L., Nicolàs Lorente, C. (2013). Implementing Microsoft Dynamics

NAV 2013. Olton, Birmingham, GBR: Packt Publishing Ltd.

Povalej, V. (2007). Kako zmanjšati bolečine ob postavljanju celovitih informacijskih

rešitev, Uporabna informatika, XV(4).

Prometna informatika (2016), Informacijski sistemi – osnove: http://www.fg.uni-

mb.si/predmeti/pi/PI-1_ISvPrometu-Osnove.pdf, (10. 1. 2016)

Strateški načrt informatizacije poslovanja podjetja (2016), Obravnava strateškega

načrtovanja informatike v praksi (straškega načrta):

www.buyitc.si/downloadfile.aspx?fileid=791, (27. 11. 2016)

Technology Evaluation Centers (2016), ERP: Origins, Develpoments, and Trends:

http://www.technologyevaluation.com/research/article/ERP-Origins-

Developments-and-Trends.html, (8. 2. 2016)

Truffle100 (2016), European software vendors ranking 2015:

http://www.truffle100.com/2015/ranking.php, (10. 1. 2016)

Waterfall model (2015), Supporting

arguments:https://en.wikipedia.org/wiki/Waterfall_model, (27. 11. 2016)



KAZALO SLIK Slika 1: Diagram ERP modulov .................................................................................. 3 Slika 2: Grafični prikaz deleža vrednosti ERP ponudnikov ........................................ 6 Slika 3: Prikaz modela Waterfall ............................................................................ 10 Slika 4: Agilna metodologija .................................................................................. 11 Slika 5: Vstopna stran Microsoft Dynamics Nava .................................................... 17 Slika 6 Model prodajnega procesa podjetja X ........................................................ 18 Slika 7: Vstopna stran Exima .................................................................................. 22 Slika 8: Premikanje po direktorijih Exima .............................................................. 22 Slika 9: Eximovo prodajno področje ....................................................................... 23 Slika 10: Obstoječa naročila v Eximu ..................................................................... 24 Slika 11: Prva stran prodajnega naročila v Eximu .................................................. 24 Slika 12: Določanje plačilnih klavzul na prodajnem naročilu v Eximu .................... 26 Slika 13: Druga stran prodajnega naročila v Eximu ................................................ 26 Slika 14: Tretja stran prodajnega naročila v Eximu ............................................... 27 Slika 15: Vstavljanje postavk na naročilo v Eximu ................................................. 27 Slika 16: Komentarji na prodajnem naročilu v Eximu ............................................ 28 Slika 17: Gumb do seznama prodajnih naročil v Microsoft Dynamics Navu ............ 33 Slika 18: Ustvarjanje prodajnega naročila v Microsoft Dynamics Navu .................. 34 Slika 19: Dodajanje pozicij na naročilo v Microsoft Dynamics Nav ......................... 35 Slika 20: Obdelava drugih pomembnih podatkov v naročilu ................................... 36 Slika 21: Opozorilna kartica pomanjkanja zaloge v Microsoft Dynamics Navu ....... 37 Slika 22: Sledenje prodajnemu nalogu v Microsoft Dynamics Navu ........................ 38 Slika 23: Spreminjanje podatkov na vrstici v Microsoft Dynamics Navu ................. 39 Slika 24: Določevanje plačnika na prodajnem naročilu v Microsoft Dynamics Navu

............................................................................................................................... 40 Slika 25: Terminski načrt projekta ......................................................................... 42 Slika 26: Skladiščna dobavnica pred predelavo ...................................................... 44 Slika 27: Skladiščna dobavnica po predelavi .......................................................... 45 Slika 28: Januarski graf odprtih in rešenih nalog v Atlassian JIRI ........................... 46 Slika 29: Diagram poteka izvoza in uvoza podatkov ............................................... 47 Slika 30: Šifrant poslovnih partnerjev v Eximu, ki je bil izvožen v MS Excela ........ 49 Slika 31: Izvožen šifrant iz Exima v MS Excel ......................................................... 50 Slika 32: Uvožen šifrant kupcev v Microsoft Dynamics Nav .................................... 51 Slika 33: Dokument za uvažanje dostavnih mest .................................................... 53 Slika 34: Obrazec za odpiranje oziroma spreminjanje poslovnega partnerja ........ 55 Slika 35: Primer izvoženih plačilnih klavzul ........................................................... 56 Slika 36: Prvi izpis plačilnih klavzul iz Exima v Excel ............................................. 57 Slika 37: Urejanje klavzul po aktivnostih (starejše od 1. 1. 2013) ......................... 58 Slika 38: Za uvoz pripravljene urejene plačilne klavzule ....................................... 60 Slika 39: Vnesene plačilne klavzule v Microsoft Dynamics Nav .............................. 62



KRATICE IN AKRONIMI ERP: Enterprise resource planning: poslovno-programska oprema za opravljanje aplikacij IS: Information System: informacijski sistem MRP: Material Requierments Planning: sistem za načrtovanje proizvodnih materialov ROP: Record Point: sistem točk ponovnega naročanja

uvedba celovite programske reŠitve microsoft … · ( c rm ) administracija, ( ] v oµ Î ,...

Documents