How Long Does ERP Implementation Take? Realistic Timelines

A phase-by-phase answer to how long an ERP project takes, the things that make it longer, and a contrasting timeline for an accounting core you integrate through an API.

Prehod manjše družbe na v oblaku gostovan s standardnimi moduli zgrajen ERP sistem običajno traja od treh do šestih mesecev od podpisa pogodbe do uvedbe v produkcijo (go-live). Srednje velika družba z več povezanimi osebami, prilagojenimi potki potrjevanja in integracijami potrebuje od šest do dvanajst mesecev. Uvedba v večjem multinacionalnem podjetju traja od enega do treh let, pogosto v valovih glede na regijo ali poslovno enoto. To so časovni okvirji, ki se ujemajo z objavami implementacijskih partnerjev in poročili finančnih ekip; ne gre za rezultate anket, zato lahko posamezen projekt v eni ali drugi smeri odstopa od teh vrednosti.

Edinstvene številke, ki jo vsi želijo slišati, ni, saj je »uvedba« sestavljena iz devetih ločenih sklopov dela, dolžina posameznega sklopa pa je odvisna od odločitev, ki jih naročnik sprejme pred začetkom projekta. Ta članek deli časovni načrt na omenjene sklope, prikazuje dejavnike, ki podaljšujejo posamezne faze, v nadaljevanju pa opisuje drugačen koledar: tistega, ki ga dobite, ko je računovodsko jedro API, s katerim komunicira vaša lastna programska oprema, in ne sistem, ki ga morate sami konfigurirati.

Devet faz in dejavniki, ki vplivajo na vsako izmed njih

Faza	Običajno trajanje	Glavni dejavniki vpliva na trajanje
Izbira	1–3 mesece	Število ponudnikov v ožjem izboru, krogi predstavitev (demo), referenčni klici, pravila javnega naročanja
Načrtovanje	2–8 tednov	Število poslovnih procesov, ki jih je treba preslikati, stopnja usklajenosti ekipe glede njih, obseg sprejemanja standardnih procesov ponudnika v nespremenjeni obliki
Prenos podatkov	4–16 tednov	Kakovost glavnih podatkov (master data), število let zgodovine prenosa, število izvornih sistemov
Nastavitev sistema	4–12 tednov	Število poslovnih subjektov, kontni načrt, število držav, davčni predpisi, tokovi potrjevanja
Integracija	4–20 tednov	Število sistemov za povezavo (banka, obračun plač, spletna trgovina, CRM, skladišče), kakovost API-ja na posamezni strani
Testiranje	3–8 tednov	Število scenarijev od konca do konca (end-to-end), realističnost testnih podatkov, število napak, odkritih v prvem krogu
Uporabniško usposabljanje	2–6 tednov	Število zaposlenih, raznolikost delovnih vlog, stopnja odstopanja novega procesa od starega
Uvedba v produkcijo	1–2 tedna	Metoda preklopa (hkratni preklop ali fazni preklop), uskladitev z zaključkom obračunskega obdobja
Intenzivna podpora	4–12 tednov	Število odprtih napak ob uvedbi, prvi zaključni obračun meseca, prva oddaja obračuna DDV iz novega sistema

Faze se v praksi prekrivajo. Integracija se začne, ko nastavitev sistema še poteka; usposabljanje se pogosto prekriva s testiranjem. Realističen načrt ni preprosta vsota vseh vrstic v stolpcu, temveč kritična pot običajno poteka skozi prenos podatkov in integracijo, pri čemer sta ravno ti dve področji vir največjih zamud.

Dejavniki, ki podaljšujejo projekt

Prilagoditve (customisation). Vsako odstopanje od standardnega delovanja ponudnika zahteva specifikacijo, razvoj, testiranje, dokumentiranje in ponovno testiranje ob vsaki prihodnji posodobitvi. Projekt, ki za 90 odstotkov potekov sprejme standardne procese, preostanek pa prilagodi, se običajno uspešno zaključi; projekt, ki se začne s kopiranjem zaslonov starega sistema, pa običajno ne.

Nekakovostni glavni podatki. Podvojeni kupci, dobavitelji z več različnimi zapisi imena, artikli brez merske enote, kontni načrt, ki se je desetletje širil nenačrtovano. Prenos podatkov ne more potekati hitreje kot njihovo čiščenje, čiščenje pa opravljajo ljudje, ki imajo tudi svoje redne delovne obveznosti. To je najpogostejši vzrok za zamik datuma uvedbe v produkcijo in hkrati najmanj opazen dejavnik v prvotnem načrtu.

Več poslovnih subjektov. Vsaka pravna oseba potrebuje lasten kontni načrt, shemo številčenja, davčno številko za DDV, bančne račune in zaključevanje obdobja. Medsebojni toki (intercompany) med njimi zahtevajo lastno zasnovo. Pomnožite fazo nastavitve s številom subjektov, nato pa na vrh dodajte še zasnovo konsolidacije.

