Kako poteka projekt uvedbe ERP v slovenskem podjetju

Projekt ERP v večini podjetij ne propade zaradi izbire programa, temveč zaradi načina, kako je voden. Ena faza se izpusti, druga se zamakne, tretja ostane brez lastnika, in nenadoma je zagon v času, ko ga nihče ne zmore. Ta vodnik razčleni projekt ERP na njegove korake, da lahko direktor, finančni vodja ali vodja informatike ob vsaki fazi ve, kaj se od njih pričakuje, kaj mora ob koncu obstajati na papirju in kje se običajno zatakne.

Besedilo velja za mala in srednje velika podjetja v Sloveniji, ki uvajajo ERP prvič ali zamenjujejo staro rešitev. Če šele spoznavate osnove, začnite s člankom Kaj je ERP, nato pa se vrnite sem.

Pregled: devet korakov uvedbe ERP

Pod imenom »mesečni načrt« se pogosto skriva ena sama misel: da je uvedba linearna. V resnici se mesta ERP (uvedba, vpeljava, implementacija) razporedijo v naslednje korake, ki se prekrivajo in imajo vsak svoj izdelek.

Poglejmo vsakega posebej.

1. Priprava in opredelitev projekta

Cilj. Pred kakršnim koli iskanjem programa je treba odgovoriti na vprašanje, zakaj sploh uvajate ERP. Razlogi so lahko različni: ročno prepisovanje med preglednicami, zamude pri zaključkih, nepregledna zaloga, rast, ki jo stari program ne zmore, ali zahteve odjemalcev glede e-računov. Vsak razlog vodi do drugačnih meril.

Izdelki.

• kratek dokument s poslovnimi cilji, ki jih je mogoče preveriti (na primer »zaključek meseca brez ročnega usklajevanja«);
• obseg: katere družbe, lokacije, skladišča, moduli in procesi so v projektu in kateri niso;
• projektna skupina z imenovanim vodjo in naročnikom na ravni uprave;
• okvirni proračun in omejitve, ki jih podjetje pozna samo: sezonska obdobja, revizije, dopusti.

Pasti.

• Projekt se prepusti informatiki, čeprav je poslovni. Če vodja financ, prodaje in skladišča ne sedijo za isto mizo, ERP postane orodje enega oddelka.
• Cilji so splošni (»digitalizacija«), zato jih po zagonu ni mogoče izmeriti.
• Nihče nima časa. Ključni uporabniki morajo za projekt dobiti prosti čas v delovnem urniku, ne po delovnem času.

Za pisanje zahtev uporabite članek Predloga zahtev za ERP, za razmislek o stroških pa Cena ERP.

2. Izbira rešitve in izvajalca

Cilj. Izbrati ERP, ki ustreza procesom, in izvajalca, ki ga zna uvesti v panogi, kot je vaša. Sta dve ločeni odločitvi. Odličen program v rokah slabega izvajalca daje slab rezultat, in obratno ni nikoli povsem res.

Izdelki.

• seznam zahtev z razvrstitvijo na nujne, zaželene in odložljive;
• primerjava dveh do treh kandidatov na podlagi predstavitve vaših scenarijev, ne splošne demonstracije;
• ponudba, v kateri so obseg, predpostavke, vloge obeh strani in način obračuna jasno zapisani;
• reference, ki jih lahko sami preverite pri podjetjih podobne velikosti in panoge.

Pasti.

• Odločitev na podlagi cene licence. Strošek uvedbe, prilagoditev in kasnejšega vzdrževanja ima običajno večjo težo kot licenca sama.
• Predstavitev na pripravljenih podatkih. Zahtevajte, da izvajalec prikaže vaš tipičen primer: nabavo z več dobavitelji, partijsko sledljivost, serijo, vezano na kupca.
• Pozabljena lokalna vsebina. Preverite, kako rešitev podpira slovenski kontni načrt, obračun DDV, izdajanje in prejemanje e-računov ter, kjer je to potrebno, davčno potrjevanje računov.

Na tej točki lahko pomagajo vodniki Kako izbrati ERP in Izbira ERP integratorja. Pri nas lahko oddate povpraševanje in vas povežemo z izvajalcem; kako to poteka, je opisano na strani Kako deluje. Svojih izvedbenih storitev ne ponujamo: projekt izvede izbrani integrator.

