Egyedi ERP vagy testreszabott kész ERP?

A Mesterséges Intelligencia Központ Kft. budapesti szoftverfejlesztő cég szerint a kész ERP akkor jó, ha a folyamatok a szabványhoz igazíthatók; egyedi ERP akkor, ha a működés eltérő, vagy a testreszabás már a frissítést veszélyeztetné.

Lényeg: Három út van: a kész ERP úgy, ahogy van; a beállított és a gyártó bővítési pontjain kiegészített kész ERP; és az egyedi ERP. Minél mélyebben kellene a kész rendszer magjába nyúlni, annál inkább érdemes az egyedi részt külön modulba tenni, vagy saját rendszert építeni. Az átállás bármelyik úton szakaszosan, előzetes adattisztítással jár kisebb kockázattal, mint egy egyszeri, nagy váltás.

Mi az ERP?

Az ERP (enterprise resource planning, magyarul vállalatirányítási rendszer) a cég alapfolyamatait egy rendszerben fogja össze. A Microsoft meghatározása szerint az ERP olyan üzletviteli szoftver, amely segít a szervezeteknek integrálni az alapfolyamataikat, például a pénzügyet, az ellátási láncot, a gyártást, az emberi erőforrásokat, a beszerzést és a projektmenedzsmentet (Microsoft: What is ERP?).

A gyakorlatban az ERP értéke abban van, hogy ugyanaz az adat csak egyszer születik meg: a beérkező rendelésből lesz a raktári kiadás, abból a számla, a számlából a könyvelési tétel és a kintlévőség. Ha ezek a lépések külön programokban és táblázatokban élnek, az adat kézzel vándorol, és vele együtt vándorolnak a hibák is. Az ügyfelek és az értékesítés követése rokon terület, de külön döntés; erről a Mikor éri meg egyedi CRM-et fejleszteni? cikkben írunk.

Három út egy ERP-hez

Az „egyedi vagy kész” kérdés valójában három lehetőség közötti választás. A határ nem éles, de a különbség a költségben, a frissítésekben és a függőségben jelentős.

Kész ERP úgy, ahogy van

A cég egy kész terméket vezet be, és a saját folyamatait a termék szabványos működéséhez igazítja. Ez akkor működik jól, ha a folyamatok szokásosak, és a cég kész változtatni a megszokott munkamódon. Előnye a gyorsabb indulás és a gyártó által szállított frissítés; hátránya, hogy ami a termékből kimarad, az táblázatban vagy kézi munkában folytatódik.

Kész ERP beállítva és bővítve

A legtöbb bevezetés valahol itt tart. Érdemes három dolgot megkülönböztetni, mert a frissíthetőség szempontjából nagyon mást jelentenek:

Konfiguráció (beállítás): a gyártó által előre megadott lehetőségek használata programozás nélkül (munkafolyamatok, jóváhagyási szintek, mezők, nyomtatványok, jogosultságok).
Bővítés (extension): új funkció a gyártó által támogatott, dokumentált bővítési pontokon és felületeken keresztül, a termék saját kódjának módosítása nélkül.
Módosítás (a mag testreszabása): a gyártó saját kódjának vagy objektumainak átírása, illetve lemásolása és átírása. Ez adja a legtöbb szabadságot, de a gyártók saját dokumentációja szerint a frissítéseknél ez jár a legtöbb kockázattal (lásd lent).

Egyedi ERP

A rendszer a cég saját folyamataira és adatmodelljére épül, és csak az készül el, amire valóban szükség van. Nincs gyári mag, amelyet frissíteni kellene, a továbbfejlesztésről a megrendelő dönt. Cserébe a fejlesztést, az üzemeltetést és a karbantartást is meg kell szervezni, saját csapattal vagy szerződött fejlesztővel. Az egyedi és a kész szoftver általános mérlegeléséről az Egyedi szoftver vagy kész megoldás (SaaS)? cikk szól.

Miért nehezíti a frissítést a sok testreszabás?

A kész ERP gyártója rendszeresen ad ki javításokat és új verziókat. Ha a cég a gyári kódot módosította, minden frissítésnél ellenőrizni kell, hogy a módosítás még működik-e, és sokszor át is kell írni. A nagy gyártók saját dokumentációja ugyanerre jut:

