Nordlet

← Tinklaraštis

Kodėl ERP diegimo projektai žlunga ir kaip API keičia šią statistiką

Septyni ERP projektuose pasikartojantys nesėkmės scenarijai, atsako priemonės į juos ir faktinė ataskaita, kurie iš jų eliminuojami naudojant apskaitos branduolį, sukurtą remiantis API pirmumo (API-first) filosofija.

Nordlet Team · · 8 min. skaitymo

ERP diegimo projektai žlunga dėl kelių trumpame sąraše surašytų priežasčių, kurios kartojasi iš projekto į projektą: nuolat augančio apimties (scope) plėtimosi, individualių pritaikymų (customisation), pakeičiančių standartinius procesus, niekieno neišvalytų duomenų, įgaliojimus priimti sprendimus turinčio asmens trūkumo, vienintelio atšaukti neleidžiančio starto (cutover) savaitgalio, priklausomybės nuo vieno tiekėjo produkto vystymo gairių (roadmap) bei mokesčių ar ataskaitų teikimo reikalavimų, paaiškėjančių jau po sistemos paleidimo (go-live). Siaurąja prasme tai nėra technologinės problemos. Kiekvienas iš šių punktų – tai sprendimas, kuris buvo priimtas (arba nepriimtas) dar nepritaikius nė vieno ekrano.

Šiame straipsnyje po vieną aptariamos šios priežastys ir nurodoma, ką reikėtų daryti kitaip. Tuomet pateikiamas konkretus, ribotas argumentas: kai sistemos apskaitos branduolys yra API, su kuriuo integruojasi jūsų pačių programinė įranga, kelios iš šių priežasčių yra ne sušvelninamos, o visiškai pašalinamos iš projekto, nes darbas, su kuriuo jos susijusios, tiesiog nustoja egzistuoti.

Pasikartojančios nesėkmių priežastys

1. Apimtis, kuri ne nustatoma, o „atrandama“

Projektas, dėl kurio pasirašyta sutartis siekiant įdiegti „finansus ir atsargas“, netrukus apima pirkimų tvirtinimus, projektų savikainą, klientų portalą ir atskirų ataskaitų sluoksnį, nes kiekvienas iš jų atrodo „beveik tas pats dalykas“. Tačiau biudžetas ir terminas buvo nustatyti pradinei apimčiai.

Alternatyva: pirmiausia parašykite priėmimo kriterijų sąrašą. Apimtis – tai dokumentų, ataskaitų ir deklaracijų sąrašas, kuris iš naujos sistemos turi teisingai išsilieti už vieną uždarytą mėnesį. Viskas, kas į šį sąrašą neįtraukta, yra atskiras projektas.

2. Individualūs pritaikymai (customisation), atkuriantys senąją sistemą

Brangiausias sakinys ERP projekte yra „naujoji sistema privalo viską daryti taip, kaip darome dabar“. Kiekvieną individualų pritaikymą reikia aprašyti, sukurti, ištestuoti, dokumentuoti ir iš naujo testuoti atliekant kiekvieną atnaujinimą. Projektai, prasidedantys nuo senųjų ekranų kopijavimo, paprastai niekada nebaigia šio kopijavimo proceso.

Alternatyva: priimkite standartinį tiekėjo procesą kiekvienam srautui, kuriame jūsų verslas iš esmės nesiskiria, ir turėkite rašytinį išimčių sąrašą su kiekvienos iš jų paaiškinimu. Jei šis sąrašas ilgas – klaidingas produktas, o ne konfigūracija.

3. Duomenys, kurių niekas neišvalė

Dubliuojantys partneriai, prekės be matavimo vienetų, sąskaitų planas su šimtais užmirštų kodų, atviros sąskaitos faktūros, kurios buvo apmokėtos prieš kelerius metus, bet niekada nesudengtos. Duomenų perkėlimas (migration) negali vykti greičiau nei jų valymas, o šį valymą atlieka tie patys žmonės, kurie turi uždaryti mėnesį.

Alternatyva: išvalykite duomenis prieš prasidedant projektui. Nuspręskite, ar perkelsite visą istoriją, ar tik pradinius likučius ir atvirus dokumentus. Validuokite perkėlimo paketą, kol jis pavyks be klaidų, prieš įrašydami bent vieną eilutę į naująją sistemą.

4. Nėra už proceso vykdymą atsakingo asmens (process owner)