3. Zasnova ciljnih procesov

Cilj. Pred nastavitvijo je treba vsak proces opisati tako, kot bo potekal v novem sistemu. Zasnova ni dokumentiranje starega stanja, ampak odločitev, kaj ohraniti, kaj poenostaviti in kje sistemu prepustiti delo.

Izdelki.

• dokument zasnove po procesih: od naročila do plačila, od nabave do plačila, proizvodnja, zaloga, finance, kadrovski podatki, kjer so v obsegu;
• seznam odstopanj od standardne funkcionalnosti, vsako z utemeljitvijo, zakaj ni mogoče uporabiti standarda;
• popis vmesnikov: spletna trgovina, banka, dobavitelji, plačilni sistem, sistem za e-račune, blagajna;
• računovodski vidik: kontni načrt, stroškovna mesta, obračun DDV, poročila za AJPES in za upravo.

Pasti.

• Prenos starih navad v nov sistem. Če ERP posnema preglednico, ste kupili drag način vnosa istih podatkov.
• Preveč prilagoditev. Vsaka prilagoditev je stalen strošek pri nadgradnjah. Pravilo: najprej prilagodite proces, šele nato program.
• Zasnovo podpiše samo vodja projekta. Podpis morajo dati tudi lastniki procesov, saj bodo prav oni po zagonu reklamirali, če nekaj manjka.

Pri posebnostih svojega področja si oglejte razdelke o panogah, na primer ERP za proizvodnjo ali ERP za veleprodajo in distribucijo.

4. Nastavitev in razvoj

Cilj. Izvajalec sistem nastavi po zasnovi: organizacijska struktura, uporabniške vloge in pravice, šifranti, davčne nastavitve, delovni tokovi, obrazci, poročila, vmesniki.

Izdelki.

• testno okolje, ki ga lahko ključni uporabniki sami preizkušajo že med nastavitvijo, ne šele ob koncu;
• seznam opravljenih nastavitev in prilagoditev v razumljivem jeziku;
• predloge dokumentov (ponudba, račun, dobavnica, naročilnica) v slovenščini in po potrebi v tujih jezikih;
• nastavljeni vmesniki, preizkušeni na poskusnih podatkih.

Pasti.

• »Pokažemo vam na koncu«. Če uporabniki do testiranja ne vidijo ničesar, se napake odkrijejo prepozno. Zahtevajte redne kratke predstavitve napredka.
• Pravice dodeljene preširoko. Ločitev nalog, na primer da isti uporabnik ne ustvari in odobri plačila, je treba nastaviti od začetka.
• Zanemarjeni računovodski izpisi. Če izpisi in obračun DDV niso preverjeni pri računovodji, se težave pokažejo ob prvem obračunu po zagonu.

5. Prenos podatkov

Cilj. Iz starih sistemov in preglednic prenesti podatke, ki jih novi sistem potrebuje: partnerje, artikle, cenike, začetna stanja glavne knjige, odprte postavke terjatev in obveznosti, stanje zaloge, osnovna sredstva.

Izdelki.

• načrt prenosa: kaj, iz kje, kdo je lastnik, kdo preveri;
• pravila čiščenja: podvojeni partnerji, neaktivni artikli, nepopolni naslovi, davčne številke brez veljavnosti;
• vsaj en poskusni prenos z uskladitvijo pri računovodstvu in skladišču;
• poročilo o skladnosti: stanja v starem sistemu so enaka stanjem v novem.

Pasti.

• Sodba »podatki so že v redu«. Zelo redko so. Prenos je priložnost, da se šifranti očistijo, in to je treba storiti pred prenosom.
• Prenos zgodovine, ki je nihče ne uporablja. Za pravno obvezne arhive so pogosto primernejše ločene rešitve, ne polnjenje živega sistema.
• Prenos v zadnjem trenutku. Podatke, ki se spreminjajo vsak dan, je treba v zadnji fazi prenesti znova, zato mora biti postopek ponovljiv in avtomatiziran.

Za zamenjavo obstoječega sistema je koristno prebrati Migracija ERP.

6. Sprejemno testiranje

Cilj. Dokazati, da sistem v resničnih scenarijih podjetja deluje, preden ga uporabi celotna organizacija. Testira podjetje, ne izvajalec.

