Per kiek laiko įdiegiama ERP sistema? Realistiški terminai

Etapas po etapo pateikiamas atsakymas į klausimą, kiek laiko trunka ERP projektas, kas lemia jo vėlavimą, ir greta pateikiamas kitoks kalendorius – toks, kokį gaunate integruodami buhalterinį branduolį per API.

Nedidelė įmonė, pereinanti prie debesijos ERP su standartiniais moduliais, nuo sutarties pasirašymo iki sistemos paleidimo (go-live) paprastai užtrunka nuo trijų iki šešių mėnesių. Vidutinio dydžio įmonei, turinčiai kelis padalinius, pritaikytus darbo procesus (workflows) ir integracijas, paprastai prireikia nuo šešių iki dvylikos mėnesių. Didelės tarptautinės įmonės masto diegimas trunka nuo vienerių iki trijų metų, dažnai etapais pagal regionus arba verslo vienetus. Tai intervalai, atitinkantys diegimo partnerių skelbiamus duomenis ir finansų komandų ataskaitas; tai nėra apklausos rezultatai, o konkretus projektas gali nukrypti nuo šių rėmų į bet kurią pusę.

Vienintelio visiems rūpimo skaičiaus nėra, nes „diegimas“ susideda iš devynių atskirų darbų sričių, o kiekvienos iš jų trukmė priklauso nuo sprendimų, kuriuos pirkėjas priima dar prieš prasidedant projektui. Šiame straipsnyje projektas išskaidomas į šiuos etapus, parodyta, kas prailgina kiekvieną iš jų, ir aprašomas kitoks kalendorius – tas, kurį gaunate tada, kai buhalterinis branduolys yra API, su kuriuo kalbasi jūsų pačių programinė įranga, o ne sistema, kurią konfigūruojate patys.

Devyni etapai ir kas lemia kiekvieno iš jų trukmę

Etapas	Tipinė trukmė	Kas lemia trukmę
Atranka (Selection)	1–3 mėn.	Į trumpąjį sąrašą patekusių tiekėjų skaičius, demonstraciniai turai, rekomendaciniai skambučiai, pirkimų taisyklės
Projektavimas (Design)	2–8 sav.	Kiek procesų reikia suplanuoti, ar komanda dėl jų sutaria, kiek priimamas standartinis tiekėjo srautas toks, koks yra
Duomenų perkėlimas (Data migration)	4–16 sav.	Bazinė duomenų kokybė, kiek metų istorijos perikeliama, šaltinio sistemų skaičius
Konfigūravimas (Configuration)	4–12 sav.	Subjektų (entities), sąskaitų planų (charts of accounts), šalių, mokesčių režimų, tvirtinimo srautų skaičius
Integracija (Integration)	4–20 sav.	Jungtinų sistemų skaičius (bankas, darbo užmokestis, el. prekyba, CRM, sandėlis), kiekvienos pusės API kokybė
Testavimas (Testing)	3–8 sav.	Visiškų (end-to-end) scenarijų skaičius, ar testavimo duomenys yra realistiški, kiek klaidų aptinkama pirmuoju praėjimu
Mokymai (Training)	2–6 sav.	Darbuotojų skaičius, vaidmenų įvairovė, kuo naujas procesas skiriasi nuo seno
Paleidimas (Go-live)	1–2 sav.	Perėjimo metodas („viskas vienu metu“ arba etapais), suderinamumas su laikotarpio pabaiga
Priežiūra po paleidimo (Hypercare)	4–12 sav.	Neatidarytų klaidų skaičius paleidimo metu, pirmasis mėnesio pabaigos uždarymas, pirmoji PVM deklaracija iš naujos sistemos

Praktikoje etapai persidengia. Integracija prasideda dar tebevykstant konfigūravimui; mokymai dažnai persidengia su testavimu. Realistiškas planas nėra tiesiog stulpelio suma, tačiau kritinis kelias dažniausiai eina per duomenų perkėlimą ir integraciją – būtent šios dvi sritys sukelia daugiausia nukrypimų.

Kas prailgina projektą