Kai kiekvienas sprendimas keliauja į vadovų komitetą, sprendimų priėmimas užtrunka savaites. Kai už procesą nuo pardavimo iki pinigų gavimo niekas neatsako nuo pradžios iki pabaigos, pardavimų modulį ir gaututinų sumų modulį konfigūruoja skirtingi žmonės, turintys skirtingas prielaidas.

Alternatyva: paskirkite po vieną aiškiai įvardytą savininką kiekvienam procesui, turintį įgaliojimus priimti sprendimus, bei savaitinį sprendimų žurnalą (decision log), kuriuo vadovaujasi tiek tiekėjas, tiek visa komanda.

5. Didžiojo sprogimo („big-bang“) startas be atsitraukimo kelio

Visų subjektų ir visų modulių paleidimas vieną savaitgalį sutelkia visą riziką viename taške. Jei pirmojo mėnesio pabaigos uždarymas žlunga, nėra senosios sistemų bazės, prie kurios būtų galima sugrįžti, ir jokio dalinio diegimo, iš kurio būtų galima pasimokyti.

Alternatyva: pereikite prie naujos sistemos laikotarpio sandūroje, turėdami suderintą uždarymo bandomąjį balansą, išlaikykite senąją sistemą skaitomą, o jei yra keli subjektai – pradėkite veiklą nuo vieno iš jų.

6. Tiekėjo gniaužtai (vendor lock-in), pasireiškiantys trečiaisiais metais

Duomenų eksportas, reikalaujantis profesionalių paslaugų įsitraukimo, integracijos, veikiančios tik per paties tiekėjo tarpinę programinę įrangą (middleware), kainodara pagal naudotojų skaičių, auganti kartu su darbuotojų, o ne atlikto darbo skaičiumi, ir gairės (roadmap), kurioms negalite padaryti įtakos. Pasirašant sutartį visa tai nematoma; pratęsiant – matoma viskas.

Alternatyva: prieš pasirašydami sutartį, eksportuokite viską iš bandomosios aplinkos ir patikrinkite, kas iš jos išgaunama. Patikrinkite, ar API apima kiekvieną veiksmą, kurį atlieka ekranai, ar tik jų dalį. Perskaitykite kainoraštį kitam tarifų planui, o ne tik tam, kurį perkate dabar.

7. Atitikties reikalavimai, paaiškėję po starto

Naujas PVM mokėtojo kodas kitoje valstybėje narėje, nuo ateinančio sausio įsigaliojantis e. sąskaitų faktūrų teikimo mandatas, vietinės mokesčių administracijos pakeistas deklaracijos formatas. Tradiciniame projekte kiekvienas iš šių punktų reiškia arba partnerių įsitraukimą, arba individualų pritaikymą, ir kiekvienas atvyksta pagal savo kalendorių.

Alternatyva: prieš atlikdami pasirinkimą, kiekvienai šaliai surašykite kiekvieną deklaraciją ir PVM schemą, kuriai įmonė yra pavaldi, ir paprašykite tiekėjo bandomojoje aplinkoje parodyti kiekvieno iš jų išvesties failą. „Palaiko X šalį“ yra pardavimo teiginys; sugeneruota deklaracija yra įrodymas.

Ką keičia API?

Šiame straipsnyje dėstomas požiūris yra gana specifinis. API pagrįstas apskaitos branduolys savaip negarantuoja sėkmingo ERP projekto. Jis tiesiog pašalina specifinius darbų etapus iš projekto, o kartu su jais pasitraukia ir su šiais etapais susijusios nesėkmių priežastys. Toliau pateikiami dalykai, kuriuos „Nordlet“ atlieka jau šiandien – aprašant produktą tokį, koks jis yra, o ne žadant ateities rezultatus.

Integracija ištestuojama prieš pasirašant sutartį. Bandomoji įmonė (sandbox) sukuriama vienu užklausos iškvietimu, elgiasi tiksliai kaip tikra įmonė su tais pačiais moduliais bei galiniais punktais (endpoints) ir kainuoja tokiu pačiu tarifu kaip ir realus naudojimas. Priešgamybinis testavimo planas yra atgaminamas testas, o ne demonstracija. Jei integracija neveikia bandomojoje aplinkoje, tai sužinosite dar prieš prisiimdami bet kokius įsipareigojimus – tai visiškai priešinga tvarka nei tradicinio diegimo atveju, kai integracija yra priešpaskutinis etapas.