Izdelki.

• testni scenariji, napisani po poslovnih procesih: od prejema povpraševanja do plačila računa, od naročila pri dobavitelju do vknjižbe prejetega računa;
• seznam napak z resnostjo (kritična, pomembna, kozmetična) in rokom odprave;
• preizkus celotnega obračuna DDV, izdaje in prejema e-računov ter, kjer je relevantno, davčnega potrjevanja računov;
• zapisnik testiranja z jasnim merilom: kdaj je sistem sprejet.

Pasti.

• Testiranje se opravi ob robu delovnega dne. Ljudje, ki testirajo, morajo imeti čas.
• Testira samo vodja projekta. Napake v skladišču najde skladiščnik, napake v knjiženju računovodja.
• Merilo sprejema ni vnaprej znano, zato se razprava o »končanem« vleče v nedogled. Merila določite že pri zasnovi.

7. Usposabljanje uporabnikov

Cilj. Vsak uporabnik zna opraviti svoje naloge v novem sistemu brez klica na pomoč. Usposabljanje ni enkratna delavnica, ampak niz kratkih sej, vezanih na vloge.

Izdelki.

• učni načrt po vlogah: računovodstvo, nabava, prodaja, skladišče, proizvodnja, vodstvo;
• kratka navodila v slovenščini, ki odražajo vaše procese, ne le splošni priročnik proizvajalca;
• interni »prvi odzivnik« na vsakem oddelku, ki zna odgovoriti na osnovna vprašanja;
• preverjanje: vsak uporabnik opravi dejanske naloge v testnem okolju.

Pasti.

• Usposabljanje prezgodaj, ko sistem še ni stabilen: ljudje pozabijo, kar so se naučili.
• Usposabljanje prepozno, med zagonom, ko je pritisk največji.
• Vodstvo se usposabljanja ne udeleži, potem pa zahteva poročila, ki jih ne zna odpreti.

8. Zagon

Cilj. Varen preklop z starega na novi sistem. To je trenutek, ko se podjetje začne zanašati na ERP.

Izdelki.

• načrt zagona po urah in odgovornih osebah, vključno z zadnjim prenosom podatkov;
• načrt vrnitve na staro stanje, če se pokaže kritična težava, in jasen pogoj, kdaj se o tem odloča;
• okrepljena podpora v prvih dneh: izvajalec in vaši prvi odzivniki so na voljo;
• seznam odprtih točk po zagonu, razvrščen po nujnosti.

Pasti.

• Zagon v obdobju zaključkov, obračunov, popisa ali sezonske konice.
• Hkratni zagon vseh modulov in lokacij, ko podjetje nima izkušenj. Postopen zagon (najprej finance in zaloga, nato proizvodnja ali drugi moduli) pogosto zmanjša tveganje, vendar ga je treba načrtovati že v zasnovi.
• Pomanjkanje nadzora. Prve dni je treba spremljati knjižbe, zaloge in izdane račune, da se napake ujamejo, preden se razširijo.

9. Izboljšave po zagonu

Cilj. Po zagonu se ERP ne zaključi, ampak začne dihati. Uporabniki odkrijejo, kaj jim manjka, vodstvo zahteva nova poročila, zakonodaja se spremeni.

Izdelki.

• pregled po zagonu: kaj je bilo narejeno, kaj ne, kaj smo se naučili;
• seznam izboljšav z lastnikom, prednostjo in oceno truda;
• dogovor o podpori in nadgradnjah: kdo odgovarja za napake, kdo za razvoj, kako se obravnavajo spremembe predpisov;
• merjenje ciljev iz prvega koraka: ali je zaključek meseca res hitrejši, ali je zaloga res zanesljiva.

Pasti.

• Konec projekta pomeni konec pozornosti. Brez lastnika sistem počasi zdrsne nazaj v preglednice.
• Podpora brez dogovora o odzivnosti. Pri poslovno kritičnem sistemu mora biti jasno, kdo odgovori in v kakšnem času.
• Nadgradnje se odlagajo, dokler ne postanejo nemogoče. Redne manjše nadgradnje so lažje od ene velike.

Vloge v projektu: kdo mora biti za mizo

Ne glede na izbrani sistem se projekt bolj ali manj pogosto zatakne pri ljudeh. Minimalna zasedba v slovenskem podjetju:

• Naročnik (direktor ali član uprave): odločitve o obsegu, proračunu in prednostih.
• Vodja projekta na strani podjetja: ima čas in pooblastilo, da usklajuje oddelke.
• Računovodja ali vodja financ: odgovoren za kontni načrt, DDV, e-račune in uskladitev začetnih stanj.
• Ključni uporabniki: ljudje iz nabave, prodaje, skladišča in proizvodnje, ki poznajo procese do podrobnosti.
• Informatik: dostopi, varnost, varnostne kopije, povezave z drugimi sistemi.
• Vodja projekta izvajalca in svetovalci: nosilci metodologije in nastavitve.

Če imate zunanje računovodstvo, ga povabite k projektu od zasnove, ne šele ob prvem obračunu. Nov sistem namreč spremeni, kako podatki prihajajo do računovodje.

Slovenske posebnosti, ki jih ne smete spregledati

Nekatere stvari so skupne vsem državam, druge pa so značilne za naš prostor in jih je treba v projekt vključiti zgodaj:

• Davčno potrjevanje računov (FURS). Kdor izdaja račune, za katere velja davčno potrjevanje, mora to imeti v sistemu urejeno, vključno z delovanjem v primeru izpada povezave. Več v vodniku Davčna blagajna in ERP.
• E-računi in obračun DDV. Izdajanje, prejemanje in arhiviranje e-računov ter priprava podatkov za eDavki sodijo v zasnovo, ne v dodatek po zagonu. Oglejte si E-računi, DDV in ERP ter Zakonske zahteve za ERP.
• Kontni načrt in poročila. Izpisi za računovodstvo, AJPES in revizorja morajo biti preverjeni pred zagonom.
• Regijska dostopnost izvajalcev. Pri uvajanju je pomembno, da je izvajalec dostopen za obisk na kraju samem; pregled po območjih najdete v razdelku Regije.

Kako se izbrani ERP odraža na projektu

Koraki so enaki ne glede na izdelek, razlikujejo se poudarki. Na splošno:

• Pri Odoo (odprtokodna platforma z moduli) je pogosto več svobode pri nastavitvi, zato je zasnova še pomembnejša, da se obseg ne razraste. Več v Odoo.
• Pri Microsoft Dynamics 365 Business Central je pomembna povezava z drugimi Microsoftovimi storitvami in disciplina pri razširitvah. Več v Business Central.
• Pri SAP Business One je običajno poudarek na dobro opredeljenih procesih in poročanju; glejte SAP Business One.
• Pri Oracle NetSuite gre za oblačno rešitev, kjer so nadgradnje in dostop vnaprej določeni; glejte Oracle NetSuite.
• Pri PANTHEON je razvit in uveljavljen na slovenskem trgu, zato je lokalna vsebina običajno že vgrajena; glejte PANTHEON.

Izbira med njimi ni tema tega članka. Če jo še razmišljate, pomaga primerjava Odoo ali Business Central.

Najpogostejše napake in kako se jim izogniti

Podrobneje jih obravnava vodnik Napake pri projektih ERP. Tu le kratek povzetek:

1. Nejasen obseg. Rešitev: pisni obseg in postopek za spremembe.
2. Premalo časa za uporabnike. Rešitev: formalno sproščen čas.
3. Zasnova brez lastnikov procesov. Rešitev: podpis zasnove po procesih.
4. Premalo testiranja. Rešitev: merila sprejema in dovolj časa.
5. Zagon v neprimernem obdobju. Rešitev: koledar podjetja pred koledarjem projekta.

Kaj storiti zdaj

Če ste še v fazi priprave, zapišite tri cilje, ki jih lahko izmerite, in določite vodjo projekta s časom za delo. Če že primerjate rešitve, pripravite lasten seznam scenarijev in jih zahtevajte v predstavitvi. Če iščete izvajalca, ki pozna vašo panogo in regijo, oddajte povpraševanje prek obrazca; povezali vas bomo z integratorjem, ki ustreza vašemu projektu, projekt pa bo potekal neposredno z njim. Splošni pregled najdete tudi na začetni strani in v vodnikih.

Imena programske opreme so blagovne znamke njihovih izdelovalcev in so navedena zgolj informativno. Spletno mesto je neodvisno in ni povezano z nobenim izdelovalcem.