Pritaikymas individualiems poreikiams (Customisation). Kiekvienas nukrypimas nuo standartinio tiekėjo elgesio turi būti aprašytas, sukonstruotas, ištestuotas, dokumentuotas ir vėl ištestuotas per kiekvieną būsimą atnaujinimą. Projektas, kuris 90 % srautų priima standartinį procesą, o likusią dalį pritaiko, dažniausiai sėkmingai baigiamas; projektas, kuris pradedamas nuo senosios sistemos ekranų kopijavimo, – rečiau.

Netvarkingi baziniai duomenys (Master data). Dubliuojami klientai, tiekėjai su trimis rašybos variantais, prekės be matavimo vieneto, sąskaitų planas, dešimtmetį augęs stichiškai. Duomenų perkėlimas negali būti greitesnis už apsivalymą, o valymą atlieka žmonės, turintys ir tiesioginius kasdienius darbus. Tai dažniausia pavėluotos paleidimo datos priežastis ir mažiausiai matoma pirminiame plane.

Keli subjektai (Multiple entities). Kiekvienas juridinis asmuo reikalauja savo sąskaitų plano, numeravimo, PVM mokėtojo registracijos, banko sąskaitų ir laikotarpio uždarymo. Įmonių vidaus sandorių (intercompany) srautams reikia atskiro projektavimo. Padauginkite konfigūravimo etapą iš subjektų skaičiaus, o ant viršaus pridėkite konsolidavimo projektavimą.

Tarptautiniai mokesčiai. Į kelias ES valstybes nares parduodanti įmonė naujojoje sistemoje privalo teisingai sukonfigūruoti prekių ir paslaugų teikimo vietos taisykles, atvirkštinį PVM apmokestinimą (reverse charge), OSS atskaitomybę ir vietinius teikimo formatus dar prieš pateikiant pirmąją deklaraciją. Jei tiekėjo lokalizacija šaliai yra sukurta partnerio, o ne paties tiekėjo, to partnerio užimtumas tampa kritinio kelio dalimi.

Integracijos su silpnais API. ERP, kuri palaiko tik failų importą, priverčia kiekvieną prijungtą sistemą veikti paketinio (batch) apdorojimo režimu, o kiekvienam paketiniam režimui reikalinga suderinimo logika, kurią kažkas turi parašyti ir ištestuoti.

Paleidimo data nustatyta neatsižvelgiant į apimtį. Kai data nustatoma dėl politinių priežasčių, o apimtis paaiškėja vėliau, projektas arba sutrumpina testavimą, arba nukelia datą. Abi šios išeitys yra brangios.

Kas sutrumpina projektą

Tiekėjo standartinių procesų priėmimas ten, unde verslas iš tikrųjų nėra išskirtinis.
Bazinio duomenų rinkinio valymas dar prieš prasidedant projektui, o ne jo metu.
Pradinių likučių bei atvirų pozicijų (open items) perkėlimas vietoj visos istorijos, senąją sistemą paliekant skaitomą tik paieškai.
Perėjimo datos pasirinkimas laikotarpio riboje su užfiksuotu, suderintu uždarymo bandomuoju balansu (trial balance).
Po vieną procesų vadovą kiekvienam moduliui, turintį įgaliojimus priimti sprendimus.
Testavimas su realiais dokumentais iš praėjusių dvylikos mėnesių, o ne su sugalvotais pavyzdžiais.
Tokios sistemos pasirinkimas, kurios API leidžia kurti ir testuoti integracijas lygiagrečiai su konfigūravimu, o ne po jo.

Kitoks kalendorius: API pirmiausia pritaikytas buhalterinis branduolys

Aukščiau aprašyti terminai taikomi sistemai, kurią žmonės konfigūruoja per ekranus, o vėliau per juos ir naudoja. Egzistuoja kito tipo projektas, turintis kitokį laikmatį. Kai buhalterinis branduolys yra buhalterinis API, integracijos darbai perkeliami į priekį, o didžioji konfigūravimo etapo dalis išnyksta, nes konfigūruoti reikia mažiau: sąskaitų planas, mokesčių taisyklės ir ataskaitų teikimo formatai atkeliauja kartu su produktu.