Pakartotiniai bandymai negali sukurti dublikatų. Kiekvienas duomenis keičiantis iškvietimas reikalauja antraštės Idempotency-Key. Toks pats raktas su tokiu pačiu naudinguoju krovininiu duomenų kiekiu (payload) grąžina išsaugotą atsakymą; toks pats raktas su kitu kroviniu atmetamas su klaida idempotency_key_reuse. Visa integracijos klaidų klasė – dviguba sąskaita faktūra po tinklo laiko viršinimo (timeout) – tiesiog negali įvykti, todėl jos negalima rasti ir po starto atliekamos intensyvios priežiūros metu. Mechanizmas aprašytas idempotencijos žurnalo įraše.

Įvykiai pakeičia paketinį (batch) sinchronizavimą. „Webhook“ pranešimai įrašomi į operacijų eilę (outbox) tos pačios duomenų bazės operacijos metu kaip ir pakeitimas, todėl atšauktas dokumentas niekada neišspinduliuoja įvykio ir nė vienas įvykis nepasimeta. Jūsų sistema reaguoja į sale_invoice.paid tuo momentu, kai tai įvyksta; čia nėra jokio naktinio failo, kurį reikėtų suderinti, ir jokios derinimo logikos, kurią reikėtų rašyti ar testuoti.

Didžioji knyga (ledger) už jus sugaudo integracijos klaidas. Duomenų bazė atmeta nesubalansuotą žurnalo įrašą. Užregistruotas įrašas nėra redaguojamas; taisymai atliekami koreguojamaisiais įrašais, susietais su pradiniais. Įrašas, kurio data patenka į užrakintą laikotarpį, atmetamas grąžinant 409 kodą. Šie apribojimai yra tai, ką praktikoje reiškia nekintama didžioji knyga, ir jie paverčia tylias duomenų problemas akivaizdžiosiomis API klaidomis kūrimo etape.

PVM taisyklės ir deklaracijų formatai yra tiekėjo priežiūros rūpestis, o ne jūsų pritaikymas. ES PVM variklis nustato prekių tiekimo vietą, atvirkštinį apmokestinimą (reverse charge), OSS, IOSS bei fiksuotojo tiekėjo taisykles ir su kiekvienu atsakymu pateikia teisinį pagrindą. 30-ies šalių deklaracijų formatai yra užregistruoti produkto viduje; deklaracijų palaikymo lentelė kiekvienam terminui nurodo, ar „Nordlet“ išsiunčia failą pati, ar sugeneruoja jį įkėlimui, ar tiesiog parodo duomenis, kuriuos reikia suvesti ranka. Pasikeitus formatui, pakeitimas išplatinamas kaip produkto atnaujinimas kiekvienai įmonei, o produkto pakeitimai skelbiami pakeitimų žurnale (changelog). Atitikties reikalavimai, paaiškėję po starto (7 priežastis), tampa klausimu, į kurį prieš pasirinkimą galite atsakyti apsilankę viešajame puslapyje.

Kainodara nepriklauso nuo darbo vietų (seats) skaičiaus. Planai yra apmokestinami pagal užklausų skaičių, kiekviename plane yra visi moduliai, visa API bei neribotas naudotojų ir įmonių skaičius. Kaina auga kartu su sistemos atliekamu darbu, o ne su prisijungusių žmonių skaičiumi, ir čia nėra jokių funkcijų pakopų (tiers), į kurias vėliau tektų migruoti. Tai išsprendžia vieną iš priklausomybės nuo tiekėjo dalių (6 priežastis); kitų ji neišsprendžia, todėl ir egzistuoja kitas skyrius.

Duomenys išeina tokie patys, kokie įėjo. Ataskaitos generuojamos XLSX, PDF arba JSON formatais. Didžiosios knygos eksportai atitinkamoms šalims pateikiami DATEV, FEC ir SIE formatais. Žiniatinklio programėlė neturi privačių galinių punktų, todėl viskas, ką matote ekrane, gali būti pasiekiama ir per API. Eksporto testą iš 6 priežasties galima paleisti bandomojoje aplinkoje jau pirmąją dieną.

