Koliko traje uvođenje ERP-a? Realni vremenski rokovi

Detaljan odgovor fazu po fazu o tome koliko traje ERP projekt, što ga produljuje i usporedni vremenski okvir za računovodstvenu jezgro koju integrirate putem API-ja.

Maloj tvrtki koja prelazi na oblak ERP (cloud ERP) sa standardnim modulima obično treba između tri i šest mjeseci od potpisivanja ugovora do puštanja u rad. Srednje velikoj tvrtki s više povezanih društava, prilagođenim radnim procesima i integracijama obično treba šest do dvanaest mjeseci. Veliko multinacionalno uvođenje traje od jedne do tri godine, često u valovima prema regijama ili poslovnim jedinicama. To su rasponi koji odgovaraju objavama partnera za uvođenje i izvješćima financijskih timova; nisu rezultat ankete, a specifičan projekt može odstupati u oba smjera.

Jedinstvena brojka koju svi žele čuti ne postoji jer se "uvođenje" sastoji od devet zasebnih zadataka, a trajanje svakog ovisi o odlukama koje kupac donosi prije početka projekta. Ovaj članak dijeli taj vremenski okvir na te dijelove, pokazuje što produljuje svaki od njih, a zatim opisuje drugačiji kalendar: onaj koji dobivate kada je računovodstvena jezgra API s kojim vaš vlastiti softver komunicira, umjesto sustava koji ručno konfigurirate.

Devet faza i što utječe na svaku od njih

Faza	Tipično trajanje	Što utječe na trajanje
Odabir	1–3 mjeseca	Broj u uži izbor uvrštenih dobavljača, krugovi prezentacija, pozivi referentnim klijentima, pravila nabave
Dizajn	2–8 tjedana	Koliko procesa treba mapirati, slaže li se tim oko njih, u kojoj se mjeri standardni tok dobavljača prihvaća takav kakav jest
Migracija podataka	4–16 tjedana	Kvaliteta matičnih podataka, koliko se godina povijesti prebaci, broj izvornih sustava
Konfiguracija	4–12 tjedana	Broj subjekata, kontni planovi, države, porezni sustavi, tijekovi odobravanja
Integracija	4–20 tjedana	Broj sustava koje treba povezati (banka, obračun plaća, e-trgovina, CRM, skladište), kvaliteta API-ja sa svake strane
Testiranje	3–8 tjedana	Broj scenarija od kraja do kraja, jesu li testni podaci realistični, koliko nedostataka otkriva prvi prolaz
Obuka	2–6 tjedana	Broj zaposlenih, raznolikost uloga, koliko se novi proces razlikuje od starog
Puštanje u rad	1–2 tjedna	Način prijelaza (sve odjednom ili fazno), usklađenost s krajem razdoblja
Intenzivna podrška (hypercare)	4–12 tjedana	Broj otvorenih nedostataka pri puštanju u rad, prvo zaključivanje mjeseca, prva PDV prijava iz novog sustava

Faze se u praksi preklapaju. Integracija započinje dok konfiguracija još traje; obuka se često preklapa s testiranjem. Realan plan nije zbroj stupaca, ali kritični put obično prolazi kroz migraciju podataka i integraciju, a upravo su to dva područja s najviše kašnjenja.

Što projekt čini duljim

Prilagodba (customisation). Svaka promjena standardnog ponašanja dobavljača mora biti definirana, izrađena, testirana, dokumentirana i ponovno testirana prilikom svake buduće nadogradnje. Projekt koji prihvaća standardni proces za 90% tokova, a ostatak prilagođava, obično uspješno završi; projekt koji započinje repliciranjem zaslona starog sustava obično ne uspije.

Neuređeni matični podaci. Duplicirani kupci, dobavljači s tri različita načina pisanja, artikli bez mjerne jedinice, kontni plan koji se desetljeće razvijao stihijski. Migracija ne može biti brža od čišćenja podataka, a čišćenje obavljaju ljudi koji uz to imaju svoje redovne poslove. Ovo je najčešći uzrok pomicanja datuma puštanja u rad, a ujedno i najmanje vidljiv u izvornom planu.

Više pravnih subjekata. Svaki pravni subjekt treba svoj kontni plan, numeraciju, registraciju za PDV, bankovne račune i zaključivanje razdoblja. Međusobni tijekovi (intercompany) između njih zahtijevaju zaseban dizajn. Pomnožite fazu konfiguracije s brojem subjekata, a zatim na to dodajte dizajn konsolidacije.

