Cik ilgi notiek ERP ieviešana? Reālistiski termiņi

Pa posmiem sniegta atbilde uz jautājumu, cik ilgu laiku aizņem ERP projekts, kas pagarina tā gaitu un kāds ir alternatīvs kalendārs gadījumā, ja grāmatvedības kodols ir integrēts caur API.

Mazam uzņēmumam, kas pāriet uz mākoni balstītu ERP (cloud ERP) ar standarta moduļiem, no līguma parakstīšanas līdz sistēmas iedarbināšanai parasti ir nepieciešami trīs līdz seši mēneši. Vidējam uzņēmumam ar vairākām juridiskajām personām, pielāgotām darba plūsmām (workflows) un integrācijām parasti vajag no sešiem līdz divpadsmit mēnešiem. Liela mēroga multinacionāla ieviešana ilgst no viena līdz trim gadiem, bieži pa posmiem sadalot pa reģioniem vai biznesa vienībām. Šie diapazoni atbilst gan ieviešanas partneru publicētajiem datiem, gan finanšu komandu ziņotajam; tie nav aptaujas rezultāti, un konkrēts projekts var ārpus tiem iziet jebkurā virzienā.

Viena konkrēta skaitļa, ko visi vēlas uzzināt, nav, jo "ieviešana" sastāv no deviņiem atsevišķiem darba posmiem, un katra posma ilgums ir atkarīgs no lēmumiem, ko pircējs pieņem pirms projekta sākuma. Šajā rakstā termiņš tiek sadalīts šajās sastāvdaļās, parādīts, kas pagarina katru no tām, un pēc tam aprakstīts cits kalendārs – tāds, kādu iegūstat tad, ja grāmatvedības kodols ir API, ar kuru sazinās jūsu pašu programmatūra, nevis sistēma, kuru nākas konfigurēt.

Devņi posmi un to ietekmējošie faktori

Posms	Tipiskais ilgums	Ilgumu ietekmējošie faktori
Atlase (Selection)	1–3 mēneši	Atlasīto piegādātāju skaits, demonstrāciju kārtas, atsauksmju zvani, iepirkuma noteikumi
Projektēšana (Design)	2–8 nedēļas	Kartējamo procesu skaits, komandas vienprātība par tiem, piegādātāja standarta plūsmas pieņemšanas pakāpe bez izmaiņām
Datu migrācija (Data migration)	4–16 nedēļas	Pamatdatu kvalitāte, līdzi ņemamo vēstures gadu skaits, avota sistēmu skaits
Konfigurācija (Configuration)	4–12 nedēļas	Juridisko vienību skaits, kontu plāni, valstis, nodokļu režīmi, apstiprināšanas plūsmas
Integrācija (Integration)	4–20 nedēļas	Pieslēdzamo sistēmu skaits (banka, algas, e-komercija, CRM, noliktava), katras puses API kvalitāte
Testēšana (Testing)	3–8 nedēļas	No gala līdz galam (end-to-end) scenāriju skaits, testa datu reālistiskums, pirmajā reizē atrasto kļūdu skaits
Apmācība (Training)	2–6 nedēļas	Darbinieku skaits, lomu dažādība, jaunā procesa atšķirība no vecā procesa
Darbības uzsākšana (Go-live)	1–2 nedēļas	Pārejas metode (vienā dienā jeb big-bang vai pa posmiem), laika grafika saskaņošana ar perioda beigām
Intensīvā uzraudzība (Hypercare)	4–12 nedēļas	Neatrisināto kļūdu skaits sistēmas palaišanas brīdī, pirmais mēneša slēgums, pirmā PVN deklarācija no jaunās sistēmas

Praksē posmi pārklājas. Integrācija sākas, kamēr konfigurācija vēl turpinās; apmācība bieži pārklājas ar testēšanu. Reālistisks plāns nav kolonnu summa, tomēr kritisko ceļu parasti nosaka datu migrācija un integrācija, un tieši šajās divās jomās rodas visvairāk aizkavēšanās.

Kas pagarina projektu

