Mennyi ideig tart egy ERP bevezetés? Reális ütemtervek

Fázisról fázisra bemutatjuk, mennyi ideig tart egy ERP-projekt, mi nyújtja el a folyamatot, és milyen ütemtervre számíthatunk egy API-n keresztül integrált számviteli mag esetében.

Egy kisvállalat, amely szabványos modulokat használó felhőalapú ERP-re vált, a szerződéskötéstől az élesítésig (go-live) tipikusan három-hat hónap alatt végez. Egy több vállalkozást, egyedi munkafolyamatokat és integrációkat felsorakoztató középvállalat számára ez általában hat-tizenkét hónapot vesz igénybe. Egy nagy multinacionális bevezetés egy-három évig tart, gyakran régiók vagy üzletágak szerinti hullámokban. Ezek a tartományok egybeesnek a bevezetési partnerek által publikált adatokkal és a pénzügyi csapatok beszámolóival; nem egy felmérés eredményei, így egy adott projekt mindkét irányba eltérhet tőlük.

Az egyetlen szám, amit mindenki tudni akar, nem létezik, mivel a „bevezetés” kilenc különálló feladatból áll, és mindegyik hossza olyan döntéseken múlik, amelyeket a vevő még a projekt kezdete előtt hoz meg. Ez a cikk ezekre a részekre bontja az ütemtervet, bemutatja, mi nyújtja el az egyes fázisokat, majd egy másik naptárat is felvázol: azt, amelyet akkor kapunk, ha a számviteli mag nem egy konfigurálandó rendszer, hanem egy olyan API, amellyel a saját szoftverünk kommunikál.

A kilenc fázis és ami mozgatja őket

Fázis	Tipikus időtartam	Mi határozza meg a hosszát?
Kiválasztás	1–3 hónap	A szűkített listára került szállítók száma, demókörzök, referencia-beszélgetések, beszerzési szabályok
Tervezés	2–8 hét	Hány folyamatot kell leképezni, egyetért-e velük a csapat, mennyire fogadják el a szállító alapértelmezett folyamatát úgy, ahogy van
Adatmigráció	4–16 hét	A törzsadatok minősége, hány év történeti adatait kell átvinni, a forrásrendszerek száma
Konfiguráció	4–12 hét	Jogi egységek száma, számlatükrök, országok, adórendszerek, jóváhagyási folyamatok
Integráció	4–20 hét	A kapcsolódó rendszerek száma (bank, bérszámfejtés, e-kereskedelem, CRM, raktár), az egyes oldali API-k minősége
Tesztelés	3–8 hét	Végpontok közötti (end-to-end) forgatókönyvek száma, a tesztadatok reálissága, hány hibát talál az első kör
Képzés	2–6 hét	Létszám, munkakörök sokszínűtsége, mennyire tér el az új folyamat a régitől
Élesítés (Go-live)	1–2 hét	Átállási módszer (big-bang vagy fázisolt), időzítés az időszak lezárásához igazítva
Hiperképzés és támogatás (Hypercare)	4–12 hét	Nyitott hibák száma az élesítéskor, az első havi zárás, az új rendszerből készülő első áfa-bevallás

A fázisok a gyakorlatban átfedik egymást. Az integráció akkor kezdődik, amikor a konfiguráció még fut; a képzés gyakran átfedésben van a teszteléssel. A reális terv nem az oszlop értékeinek összege, de a kritikus útvonal (critical path) általában az adatmigráción és az integráción vezet keresztül, és a legtöbb csúszás is ezen a kettőn menthető el.

Amitől hosszabb lesz a projekt

Testreszabás (Customisation). A szállító alapértelmezett viselkedésének minden egyes módosítását specifikálni, építeni, tesztelni, dokumentálni kell, majd minden jövőbeni frissítéskor újra tesztelni kell. Az a projekt, amely a folyamatok 90%-ában elfogadja a szabványos működést, a maradékot pedig testreszabja, általában célba ér; az a projekt viszont, amely a régi rendszer képernyőinek lemásolásával kezdi, ritkán.

Nem tiszta törzsadatok. Duplikált vevők, háromféleképpen írt nevű beszállítók, mértékegység nélküli cikkek, egy évtized alatt organikusan duzzadt számlatükör. A migráció nem lehet gyorsabb a tisztításnál, a tisztítást pedig azoknak az embereknek kell végezniük, akiknek van rendes napi munkájuk is. Ez a csúszó élesítési dátumok leggyakoribb, és az eredeti tervben a legkevésbé látható oka.

Több jogi egység. Minden egyes jogi entitásnak saját számlatükörre, számozásra, áfa-regisztrációra, bankszámlákra és időszakzárásra van szüksége. A köztük lévő vállalatcsoporton belüli (intercompany) folyamatok megtervezése önmagában is feladat. Szorozzuk meg a konfigurációs fázist a jogi egységek számával, majd adjuk hozzá a konszolidációs tervezést.