Porezi u više država. Tvrtka koja prodaje u nekoliko država članica EU-a mora u novom sustavu ispravno postaviti pravila o mjestu oporezivanja, prijenos porezne obveze (reverse charge), OSS izvješćivanje i lokalne formate izvještaja prije nego što dospije prva prijava. Ako je lokalizacija dobavljača za neku državu djelo partnera, a ne izvorna značajka, dostupnost tog partnera postaje dio kritičnog puta.

Integracije sa slabim API-jima. ERP koji nudi samo uvoze temeljene na datotekama prisiljava svaki povezani sustav na skupnu obradu (batch), a svaka skupna obrada zahtijeva logiku usklađivanja koju netko mora napisati i testirati.

Datum puštanja u rad određen prije opsega. Kada se datum odredi iz političkih razloga, a opseg se definira kasnije, projekt ili skraćuje testiranje ili pomiče datum. Oboje je skupo.

Što projekt čini kraćim

Prihvaćanje standardnih procesa dobavljača tamo gdje se poslovanje zapravo ne razlikuje.
Čišćenje matičnih podataka prije početka projekta, a ne tijekom njega.
Migracija početnih stanja i otvorenih stavki umjesto cjelokupne povijesti te čuvanje starog sustava čitljivim za pretragu.
Odabir datuma prijelaza na granici obračunskih razdoblja sa zaključenom, usklađenom zaključnom bruto bilancom (trial balance).
Imenovanje jednog vlasnika procesa po modulu s ovlastima donošenja odluka.
Testiranje s stvarnim dokumentima iz posljednjih dvanaest mjeseci, a ne s izmišljenim uzorcima.
Odabir sustava čiji API omogućuje izradu i testiranje integracija paralelno s konfiguracijom, umjesto nakon nje.

Drugačiji kalendar: API-first računovodstvena jezgra

Vremenski rokovi opisani u nastavku odnose se na sustav koji ljudi konfiguriraju putem sučelja na zaslonu, a zatim ga koriste na isti način. Postoji i druga vrsta projekta koja ima drukčiji ritam. Kada je računovodstvena jezgra računovodstveni API, posao integracije seli se na sam početak, a veći dio faze konfiguracije nestaje jer je manje toga za podešavanje: kontni plan, porezna pravila i formati izvještaja stižu već ugrađeni u proizvod.

Kako to izgleda u praksi s Nordletom, opisano prema mogućnostima koje proizvod nudi danas, a ne kao obećanje:

Prvi dan: testno poduzeće (sandbox). Testno poduzeće stvara se iz aplikacije ili jednim API pozivom. Ponaša se potpuno isto kao pravo poduzeće, s istim modulima i istim krajnjim točkama (endpoints), a možete ih pokrenuti onoliko koliko vam treba. Vodič za početak rada (getting-started guide) vodi vas kroz prve pozive.

Od prvog do petog dana: prvi radni tijek. Stvorite partnera, stvorite fakturu, izdajte je, primite uplatu, pročitajte temeljnicu (journal entry) koju je izdavanje generiralo. Svaka operacija je POST /v1/{module}/{resource}/{action} poziv s JSON tijelom, a tipizirani SDK-ovi postoje za devet jezika, tako da se prvi tijek sastoji od svega nekoliko desetaka linija koda. Ponovljeni pozivi su sigurni jer zaglavlje Idempotency-Key vraća spremljeni odgovor umjesto stvaranja druge fakture.

Drugi tjedan: povijest. Uvoznik za migraciju (migration importer) preuzima kontni plan, partnere, artikle, početna stanja ili cjelokupnu povijest temeljnica, otvorene fakture kupaca i dobavljača, dugotrajnu imovinu s obračunatom amortizacijom do tog datuma te zalihe na skladištu, te ih zapisuje u jednoj bazi podataka. Krajnja točka samo za provjeru (migration/books/validate) pokreće svaku provjeru bez spremanja podataka, što vam omogućuje ponavljanje postupka dok se ne prikaže nula pogrešaka, a zatim jednom pokrenete migration/books/import. Ako bilo koji redak ne prođe provjeru, ništa se ne sprema.

Od drugog do četvrtog tjedna: ostatak integracije. Bankovni izvodi putem PSD2 veza, uvoz camt.053 izvadaka, Stripe izvoz, webhooks obavijesti poput sale_invoice.paid kako bi vaš sustav reagirao na događaje umjesto stalnog provjeravanja (polling). Svaki dio je zasebna krajnja točka i zaseban developer ga može izgraditi paralelno.