Pielāgošana (Customisation). Katras izmaiņas piegādātāja standarta darbībā ir jāapraksta, jāizstrādā, jānotestē, jādokumentē un pēc tam no jauna jātestē katras nākamās sistēmas jaunināšanas laikā. Projekts, kas 90% plūsmu pieņem standarta procesā un pārējo pielāgo, parasti tiek pabeigts; projekts, kas sāk ar vecās sistēmas ekrānu kopēšanu, parasti netiek pabeigts.

Nekārtīgi pamatdati. Dublēti klienti, piegādātāji ar trīs dažādiem nosaukumiem, preces bez mērvienības, kontu plāns, kas gadu desmitiem audzis pats no sevis. Migrācija nevar noritēt ātrāk par sakārtošanu, un sakārtošanu veic cilvēki, kuriem ir arī savi ikdienas darbi. Šis ir visbiežāk sastopamais plānotā palaišanas datuma kavēšanās iemesls un vienlaikus mazāk redzamais elements sākotnējā plānā.

Vairākas juridiskās vienības. Katrai juridiskajai vienībai ir nepieciešams savs konts, numerācija, PVN reģistrācija, bankas konti un perioda slēgums. Starpuzņēmumu plūsmām (intercompany) ir jāizstrādā savs dizains. Reiziniet konfigurācijas posmu ar vienību skaitu un virsū uzlieciet konsolidācijas dizainu.

Nodokļi vairākās valstīs. Uzņēmumam, kas tirgo preces vairākās ES dalībvalstīs, jaunajā sistēmā pirms pirmās atskaites iesniegšanas ir jānodrošina pareiza piegādes vietas noteikšana, reversais PVN, OSS atskaites un vietējie deklarāciju formāti. Ja piegādātāja lokalizācija konkrētajai valstij ir partnera veidota, nevis iebūvēta, šī partnera pieejamība kļūst par daļu no kritiskā ceļa.

Integrācijas ar vājiem API. ERP, kas nodrošina tikai failu importu, piespiež katru pieslēgto sistēmu izmantot pakešu (batch) apstrādi, un katrai pakešu apstrādei ir nepieciešama saskaņošanas loģika, kas kādam ir jāuzraksta un jānotestē.

Palaišanas datums noteikts pirms apjoma apzināšanas. Ja datums tiek noteikts politisku apsvērumu dēļ un darba apjoms atklājas vēlāk, projekts vai nu saīsina testēšanu, vai pārcel datumu. Abas opcijas ir dārgas.

Kas saīsina projektu

Piegādātāja standarta procesu pieņemšana gadījumos, kad uzņēmējdarbība patiesībā neatšķiras.
Pamatdatu sakārtošana pirms projekta sākuma, nevis tā laikā.
Sākuma atlikumu un neatvērto pozīciju migrācija, nevis pilnas vēstures pārnešana, saglabājot veco sistēmu lasāmā formātā uzziņām.
Pārejas datuma izvēle perioda beigās ar fiksētu, saskaņotu slēguma kontu apgrozījuma pārskatu.
Pa vienam procesa īpašniekam (process owner) katram modulim ar pilnvarām pieņemt lēmumus.
Testēšana ar reāliem dokumentiem no pēdējiem divpadsmit mēnešiem, nevis ar izdomātiem paraugiem.
Tādas sistēmas izvēle, kuras API ļauj izveidot un notestēt integrācijas paralēli konfigurācijai, nevis pēc tās.

Cita veida kalendārs: API pirmā līmeņa (API-first) grāmatvedības kodols

Iepriekš aprakstītie termiņi attiecas uz sistēmu, ko cilvēki konfigurē caur ekrāniem un pēc tam lieto caur ekrāniem. Pastāv cita veida projekts, un tam ir citāds laika ritms. Ja grāmatvedības kodols ir grāmatvedības API, integrācijas darbs tiek pārcelts uz sākumu, un lielākā daļa konfigurācijas posma izzūd, jo konfigurējamā ir mazāk – kontu plāns, nodokļu noteikumi un atskaišu formāti jau ir iebūvēti produktā.