Többországos adózás. Az az vállalat, amely több uniós tagállamba értékesít, az új rendszerben még az első bevallás esedékessége előtt helyesen kell beállítania a teljesítési helyre vonatkozó szabályokat, az fordított adózást (reverse charge), az OSS-bevallást és a helyi adatszolgáltatási formátumokat. Ha egy ország lokalizációját a szállító helyett egy partner építette, akkor annak a partnernek a rendelkezésre állása a kritikus útvonal részévé válik.

Gyenge API-val rendelkező integrációk. Az olyan ERP, amely csak fájlalapú importot biztosít, minden csatlakoztatott rendszert kötegelt (batch) mintára kényszerít, és minden kötegelt minta olyan egyeztetési logikát igényel, amelyet val9nek meg kell írnia és tesztelnie kell.

A hatókör (scope) előtt rögzített élesítési dátum. Ha a dátumot politikai okokból tűzik ki, és a hatókört csak később határozzák meg, a projekt vagy a tesztelést rövidíti le, vagy eltolja a dátumot. Mindkettő költséges.

Amitől rövidebb lesz a projekt

A szállító alapértelmezett folyamatainak elfogadása ott, ahol a vállalat működése nem tér el a sztenderdtől.
A törzsadatok megtisztítása még a projekt kezdete előtt, nem pedig közben.
A teljes múltbeli előzmény helyett csak a nyitóegyenlegek és a nyitott tételek migrálása, a régi rendszer olvasható állapotban tartása mellett a keresésekhez.
Az átállási dátum megválasztása egy időszaki határvonalon, lezárt, egyeztetett záró főkönyvi kivonattal (trial balance).
Modulonként egyetlen felelős kijelölése döntési jogkörrel.
Tesztelés az elmúlt tizenkét hónap valódi bizonylataival, nem pedig kitalált mintákkal.
Olyan rendszer választása, amelynek az API-ja lehetővé teszi, hogy az integrációkat a konfigurációval párhuzamosan, ne pedig utána építsék meg és teszteljék.

Egy másik naptár: az API-központú számviteli mag

A fenti ütemtervek olyan rendszereket írnak le, amelyeket az emberek képernyőkön keresztül konfigurálnak, majd képernyőkön keresztül használnak. Létezik azonban a projekteknek egy másik típusa is, amely más ritmus szerint halad. Ha a számviteli mag egy számviteli API, az integrációs munka előrekerül, és a konfigurációs fázis nagy része eltűnik, mivel kevesebbet kell beállítani: a számlatükör, az adószabályok és a bevallási formátumok a termékkel együtt érkeznek.

Így néz ki ez a Nordlet esetében, a termék jelenlegi működése alapján, ígéretek helyett:

Első nap: egy tesztkörnyezet (sandbox) cég. Egy tesztkörnyezetben lévő cég az alkalmazásból vagy egyetlen API-hívással létrehozható. Pontosan úgy viselkedik, mint egy valódi vállalat, ugyanazokkal a modulokkal és végpontokkal, és annyit hozhat létre, amennyire szüksége van. A kezdeti lépések útmutatója (getting-started guide) végigvezeti az első hívásokon.