Večdržavno obdavčitev. Podjetje, ki prodaja v več držav članic EU, mora v novem sistemu pravilno urediti pravila kraja obdavčitve, obratno oziroma samoobdavčitev, poročanje OSS in lokalne formate poročanja pred zapadlostjo prvega obračuna. Če je lokalizacija ponudnika za posamezno državo delo partnerja in ne del osnovne rešitve, razpoložljivost tega partnerja postane del kritične poti.

Integracije s šibkimi vmesniki API. ERP, ki ponuja izključno uvoze na podlagi datotek, sili vsak povezan sistem v paketni (batch) način obdelave, vsak paketni način pa zahteva logiko usklajevanja, ki jo mora nekdo napisati in stestirati.

Datum uvedbe, določen pred opredelitvijo obsega. Ko je datum postavljen iz političnih razlogov, obseg pa se odkriva sproti, projekt bodisi skrajša testiranje bodisi premakne datum. Obe možnosti sta dragi.

Dejavniki, ki skrajšajo projekt

Sprejemanje standardnih procesov ponudnika tam, kjer poslovanje dejansko ni specifično.
Čiščenje glavnih podatkov pred začetkom projekta in ne med njim.
Prenos začetnih stanj in odprtih postavk namesto celotne zgodovine, ob ohranitvi bralnega dostopa do starega sistema za namene vpogleda.
Izbira datuma preklopa ob zaključku obdobja z usklajeno in zaklenjeno zaključno bruto bilanco.
Določitev enega skrbnika procesa za posamezen modul, ki ima pooblastilo za sprejemanje odločitev.
Testiranje z dejanskimi dokumenti zadnjih dvanajstih mesecev in ne sizmišljenimi vzorci.
Izbira sistema, katerega API omogoča, da se integracije razvijajo in testirajo vzporedno z nastavitvijo sistema in ne šele po njej.

Drugačen koledar: računovodsko jedro, zasnovano na principu API-first

Zgornji časovni okviri opisujejo sistem, ki ga ljudje konfigurirajo prek uporabniških vmesnikov in nato uporabljajo prek zaslonov. Obstaja pa drugačna vrsta projekta, ki ima drugačen ritem. Ko je računovodsko jedro računovodski API, se delo z integracijo premakne na sam začetek, večji del faze nastavitve sistema pa odpade, ker je nastavitvam namenjen manjši obseg: kontni načrt, davčna pravila in formati poročanja so že vgrajeni v izdelek.

Tako je to videti pri uporabi rešitve Nordlet, opisano skozi dejanske zmogljivosti izdelka in ne le kot obljuba:

Prvi dan: testno okolje (sandbox). Testno podjetje se ustvari neposredno iz aplikacije ali prek enega samega klica API. Deluje popolnoma enako kot pravo podjetje, z enakimi moduli in končnimi točkami, ustvarite pa jih lahko poljubno število. Vodnik za začetnike vodi skozi prve klice.

Od prvega do petega dne: prvi delujoč procesni cikel. Ustvarite poslovnega partnerja, izstavite račun, zabeležite prejem plačila in preberite temeljnico, ki jo je ustvarila izdaja. Vsaka operacija je klic POST /v1/{module}/{resource}/{action} s telesom v formatu JSON, za devet programskih jezikov pa so na voljo tipizirani paketi SDK, zato prvi potek zahteva le nekaj deset vrstic kode. Ponovni poskusi so varni, ker glava zahteve Idempotency-Key vrne shranjen odziv namesto ponovnega ustvarjanja drugega računa.

Drugi teden: prenos zgodovine. Uvoznik za prenos podatkov prevzame kontni načrt, partnerje, artikle, začetna stanja ali celotno zgodovino temeljnic, odprte račune kupcev in dobaviteljev, osnovna sredstva z dosedanjimi amortizacijskimi zneski ter zaloge na dan, in jih zapiše v eni sami bazi podatkovni transakciji. Končna točka za preverjanje (migration/books/validate) izvede vsak preizkus veljavnosti brez zapisovanja v bazo, kar omogoča ponavljanje postopka, dokler paket ne javi nič napak, nato pa se enkrat izvede migration/books/import. Če katera koli vrstica ni veljavna, se v sistemu ne shrani nič.

Od drugega do četrtega tedna: preostali del integracije. Bančni izpisi prek povezav PSD2, uvoz izpiskov camt.053, izvozi iz Stripe in sprožilci (webhooks), kot je sale_invoice.paid, ki omogočajo, da se vaš sistem odziva na dogodke namesto na poizvedbe (polling). Vsak del je samostojna končna točka, ki jo lahko posamezen razvijalec razvija vzporedno z ostalimi.