Usklađenost s propisima: već riješeno. Porezni tretman prekogranične prodaje rješava se putem EU VAT modula, a kalendar predaje izvještaja za državu u kojoj se tvrtka nalazi popunjava se prema ugrađenim pravilima. Tablica podrške za predaju izvještaja (filing support table) navodi za svih 30 država koje rokove Nordlet predaje samostalno, za koje generira datoteku, a koje se unose ručno. Ništa od toga nije projektni zadatak.

Zaključivanje razdoblja kao test. Prvo mjesečno zaključivanje trenutak je u kojem ERP projekt otkriva je li uspio. S nepromjenjivom glavnom knjigom i zaključavanjem razdoblja (period locking), knjiženje s datumom u zaključanom mjesecu odbacuje se s kodom 409, tako da zaključavanje provodi sustav, a ne radna disciplina. Pogreške u integraciji koje bi inače bile otkrivene tijekom intenzivne podrške (hypercare) ovdje se pojavljuju već u testnom okruženju.

Realna ograničenja tog kalendara: on obuhvaća računovodstvenu, poreznu i izvještajnu jezgru. Ako vaš projekt treba i upravljanje skladištem, raspoređivanje proizvodnje ili CRM, to su ili Nordlet moduli koje integrirate na isti način (zalihe, proizvodnja, narudžbe e-trgovine, potencijalni klijenti) ili sustavi koji stoje uz njega, a posao integracije za potonje i dalje je vaš. Nordlet je također mlad proizvod, u ranoj fazi dostupnosti 2026. godine uz uključivanje dizajnerskih partnera, što je faktor u svakoj odluci o odabiru dobavljača.

Kako procijeniti vlastiti projekt

Izbrojite subjekte, države i registracije za PDV. Svaka od njih u tradicionalnom ERP-u predstavlja konfiguracijski posao, a u sustavu temeljenom na API-ju zapis o tvrtki.
Izbrojite integracije i provjerite API svakog sustava prije potpisivanja ugovora. Sučelje temeljeno isključivo na datotekama otprilike udvostručuje procjenu vremena integracije.
Odlučite koliko povijesti želite migrirati. Početna stanja i otvorene stavke traju tjednima; puna višegodišnja povijest traje mjesecima.
Odredite datum prijelaza prema kalendaru razdoblja, a ne obrnuto. Granica godine ili tromjesečja s usklađenom zaključnom bilancom najjeftiniji je prijelaz koji postoji.
Predvidite da prvo zaključivanje traje dvaput dulje od uobičajenog i osigurajte proračun za intenzivnu podršku (hypercare) za prvu PDV prijavu i prvi obračun plaća iz novog sustava.
Napišite test prihvaćanja prije početka projekta: popis dokumenata, izvještaja i prijava koji iz novog sustava moraju izaći ispravno za prvi zaključeni mjesec. Plan testiranja prije produkcije (pre-production test plan) jedan je predložak za računovodstveni dio.

FAQ

Može li uvođenje ERP-a trajati kraće od tri mjeseca?

Da, za tvrtku s jednim subjektom koja prihvaća standardne procese, migrira samo početna stanja i ima jednu ili dvije integracije. Kod računovodstvene jezgre temeljene na API-ju prvi radni tijek mjeri se u danima, a najduža preostala stavka obično je paket migracije podataka.

Koja faza najčešće kasni?

Migracija podataka, a zatim integracija. Obje ovise o stanju sustava koje dobavljač ne kontrolira: o kvaliteti vaših postojećih podataka i API-jima sustava koje povezujete.

Trebamo li migrirati punu povijest ili samo početna stanja?

Početna stanja i otvorene stavke dovoljni su da novi sustav bude potpun od datuma prijelaza i zahtijevaju samo dio tog vremena. Puna povijest ima smisla kada su vam potrebni usporedni podaci unutar novog sustava ili kada se stari sustav u potpunosti gasi. Nordletov uvoznik prihvaća jedno i drugo.

Je li fazno uvođenje brže od naglog prijelaza (big-bang)?

Fazna uvođenja ukupno traju dulje, ali nose manji rizik po koraku i omogućuju timu da uči na prvom subjektu prije sljedećeg. Veliki prasak (big-bang) kraći je kada je organizacija dovoljno mala da jedan vikend prijelaza pokriva sve.

Kako se "uvođenje" razlikuje kod proizvoda temeljenog na API-ju?

Nema projekta konfiguracije zaslon po zaslon. Posao se sastoji od integracije i migracije koje programeri obavljaju u testnom okruženju (sandbox), dok sloj usklađenosti s propisima (pravila za PDV, formati izvještaja, kalendari) dolazi ugrađen u proizvod. Kompromis je u tome što netko na vašoj strani piše kod.