Kā tas izskatās ar Nordlet, runājot par to, ko produkts dara šodien, nevis par solījumiem nākotnē:

Pirmā diena: smilškastes (sandbox) uzņēmums. Smilškastes uzņēmums tiek izveidots no lietotnes vai ar vienu API izsaukumu. Tas darbojas tieši tāpat kā reāls uzņēmums, ar tiem pašiem moduļiem un tiem pašiem galapunktiem (endpoints), un jūs varat izveidot tik daudz uzņēmumu, cik nepieciešams. Darba uzsākšanas ceļvedis palīdz veikt pirmos izsaukumus.

Pirmā līdz piektā diena: pirmā strādājošā plūsma. Izveidojiet partneri, izveidojiet rēķinu, izrakstiet to, saņemiet maksājumu, izlasiet grāmatojumu, ko izrakstīšana ģenerēja. Katra darbība ir POST /v1/{module}/{resource}/{action} izsaukums ar JSON pamattekstu (body), un deviņām valodām ir pieejami tipizēti SDK, tāpēc pirmā plūsma prasa tikai dažus desmitus koda rindiņu. Atkārtoti mēģinājumi ir droši, jo Idempotency-Key galvene atskaņo saglabāto atbildi, nevis izveido otru rēķinu.

Otrā nedēļa: vēsture. Migrācijas importētājs paņem kontu plānu, partnerus, preces, sākuma atlikumus vai pilnu žurnāla vēsturi, atvērtos klientu un piegādātāju rēķinus, pamatlīdzekļus ar uzkrāto nolietojumu un noliktavas atlikumus, un ieraksta tos vienā datu bāzes tranizakcijā. Pārbaudes galpunkts (migration/books/validate) palaiž visas validācijas un neko neieraksta, tāpēc jūs varat testēt pakotni, līdz tā neuzrāda kļūdas, un pēc tam vienu reizi palaist migration/books/import. Ja kāda rinda neiztur pārbaudi, nekas netiek saglabāts.

Otrā līdz ceturtā nedēļa: pārējā integrācija. Bankas kontu plūsmas, izmantojot PSD2 savienojumus, camt.053 konta izrakstu imports, Stripe eksporti, tīmekļaāķi (webhooks), piemēram, sale_invoice.paid, lai jūsu sistēma reaģētu uz notikumiem, nevis veiktu nepārtrauktu datu vaicāšanu (polling). Katra daļa ir atsevišķs galpunkts, un to var paralēli izstrādāt cits izstrādātājs.

Atbilstība normatīviem: jau reģistrēta. Pārrobežu darījuma PVN piemērošanu atrisina ES PVN dzinējs, un uzņēmuma mītnes valsts atskaišu kalendārs tiek aizpildīts, balstoties uz iebūvētiem noteikumiem. Atskaišu atbalsta tabula visām 30 valstīm uzskaita, kurus termiņus Nordlet deklarē pats, kuram tas sagatavo failu un kuri ir jāievada manuāli. Nekas no tā nav projekta darbs.

Perioda slēgums kā tests. Pirmais mēneša slēgums ir brīdis, kurā ERP projekts parāda, vai tas darbojas. Izmantojot nemainīgu virsgrāmatu (immutable ledger) un perioda slēgšanu, grāmatojums ar datumu slēgtā mēnesī tiek noraidīts ar 409 kļūdu, tāpēc slēgšanu nodrošina pati sistēma, nevis darbinieku disciplīna, un integrācijas kļūdas, kas parasti atklātos intensīvās uzraudzības laikā, parādās smilškastē jau agrāk.

Šī kalendāra godīgie ierobežojumi: tas aptver grāmatvedības, nodokļu un atskaišu kodolu. Ja jūsu projektam ir nepieciešama arī noliktavas vadība, ražošanas plānošana vai CRM, tās ir vai nu Nordlet moduļi, kurus integrējat tādā pašā veidā (krājumi, ražošana, e-komercijas pasūtījumi, potenciālie klienti), vai arī sistēmas, kas atrodas blakus, un šo pēdējo integrācijas darbs joprojām jāveic jums. Nordlet ir arī jauns produkts, kas 2026. gadā ir agrīnās piekļuves (early access) stadijā un piesaista pirmos partnerus, kas ir jāņem vērā, pieņemot lēmumu par piegādātāju.