Skladnost s predpisi: že vključena. Davčna obravnava čezmejne prodaje je rešena z motorjem za DDV v EU, koledar oddaje poročil za državo podjetja pa se samodejno izpolni na podlagi vgrajenih pravil. Tabela podpore za oddajo poročil za vseh 30 držav navaja, katere roke Nordlet oddaja samostojno, za katere pripravi datoteko za oddajo in katere je treba vnesti ročno. Nobena od teh nalóg ne predstavlja projektnega dela.

Zaključek obdobja kot preizkus. Prvi zaključni obračun meseca je trenutek, ko projekt ERP pokaže svojo učinkovitost. Z nespremenljivo glavno knjigo (immutable ledger) in zaklepanjem obdobja je knjiženje z datumom v zaklenjenem mesecu zavrnjeno s kodo 409, kar pomeni, da zaključek zagotavlja sam sistem in ne le interna disciplina. Morebitne napake v integraciji, ki bi se sicer pokazale šele v obdobju intenzivne podpore, se odkrijejo že v testnem okolju.

Realne omejitve tega časovnega načrta: zajema računovodsko, davčno in poročevalsko jedro. Če vaš projekt poleg tega potrebuje upravljanje skladišča, urnike proizvodnje ali sistem CRM, so ti bodisi moduli Nordleta, ki jih integrirate na enak način (zaloge, proizvodnja, naročila v spletni trgovini, kontaktni vodi), bodisi zunanji sistemi, pri čemer integracija slednjih ostaja vaša naloga. Nordlet je tudi mlad izdelek, ki je v letu 2026 v fazi zgodnjega dostopa (early access) in vključevanja prvih razvojnih partnerjev, kar je dejavnik, ki ga je treba upoštevati pri vsaki odločitvi o izbiri ponudnika.

Kako oceniti obseg lastnega projekta

Preštejte poslovne subjekte, države in registracije za DDV. Vsaka od njih v klasičnem ERP sistemu predstavlja nastavitveno delo, v sistemu, ki temelji na API, pa zapis podjetja.
Preštejte integracije in pred podpisom preverite API vsakega sistema. Vmesnik, ki podpira le datoteke, približno podvoji časovno oceno integracije.
Odločite se o obsegu zgodovine za prenos. Začetna stanja in odprte postavke zahtevajo tedne; prenos celotne večletne zgodovine zahteva mesece.
Datum preklopa določite na podlagi koledarja obdobij in ne obratno. Prehod ob koncu leta ali četrtletja z usklajeno zaključno bilanco je cenovno najugodnejši preklop.
Predpostavite, da bo prvi zaključek trajal dvakrat dlje kot običajen, in načrtujte intenzivno podporo za prvo oddajo obračuna DDV ter prvi obračun plač iz novega sistema.
Pripravite sprejemne testne primere pred začetkom projekta: seznam dokumentov, poročil in obračunov, ki morajo za prvi zaključeni mesec pravilno izstopiti iz novega sistema. Testni načrt pred produkcijo je ena od možnih predlog za računovodski del.

FAQ

Ali lahko uvedba ERP sistema traja manj kot tri mesece?

Da, za eno samo družbo, ki sprejema standardne procese, prenaša zgolj začetna stanja ter vključuje eno ali dve integraciji. Pri računovodskem jedru, ki temelji na API, se prvi delujoči proces meri v dnevu ali dveh, najdaljši preostali element pa je običajno paket za prenos podatkov.

Katera faza najpogosteje povzroči zamudo?

Prenos podatkov, sledi pa mu integracija. Obe sta odvisni od stanja sistemov, ki jih ponudnik ne nadzoruje: od kakovosti vaših obstoječih podatkov in od vmesnikov API sistemov, s katerimi se povezujete.

Ali naj prenesemo celotno zgodovino ali le začetna stanja?

Začetna stanja in odprte postavke zadostujejo, da je nov sistem popoln od datuma preklopa naprej, njihov prenos pa zahteva le delček časa. Celotna zgodovina je smiselna, kadar v novem sistemu potrebujete primerjalne podatke ali ko se stari sistem popolnoma ukinja. Uvoznik v Nordletu podpira obe možnosti.

Ali je fazni preklop hitrejši od hkratnega preklopa (big-bang)?

Fazni preklopi skupno trajajo dlje, vendar nosijo manj tveganja na posamezen korak ter ekipi omogočajo učenje na prvem subjektu pred prehodom naslednjega. Hkratni preklop je krajši, ko je organizacija dovolj majhna, da celoten prehod zajame en sam vikend.

Kako se »uvedba« razlikuje pri izdelku, ki temelji na API-ju?

Ni projekta nastavitve prek zaslonov. Delo obsega integracijo in prenos podatkov, ki ju razvijalci izvedejo z uporabo testnega okolja, medtem ko je skladnost s predpisi (pravila za DDV, formati poročanja, koledarji) vgrajena neposredno v izdelek. Kompromis je v tem, da mora delo pisanja kode opraviti ekipa na vaši strani.