Štai kaip tai atrodo naudojant „Nordlet“ – remiantis tuo, ką produktas daro šiandien, o ne pažadais:

Pirma diena: smėlio dėžės (sandbox) įmonė. Smėlio dėžės įmonė sukuriama iš programėlės arba vienu API iškvietimu. Ji veikia lygiai taip pat, kaip tikra įmonė, su tais pačiais moduliais ir tais pačiais galiniais taškais (endpoints), o jų galite paleisti tiek, kiek reikia. Vadovas pradedantiesiems supažindina su pirmaisiais iškvietimais.

Nuo pirmos iki penktos dienos: pirmasis veikiantis srautas. Sukurkite partnerį, išrašykite sąskaitą faktūrą, ją išduokite, gamykite mokėjimą, nuskaitykite žurnalo įrašą (journal entry), kurį išdavimas sukūrė. Kiekviena operacija yra POST /v1/{module}/{resource}/{action} iškvietimas su JSON turiniu, o tipizuoti SDK paruošti devynioms kalboms, todėl pirmasis srautas parašomas vos iš kelių dešimčių kodo eilučių. Pakartotiniai bandymai yra saugūs, nes Idempotency-Key antraštė (header) atkuria išsaugotą atsakymą, o ne sukuria antrą sąskaitą faktūrą.

Antra savaitė: istorija. Migracijos importavimo įrankis (migration importer) paima sąskaitų planą, partnerius, prekes, pradinius likučius arba visą žurnalo istoriją, atviras klientų ir tiekėjų sąskaitas faktūras, ilgalaikį turtą su nusidėvėjimu iki šios dienos bei esamas atsargas sandėlyje ir įrašo juos vienos duomenų bazės operacijos (transaction) metu. Tikrinimo galinis punktas (migration/books/validate) paleidžia kiekvieną patvirtinimą ir neišsaugo jokių duomenų, todėl galite tobulinti paketą, kol jis neparodys jokių klaidų, o tada vieną kartą paleisti migration/books/import. Jei nors viena eilutė nepraeina, niekas nesaugoma.

Nuo antros iki ketvirtos savaitės: likusioji integracijos dalis. Banko išrašų srautai per PSD2 jungtis, camt.053 išrašų importavimas, „Stripe“ eksportai, žiniatinklio kabliukai (webhooks), tokie kaip sale_invoice.paid, kad jūsų sistema reaguotų į įvykius, o ne pati tikrintų periodiškai. Kiekviena dalis yra atskiras galinis punktas, kurį lygiagrečiai gali sukurti atskiras kūrėjas.

Atitiktis: jau užregistruota. Tarptautinio pardavimo PVM apmokestinimas išsprendžiamas per ES PVM mechanizmą (EU VAT engine), o įmonės šalies ataskaitų teikimo kalendorius užpildomas remiantis integruotomis taisyklėmis. Ataskaitų teikimo palaikymo lentelėje visoms 30 šalių nurodyta, kuriuos terminus „Nordlet“ pateikia pati, kuriam sugeneruoja failą, o kuriuos reikia suvesti ranka. Jokia iš šių veiklų nėra projektinis darbas.

Laikotarpio uždarymas kaip testas. Pirmasis mėnesio pabaigos uždarymas yra momentas, kai ERP projektas sužino, ar jis pavyko. Naudojant nekeičiamą didžiąją knygą (immutable ledger) ir laikotarpio užrakinimą (period locking), įrašas užrakintam mėnesiui atmetamas grąžinant 409 klaidą, todėl uždarymą užtikrina pati sistema, o ne darbuotojų drausmė, o integracijos klaidos, kurios būtų aptiktos priežiūros po paleidimo metu, iškyla į paviršių jau smėlio dėžėje.