Kā aprēķināt sava projekta ilgumu

Saskaitiet vienības, valstis un PVN reģistrācijas. Katra no tām tradicionālā ERP ir konfigurācijas darbs, bet API pirmā līmeņa sistēmā – uzņēmuma ieraksts.
Saskaitiet integrācijas un pirms līguma parakstīšanas pārbaudiet katras sistēmas API. Failu apmaiņas saskarne vien divkāršo integrācijas novērtējumu.
Izlemiet, cik lielu vēstures apjomu migrēt. Sākuma atlikumi un atvērtās pozīcijas prasa nedēļas; pilna vairāku gadu vēsture prasa mēnešus.
Izlemiet pārejas datumu, balstoties uz periodu kalendāru, nevis otrādi. Gada vai ceturkšņa beigu robeža ar saskaņotu slēguma atlikumu ir vislētākā pāreja, kāda iespējama.
Pieņemiet, ka pirmais slēgums aizņem divreiz ilgāku laiku nekā parasti, un ieplānojiet intensīvo uzraudzību pirmajai PVN deklarācijai un pirmajam algu aprēķinam no jaunās sistēmas.
Uzrakstiet pieņemšanas testu pirms projekta sākuma: dokumentu, atskaišu un deklarāciju sarakstu, kam pirmajam slēgtajam mēnesim ir pareizi jāiznāk no jaunās sistēmas. Pirmsražošanas testa plāns ir viena no sagatavēm grāmatvedības daļai.

FAQ

Vai ERP ieviešana var aizņemt mazāk nekā trīs mēnešus?

Jā, uzņēmumam ar vienu juridisko vienību, kas pieņem standarta procesus, migrē tikai sākuma atlikumus un kuram ir viena vai divas integrācijas. API pirmā līmeņa grāmatvedības kodolam pirmo strādājošo plūsmu mēra dienās, un garākais atlikušais elements parasti ir datu migrācijas pakotne.

Kurš posms kavējas visbiežāk?

Datu migrācija, kam seko integrācija. Abas ir atkarīgas no to sistēmu stāvokļa, kuras piegādātājs nekontrolē: jūsu esošo datu kvalitātes un to sistēmu API, kuras jūs pieslēdzat.

Vai mums vajadzētu migrēt pilnu vēsturi vai tikai sākuma atlikumus?

Sākuma atlikumi un atvērtās pozīcijas ir pietiekamas, lai jaunā sistēma būtu pilnīga no pārejas datuma, turklāt tas prasa tikai nelielu daļu no laika. Pilna vēsture ir nepieciešama tad, ja jaunajā sistēmā ir vajadzīgi salīdzinošie dati vai ja vecā sistēma tiek pilnībā izslēgta. Nordlet importētājs pieņem abus variantus.

Vai ieviešana pa posmiem ir ātrāka nekā pāreja uzreiz visā sistēmā (big-bang)?

Ieviešana pa posmiem kopumā aizņem ilgāku laiku, taču rada mazāku risku katrā solī un ļauj komandai mācīties no pirmās vienības pieredzes pirms nākamās. Pāreja uzreiz ir īsāka tad, ja organizācija ir pietiekami maza un viens nedēļas nogales pārejas logs aptver visu.

Ar ko "ieviešana" API pirmā līmeņa produktam atšķiras no parastās?

Nav ekrānu konfigurēšanas projekta. Darbs sastāv no integrācijas un migrācijas, ko izstrādātāji veic pret smilškati, bet atbilstības slānis (PVN noteikumi, deklarāciju formāti, kalendāri) ir iebūvēts pašā produktā. Trūkums ir tas, ka kādam jūsu pusē ir jāraksta kods.