Az első-ötödik nap: az első működő folyamat. Hozzon létre egy partnert, hozzon létre egy számlát, állítsa ki, fogadjon be egy fizetést, és olvassa el a kiállítás által generált vegyes bizonylatot / könyvelési tételt (journal entry). Minden művelet egy POST /v1/{module}/{resource}/{action hívás JSON törzzsel, és mivel kilenc nyelvre léteznek típusos SDK-k, az első folyamat csak néhány tucat sornyi kód. Az újrapróbálkozások biztonságosak, mert az Idempotency-Key fejléccel a tárolt válasz játszódik vissza a második számla létrehozása helyett.

Második hét: adatelőzmények. A migrációs importőr átveszi a számlatükröt, a partnereket, a cikkeket, a nyitóegyenlegeket vagy a teljes könyvelési előzményt, a nyitott vevői és szállítói számlákat, a tárgyeszközöket az eddigi értékcsökkenéssel együtt, valamint a készletállományt, és mindezt egyetlen adatbázis-tranzakcióban írja be. A csak ellenőrzést végző végpont (migration/books/validate) lefuttat minden ellenőrzést anélkül, hogy bármit is rögzítene, így addig finomíthatja a csomagot, amíg az nem jelez hibát, és csak utána futtatja egyszer a migration/books/import parancsot. Ha bármelyik sor hibás, semmi sem kerül mentésre.

A második-negyedik hét: a többi integráció. Banki adatok PSD2 kapcsolaton keresztül, camt.053 kivonatimport, Stripe exportok, webhookok, például a sale_invoice.paid, hogy a rendszer pollolás helyett eseményekre reagáljon. Minden egyes elem külön végpont, amelyet egy-egy fejlesztő párhuzamosan építhet fel.

Megfelelőség (Compliance): már regisztrálva. A határokon átnyúló értékesítések áfa-kezelését az EU áfa-motor (EU VAT engine) oldja meg, a cég országának bevallási naptárát pedig a beépített szabályok töltik fel. A bevallás-támogatási táblázat (filing support table) mind a 30 ország esetében felsorolja, hogy a Nordlet mely határidőket vallja be saját maga, melyekhez készít fájlt, és melyeket kell kézzel rögzíteni. Ebből semmi sem jelent projektmunkát.

Az időszak lezárása mint teszt. Az első havi zárás az a pont, ahol egy ERP-projekt kideríti, hogy működik-e. Egy módosíthatatlan (immutable) főkönyvvel és időszakzárással (period locking) a zárolt hónapra eső könyvelési tétel 409-es hibával elutasításra kerül, így a zárást a rendszer kényszeríti ki a fegyelem helyett, és azok az integrációs hibák, amelyek csak a hiperképzés során derültek volna ki, már a tesztkörnyezetben felszínre kerülnek.

Ennek a naptárnak a becsületes korlátai: a számviteli, adózási és bevallási magot fedi le. Ha a projektjének raktárkezelésre, gyártásütemezésre vagy CRM-re is szüksége van, azok vagy olyan Nordlet-modulok, amelyeket ugyanezzel a módszerrel integrál (készlet, gyártás, e-kereskedelmi megrendelések, leadek), vagy mellette futó rendszerek, amelyeknek az integrációs munkája továbbra is az Öné. A Nordlet emellett fiatal termék, amely 2026-ban korai hozzáférésű (early access) fázisban van, és tervezési partnereket von be, amit minden szállítói döntés során érdemes figyelembe venni.

Hogyan becsülje meg a saját projektjét?

Számolja össze a jogi egységeket, országokat és áfa-regisztrációkat. Mindegyik konfigurációs munka a hagyományos ERP-ben, és egy céges rekord az API-központú rendszerben.
Számolja össze az integrációkat, és ellenőrizze az egyes rendszerek API-ját a szerződéskötés előtt. Egy kizárólag fájlalapú interfész nagyjából megduplázza az integrációs becslést.
Döntse el, mennyi előzményt szeretne migrálni. A nyitóegyenlegek és a nyitott tételek csak heteket vesznek igénybe; a teljes többéves előzmény hónapokat.
Az átállási dátumot az időszaki naptár alapján válassza ki, ne fordítva. Az év végi vagy negyedév végi határvonal egyeztetett záróegyenleggel a legolcsóbb átállás, ami létezik.
Számoljon azzal, hogy az első zárás a szokásos duplájáig tart, és tervezze be a hiperképzést az új rendszerből indított első áfa-bevalláshoz és az első bérszámfejtéshez.
Írja meg az elfogadási tesztet (acceptance test) a projekt kezdete előtt: azon bizonylatok, jelentések és bevallások listáját, amelyeknek az első lezárt hónapra vonatkozóan helyesen kell kiérkezniük az új rendszerből. A termelésbe állítás előtti tesztterv (pre-production test plan) az egyik sablon a számviteli részhez.

FAQ

Tarthat-e egy ERP bevezetés három hónapnál rövidebb ideig?

Igen, egy olyan egyfős vállalkozás esetében, amely elfogadja a szabványos folyamatokat, csak a nyitóegyenlegeket migrálja, és egy-két integrációval rendelkezik. Egy API-központú számviteli mag esetében az első működő folyamat napokban mérhető, és a leghosszabb fennmaradó elem általában az adatmigrációs csomag.

Melyik fázis csúszik leggyakrabban?

Az adatmigráció, amit az integráció követ. Mindkettő a szállító által nem ellenőrzött rendszerek állapotától függ: a meglévő adatok minőségétől és a csatlakoztatott rendszerek API-jaitól.

A teljes múltat migráljuk, vagy csak a nyitóegyenlegeket?

A nyitóegyenlegek és a nyitott tételek elegendőek ahhoz, hogy az új rendszer az átállási naptártól kezdve teljes legyen, ráadásul a töredékét ideig veszik igénybe. A teljes előzmény akkor éri meg, ha összehasonlító adatokra van szükség az új rendszeren belül, vagy ha a régi rendszert teljesen lekapcsolják. A Nordlet importőre mindkettőt elfogadja.

Gyorsabb-e a fázisolt bevezetés a big-bang átállásnál?

A fázisolt bevezetések összességében hosszabbak, de lépésenként kisebb kockázatot rejtenek, és lehetővé teszik, hogy a csapat tanuljon az első entitás tapasztalataiból a következő előtt. A big-bang rövidebb, ha a szervezet elég kicsi ahhoz, hogy egyetlen átállási hétvége alatt mindent lefedjen.

Miben különbözik a „bevezetés” egy API-központú terméknél?

Nincs képernyőről képernyőre történő konfigurációs projekt. A munka az integrációból és a migrációból áll, amit a fejlesztők egy tesztkörnyezetben végeznek el, míg a megfelelést biztosító réteg (áfa-szabályok, bevallási formátumok, naptárak) a termékkel együtt érkezik. Ennek ára az, hogy a Önök oldaláról valaki kódot ír.