SAP: a „clean core” (tiszta mag) megközelítés szerint a bővítéseket szigorúan elkülönítve kell tartani az SAP-alkalmazástól, jól meghatározott, frissítésálló felületeken keresztül; a gyári objektumok közvetlen módosítását vagy lemásolását a gyártó problémásabbnak tartja, mert minden javítócsomag vagy frissítés után alapos újratesztelést igényelhet (SAP Learning: Introducing the Clean Core Approach).
Microsoft Dynamics 365: a Finance, Supply Chain és Commerce termékeknél a gyártó azzal indokolja a bővítésen alapuló modellt, hogy a felhő és a gyakori frissítések kevésbé beavatkozó testreszabást kívánnak, így a frissítések kisebb eséllyel érintik az egyedi megoldásokat; ezekben a termékekben a bővítés az egyetlen testreszabási mód, az alkalmazáskód felülírása (overlayering) nem támogatott (Microsoft Learn: Extensibility home page).
Odoo: a dokumentáció szerint az egyedi modulokat tartalmazó adatbázis addig nem frissíthető, amíg az egyedi modulok el nem készülnek a célverzióra, és a kompatibilitásért az egyedi modul karbantartója felel (Odoo: Upgrade).

A tanulság az SAP-nál és a Microsoftnál ugyanaz: a mag maradjon érintetlen, és ami a cégben egyedi, az elkülöníthető bővítésben vagy külön modulban éljen, amely dokumentált felületen beszélget a kész rendszerrel; az Odoo-nál pedig az egyedi modulok karbantartása határozza meg, mikor frissíthető a rendszer. Ha a szükséges egyediség olyan nagy, hogy ezt már nem lehet tisztán megoldani, az erős jel az egyedi ERP vagy egy egyedi modul mellett.

Magyar sajátosságok: NAV Online Számla, számlázás, bank, webshop

Egy magyar cég ERP-jének hazai rendszerekkel is együtt kell működnie. A legfontosabb a NAV Online Számla: a NAV tájékoztatása szerint 2021. január 4-től kötelező adatot küldeni minden olyan számláról, módosító és érvénytelenítő számláról, amelyre az áfatörvény számlázási szabályai vonatkoznak (NAV: Online Számla).

A rendszerek közötti kapcsolat (gépi interfész) támogatott változata a 3.0-s (ellenőrizve: 2026. október 17.). Az interfész-specifikáció szerint a számlázó programnak az adatszolgáltatást automatikusan, a folyamaton belül külön emberi beavatkozás nélkül kell teljesítenie; a NAV a beküldött adatot aszinkron módon dolgozza fel, és az adatszolgáltatás addig nem tekinthető teljesítettnek, amíg a program meg nem győződött a feldolgozás sikeréről, és meg nem kapta a számlához tartozó nyugtaüzenetet (NAV Online Számla: Dokumentációk). A NAV a specifikációt időnként módosítja (2026 augusztusában is közzétett egy módosított változatot), ezért a bekötést karban kell tartani.

Amit egy magyar ERP-nek jellemzően tudnia kell, és amit mi bekötünk:

NAV Online Számla: a számlaadatok beküldése a gépi interfészen, a feldolgozási eredmény lekérdezése és a hibák kezelése.
Számlázó szolgáltatások: ha a számlázás egy külső számlázóban marad, a kapcsolat az interfészén keresztül.
Bankok: a banki kivonatok és tranzakciók beolvasása, a jóváírások párosítása a számlákkal.
Webshop: a rendelések, a készlet és az árak szinkronizálása a webáruház és az ERP között.
Futárszolgálatok és egyéb rendszerek: csomagfeladás, a meglévő CRM, a levelezés és a naptár.

Kész ERP választásakor érdemes megkérdezni, van-e a terméknek magyar lokalizációja, ki tartja karban a NAV-bekötést, ha a specifikáció változik, és milyen a kapcsolat a hazai bankokkal és számlázókkal. Egyedi ERP-nél ugyanezek a bekötések a fejlesztés részei. A rendszerek összekötéséről a Folyamatautomatizálás oldalon írunk részletesebben.

Döntési táblázat