Ko API nekeičia

  • Pagrindiniai duomenys (master data) vis tiek yra jūsų atsakomybė – juos turite išsivalyti patys. Perkėlimo importavimo įrankis validuoja ir atmeta blogus paketus, bet jų netaiso.
  • Procesų valdymas vis tiek yra personalo sprendimas. API sumažina klausimą „kas sprendžia“, nes yra mažiau konfigūracijos, tačiau į patį klausimą neatsako.
  • Kažkas vis tiek turi rašyti kodą. Konfigūracijos projektas pakeičiamas programuotojų atliekamu integracijos projektu. Jei jūsų komandoje nėra programuotojų, tokio tipo produktas darbą tik perkelia, o ne pašalina.
  • Apimtis už apskaitos ribų vis tiek lieka apimtimi. Sandėlių planavimas, gamybos planavimas ir CRM sistema (neapsiribojant vien tik užklausomis) yra arba atskiri „Nordlet“ moduliai, kuriuos integruosite lygiai taip pat, arba atskiros šalia veikiančios sistemos, o integracija tarp jų vis tiek lieka jūsų projektu.
  • Tiekėjo branda. „Nordlet“ 2026 metais veikia ankstyvosios prieigos (early access) režimu ir pasitelkia bandomuosius partnerius (design partners). Jaunas tiekėjas yra rizikos veiksnyje, kurio bandomasis testas nepašalina – jis tik leidžia išmatuoti dabartinę produkto būseną.

Trumpas kontrolinis sąrašas prieš pasirašant bet kokias sutartis

  1. Surašykite priėmimo kriterijų sąrašą: dokumentai, ataskaitos, deklaracijos už vieną uždarytą mėnesį.
  2. Išvalykite pagrindinius duomenis ir išspręskite istorijos klausimą prieš prasidedant projektui.
  3. Kiekvienam procesui paskirkite po vieną atsakingą asmenį.
  4. Paleiskite integraciją bandomojoje aplinkoje ir išsaugokite testavimo rinkinį (test suite).
  5. Eksportuokite viską iš bandomosios įmonės ir patikrinkite failus.
  6. Kiekvienai šaliai peržiūrėkite sugeneruotą deklaraciją, o ne funkcijų sąrašą.
  7. Perskaitykite aukštesnio nei perkate plano kainą bei pasitraukimo iš sistemos kainą.

D.U.K.

Kokia yra pati dažniausia ERP projektų žlugimo priežastis?

Apimties išsiplėtimas po to, kai biudžetas ir terminai jau buvo patvirtinti, dažniausiai pasireiškiantis per individualių pritaikymų užklausas, atkuriančias senąją sistemą. Duomenų kokybė užima antrąją vietą ir yra dažniausia nukelto starto termino priežastis.

Ar debesijos (cloud) ERP pasirinkimas padeda išvengti šių nesėkmių?

Priegloba (hosting) tik pakeičia tai, kas valdo serverius. Ji nekeičia apimties, pritaikymų, duomenų kokybės ar atsakomybės. Visgi debesijos produktai padeda užtikrinti, kad atnaujinimai tampa paties tiekėjo rūpesčiu, o tai pašalina vieną ilgalaikį individualių pritaikymų palaikymo kaštų elementą.

Kaip API pagrįsta sistema sumažina diegimo riziką?

Ji perkelia integraciją į projekto pradžią, kur ją galima ištestuoti bandomojoje aplinkoje dar prieš prisiimant įsipareigojimus, užtikrina, kad pakartotiniai bandymai ir įvykiai būtų saugūs jau pačios savo architektūros dėka, bei pateikia mokesčių taisykles ir deklaracijų formatus kaip gatavas produkto funkcijas, o ne kaip projektinius pritaikymus. Ji neišvalo jūsų duomenų ir nenustato jūsų procesų už jus.

Ar API pagrįstas apskaitos branduolys yra ERP?

Tai finansinis jo branduolys: didžioji knyga, dokumentai, bankas, mokesčiai, deklaracijos, o „Nordlet“ atveju – taip pat atsargos, gamyba, darbo užmokestis, ilgalaikis turtas ir e. prekybos užsakymai. SaaS ERP straipsnyje šis skirtumas aptartas išsamiai.

Ką turėtume ištestuoti bandomojoje aplinkoje?

Išrašykite sąskaitą faktūrą ir perskaitykite žurnalo įrašą. Nusiųskite tą pačią užklausą du kartus ir suskaičiuokite sąskaitas. Užregistruokite operaciją į užrakintą laikotarpį ir patvirtinkite, kad grąžintas 409 kodas. Išrašykite kreditinę sąskaitą ir patikrinkite anuliavimą. Sugeneruokite PVM deklaraciją bandomosios įmonės šaliai. Eksportuokite didžiąją knygą. Jei šie punktai pavyksta, apskaitos branduolys veikia; likusi rizika slypi jūsų duomenyse ir kitose sistemose.

Papildomas skaitinys