Sąžiningos šio kalendoriaus ribos: jis apima apskaitos, mokesčių ir ataskaitų teikimo branduolį. Jei jūsų projektui taip pat reikalingas sandėlio valdymas, gamybos planavimas arba CRM, tai yra arba „Nordlet“ moduliai, kuriuos integruojate tuo pačiu būdu (atsargos, gamyba, e. prekybos užsakymai, užklausos), arba šalia esančios sistemos, o pastarųjų integracijos darbai lieka jūsų atsakomybe. „Nordlet“ taip pat yra jaunas produktas, 2026 m. pasiekiamas ankstyvosios prieigos (early access) režimu ir pritraukiantis bandomuosius partnerius, o tai yra svarbus veiksnys priimant bet kokį sprendimą dėl tiekėjo.

Kaip įvertinti savo projektą

Suskaičiuokite subjektus, šalis ir PVM registracijas. Kiekvienas iš jų tradiciniame ERP yra konfigūravimo darbas, o API pirmiausia pritaikytoje sistemoje – įmonės įrašas.
Suskaičiuokite integracijas ir prieš pasirašydami sutartį patikrinkite kiekvienos sistemos API. Tik failais pagrįsta sąsaja maždaug padvigubina integracijos sąmatą.
Nuspręskite, kiek istorijos norite perkelti. Pradiniai likučiai ir atviros pozicijos užtruks kelias savaites; visa kelerių metų istorija – kelis mėnesius.
Perėjimo datą pasirinkite pagal laikotarpio kalendorių, o ne atvirkščiai. Metų pabaigos ar ketvirčio pabaigos riba su suderintu uždarymo balansu yra pigiausias galimas perėjimas.
Planuokite, kad pirmasis uždarymas užtruks dvigubai ilgiau nei įprastai, ir numatykime biudžetą priežiūrai po paleidimo pirmosios PVM deklaracijos ir pirmojo darbo užmokesčio skaičiavimo iš naujos sistemos metu.
Prieš prasidedant projektui parašykite priėmimo testą: dokumentų, ataskaitų ir deklaracijų sąrašą, kurie iš naujojo įrankio už pirmąjį uždarytą mėnesį privalo išeiti teisingi. Pasigamybinio testavimo planas yra vienas iš šablonų apskaitos daliai.

D.U.K.

Ar ERP diegimas gali trukti trumpiau nei tris mėnesius?

Taip, vieno subjekto įmonei, kuri priima standartinius procesus, perkelia tik pradinius likučius ir turi vieną ar dvi integracijas. API pirmiausia pritaikytam buhalteriniam branduoliui pirmasis veikiantis srautas matuojamas dienomis, o ilgiausiai trunkantis elementas dažniausiai būna duomenų perkėlimo paketas.

Kuris etapas vėluoja dažniausiai?

Duomenų perkėlimas, po kurio seka integracija. Abu jie priklauso nuo sistemų, kurių tiekėjas nekontroliuoja, būklės: jūsų esamų duomenų kokybės ir jungiamų sistemų API.

Ar turėtume perkelti visą istoriją, ar tik pradinius likučius?

Pradinių likučių ir atvirų pozicijų pakanka tam, kad naujoji sistema būtų pilnavertė nuo perėjimo datos, be to, tam sugaištama tik trupinys laiko. Visą istoriją verta kelti tada, kai naujojoje sistemoje reikalingi palyginamieji duomenys arba kai senoji sistema išjungiama visiškai. „Nordlet“ importavimo įrankis priima abu variantus.

Ar diegimas etapais yra greitesnis nei perėjimas „viskas vienu metu“ (big-bang)?

Diegimas etapais iš viso užtrunka ilgiau, tačiau kelia mažesnę riziką kiekviename žingsnyje ir leidžia komandai pasimokyti iš pirmojo subjekto prieš pereinant prie kito. „Big-bang“ yra trumpesnis, kai organizacija pakankamai maža, kad vienas perėjimo savaitgalis apimtų viską.

Kuo „diegimas“ skiriasi kalbant apie API pirmiausia pritaikytą produktą?

Nėra ekrano po ekrano konfigūravimo projekto. Darbą sudaro integracija ir migracija, kūrėjų atliekama naudojant smėlio dėžę, o atitikties sluoksnis (PVM taisyklės, teikimo formatai, kalendoriai) pristatomas kartu su produktu. Kompromisas yra tas, kad kažkas iš jūsų pusės turi rašyti kodą.