Szempont	Kész ERP, ahogy van	Bővített kész ERP	Egyedi ERP
Illeszkedés a folyamatokhoz	a cég a szabványos folyamatokhoz igazodik	a szabvány nagy része jó, néhány pont egyedi	a működés lényegesen eltér a szabványtól
Indulás	jellemzően gyors, ha a beállítás elég	a bővítések fejlesztésével hosszabb	a fejlesztés idejét igényli, szakaszosan is indulhat
Frissítések	a gyártó szállítja, kevés kockázattal	a bővítéseket minden frissítésnél ellenőrizni kell	a megrendelő ütemezi, a fejlesztő végzi
Egyedi folyamatok	csak beállításokkal	bővítési pontokon vagy külön modulban	bármilyen üzleti logika
Integrációk	a gyártó és a partnerei összekötőivel	összekötők és egyedi integrációk	bármivel, aminek elérhető a felülete vagy az adata
Költségszerkezet	licenc- vagy előfizetési díj a gyártó feltételei szerint	licenc, plusz a bővítések fejlesztése és karbantartása	fejlesztés, üzemeltetés és továbbfejlesztés
Függőség	a gyártótól és a termék jövőjétől	a gyártótól és a bővítéseket fejlesztő partnertől	a forráskód birtokában más fejlesztővel is továbbvihető
Kinek való?	szokásos működésű cégnek, gyors indulással	akinek a szabvány jó alap, de néhány ponton más	akinek a működése vagy az integrációi egyediek

Gyakori a vegyes megoldás is: a kész ERP marad a pénzügyre és a könyvelésre, a cég sajátos folyamatai (például egy egyedi gyártásütemezés vagy árazás) pedig külön, egyedi modulban futnak, amely interfészen keresztül beszélget a kész rendszerrel.

Átállás a régi rendszerről

Egy ERP-projekt ritkán indul üres lappal: van egy régi program, egy kész rendszer vagy egy táblázatrendszer, amelyben évek adatai élnek. Az átállás lépései:

Felmérés: milyen adatok, folyamatok és kapcsolatok vannak, és mi az, ami ma táblázatban, a rendszeren kívül fut.
Adatleltár és adattisztítás: a kettőzött ügyfelek, a hiányos cikktörzs és az elavult tételek rendbetétele még a költöztetés előtt.
Adatleképezés: melyik régi mező hová kerül az új rendszerben, és mi történik a régi, lezárt tételekkel.
Próbaköltöztetés: a régi adatok tesztkörnyezetbe kerülnek, ahol a kulcsfelhasználók valós eseteken ellenőrzik őket.
Szakaszos élesítés: modulonként vagy telephelyenként, esetleg a régi és az új rendszer rövid párhuzamos futtatásával, hogy a napi munka ne álljon meg.
Utókövetés: hibajavítás, kiegészítő betanítás és üzemeltetés az éles indulás után.

Nem kell mindent egyszerre lecserélni. Sokszor az a járható út, ha az új modul előbb a régi rendszer mellé kerül, és a kettő interfészen keresztül cserél adatot, amíg a régi rész ki nem váltható.

Kockázatok és csökkentésük

Túl nagy első szakasz: ha minden egyszerre indul, egy hiba az egész céget megállítja. Érdemes egy jól körülhatárolt modullal kezdeni.
Rendezetlen adatok: a hibás adat az új rendszerben is hibás marad. Az adattisztítás a projekt része, nem utólagos feladat.
Rejtett folyamatok: sok fontos lépés táblázatokban vagy egy-egy munkatárs fejében él. A felmérésnek ezeket is fel kell tárnia.
Kulcsfelhasználók hiánya: ha a napi munkát végzők nem vesznek részt a tervezésben és a tesztelésben, a rendszer mellett tovább él a táblázat.
Integrációs hibák: a NAV-, a banki és a webshopkapcsolatba naplózás és hibajelzés kell, hogy egy elakadt szinkron ne maradjon észrevétlen.
Egyoldalú függés: a teljes forráskód és a dokumentáció átadása biztosítja, hogy a rendszer később más fejlesztővel is továbbvihető legyen.

Hol segít a mesterséges intelligencia az ERP-ben?

A nagy nyelvi modellek (az OpenAI ChatGPT-je, az Anthropic Claude-ja és a Google Geminije) ott hasznosak, ahol eddig ember olvasott, másolt vagy fogalmazott:

Dokumentumok: a bejövő számlák, szállítólevelek és megrendelések adatainak kiolvasása, ellenőrzésre előkészített rögzítéssel.
Levelezés: a beérkező megrendelő e-mailek feldolgozása és a válaszvázlat előkészítése.
Kérdés az adatokhoz: hétköznapi nyelvű kérdés a rendszerhez, például arról, mely vevők tartoznak lejárt számlával.
Eltérések jelzése: a szokatlan tételek kiemelése ellenőrzésre, például egy olyan rendelésé, amely nagyon eltér az ügyfél korábbi rendeléseitől.

Ahol a tévedés pénzbe kerül, ott az AI javasol, és ember hagyja jóvá. A modellek bekötéséről és az adatvédelemről az AI-integráció oldalon írunk.

Tapasztalatunk

Jelenleg is egy nagy ERP- és CRM-rendszert fejlesztünk; az ügyfél és a termék nevét nem közöljük. Egy ERP-ben ritkán a képernyő a nehéz rész: az adatmodell, a jogosultságok, az integrációk és a régi adatok átvétele dönti el, hogy a munkatársak a rendszert fogják használni, vagy mellette tovább vezetik a táblázatot.

Gyakori kérdések

Mikor éri meg egyedi ERP-t fejleszteni?

Akkor, ha a cég működése lényegesen eltér attól, amire a kész ERP-k épülnek, és ezt az eltérést meg akarja tartani; ha sok rendszert kell összekötni, és nincs hozzájuk kész összekötő; vagy ha a szükséges testreszabás már a gyári mag módosítását kívánná. Ha egy kész ERP a folyamatok nagy részét beállításokkal lefedi, általában az a gyorsabb út, és ezt az első egyeztetésen meg is mondjuk.

Mennyire szabható testre egy kész ERP?

Sokféleképpen, de nem mindegy, hogyan. A beállítások (konfiguráció) és a gyártó által támogatott bővítési pontok a frissítéseket kevéssé érintik; a gyári kód módosítása viszont minden frissítésnél újabb munkát okozhat. A nagy gyártók (az SAP és a Microsoft) dokumentációja a mag érintetlenül hagyását és az elkülönített bővítést javasolja; az Odoo dokumentációja szerint az egyedi modulok karbantartása a frissítés feltétele.

Mi a kockázata a sok testreszabásnak?

Elsősorban az, hogy a frissítések drágák és kockázatosak lesznek: minden új verziónál ellenőrizni és sokszor át kell írni a módosításokat, egyes gyártóknál pedig a frissítés addig el sem végezhető, amíg az egyedi részek el nem készülnek az új verzióra. Emellett a cég a bővítéseket fejlesztő partnertől is függővé válik. Ha a testreszabás mértéke ezt indokolja, érdemes összevetni egy egyedi modul vagy egy egyedi ERP költségével.

Hogyan zajlik az átállás a régi rendszerről?

Felméréssel, adattisztítással és adatleképezéssel kezdődik, ezt próbaköltöztetés követi tesztkörnyezetben, majd szakaszos élesítés: modulonként, vagy a régi és az új rendszer rövid párhuzamos futtatásával. Az éles indulás után hibajavítás és üzemeltetés következik. A régi rendszer egy ideig az új mellett is futhat, interfészen keresztül összekötve.

Bekötik a NAV Online Számlát?

Igen. A számlaadatokat a NAV gépi interfészén küldjük be, lekérdezzük a feldolgozás eredményét, és kezeljük a hibákat, ahogy a NAV interfész-specifikációja előírja. Ugyanígy bekötjük a külső számlázó szolgáltatásokat, a bankokat és a webshopot is.

Hogyan segítünk?

A Mesterséges Intelligencia Központ Kft. egyedi ERP-, CRM- és ügyviteli rendszereket fejleszt, kész rendszerekhez egyedi modult és integrációt készít, és mesterséges intelligenciával köti össze őket. Az első egyeztetés díjmentes, és ha egy kész ERP elég, azt is megmondjuk. A fejlesztés funkcionális méretét COSMIC funkciópontban (ISO/IEC 19761) mérjük, és ebből készül az ajánlat és az ütemezés; a módszert az Árazás oldal írja le. Kérésre titoktartási szerződést (NDA) kötünk, és átadás után az üzemeltetést és a karbantartást is vállaljuk. A forráskódról és a felhasználási jogokról a szerződés rendelkezik.

Részletek az Üzleti szoftverek oldalon. Ha a saját rendszerükről beszélnének velünk, írjanak nekünk a Kapcsolat oldalon megadott elérhetőségeken.