Egy belső rendszerbe került a pénzügy, a készlet és a gyártás a saját cégünknél

Saját cégünk esete, név nélkül. Személyes és pénzügyi részletet nem közlünk.

Röviden: a saját gyártó-forgalmazó cégünknél a termékszintű eredmény, a valós havi eredménykimutatás, a készlet és a gyártás követése hiányzott, mert az adat a webshopban, a számlázóban, a bankban és a hirdetési fiókokban élt. Szakaszosan épült egy belső ügyviteli rendszer, ellenőrző szabályokkal és kézikönyvekkel. Elkészült, és a csapatnak átadtuk: benne a pénzügy, a készlet és a gyártás egy helyen áll össze.

Hónap vége. A hirdetési fiók szerint egy termék jól megy, a számlázó szerint sokat adtunk el belőle. Hogy a cég keresett-e rajta, azt egyik sem mondja meg, mert az önköltség egy harmadik helyen van, a gyártás egy negyediken, és a kettőt kézzel kell összeolvasni.

Ebben az ERP esettanulmányban a szó azt jelenti: egy belső rendszer, amely a meglévő forrásokból olvas, és összeköti a pénzügyet, a készletet, a gyártást és az ügyfélszolgálatot. Nem a meglévő programokat váltja ki, hanem a köztük lévő hézagot tölti ki.

A kiinduló helyzet: minden adat megvolt, csak nem egy helyen

A cég nem adathiánnyal küzdött, hanem szétszórtsággal. A rendelések a webshopmotorban, a számlák a számlázóban, a pénzmozgás a bankban, a hirdetési költség a hirdetési fiókokban élt. Mindegyik pontos volt a saját területén, de egy kérdésre, amely több területet érint, egyik sem tudott válaszolni.

A legfájóbb kérdés az volt, melyik termék hozza a pénzt, és melyik viszi. Erre csak becslés volt, és a becslés attól függött, ki készítette és melyik táblázatból.

A készlet és a gyártás ugyanígy élt: a raktárban mindenki tudta nagyjából, mi van, de a „nagyjából” nem elég, amikor a B2B-rendelés jön, és a szállítólevélen pontos tételnek kell állnia.

A gyártásban mindenki ismeri a darabjegyzéket: ha egy alkatrész hiányzik belőle, a termék nem áll össze. Nálunk a pénzügyi kép darabjegyzéke volt hiányos. Minden alkatrész létezett, csak senki nem rakta össze őket egy kimutatásba.

Mit építettünk, modulonként

A rendszer nem egyszerre készült el, hanem modulonként, a hiányok mentén. Az alapozás a pénzügyi lánc és a B2B-rendelés volt, valós adattal. Erre épült az újratervezett felület. A gondozás szakaszában a leltár, az ügyfélszolgálat és végül az önköltség-lánc került sorra, amely a kimutatást valóssá tette.

Pénzügyi lánc valós adattal. Ebben a modulban a banki és pénztári mozgások és a költségek kerültek be, nem mintaadattal, hanem a cég saját adatával. Így már az elején kiderült, hol nem illeszkedik egy forrás a többihez.

B2B-rendelés. A partneri rendeléshez szállítólevél, partnerfelvételi varázsló és kézikönyv készült, hogy a rendelés ne levélváltásban és táblázatban éljen.

Felület-újratervezés. A korábbi, menet közben nőtt felületet fázisokban terveztük újra, hogy a napi munka ne álljon le közben.

Leltár-modul a négy szem elvével. A leltárt egy ember rögzíti, egy másik hagyja jóvá. A modulhoz ellenőrző szabályok tartoznak, amelyeknek minden módosítás után teljesülniük kell. A számviteli törvény a mérleg tételeit leltárral kéri alátámasztani (Számviteli törvény 69. §, Nemzeti Jogszabálytár, 2000), így ez a modul nem kényelmi funkció, hanem a kimutatás hitelességének alapja.

Hívásnapló és vevőkereső. Az ügyfélszolgálat egy helyen látja, ki hívott, miért, és mi lett a vége.

Önköltség-lánc. Végül a beszerzés, a gyártás és a készletmozgás összekötése következett, így a havi eredménykimutatásban az önköltség már nem becslés.

Mi készült el

A cégnél maradt maga a belső rendszer, a hozzá tartozó kézikönyvek, és egy ellenőrző kapu a szabályaival. A rendszer elkészült, és a csapatnak átadtuk. A kézikönyvek a napi folyamatokat írják le, a kapu pedig minden módosítás után megnézi, hogy a könyvelési és készletszabályok még teljesülnek-e.

Példa (szemléltető, nem valós tétel): egy ellenőrző szabály. „Egy termék készlete nem lehet kevesebb, mint amennyit a nyitott szállítólevelek lefoglalnak.” Ha egy módosítás után ez nem teljesül, a kapu megállítja a változást, és megmutatja, melyik tételnél csúszott el.

Mit döntöttem a felületről és a lánc végén

A felület újratervezésénél nem darabonként hagytam jóvá a változásokat, hanem a teljes újratervezést egyben kértem, fázisokra bontva. A menet közben nőtt felületen minden új modul egy újabb folt lett volna, és a fázisok miatt a napi munkának nem kellett megállnia, amíg az új felület elkészül.

A záró szakaszban egy csomagban döntöttem a felgyűlt nyitott kérdésekről. Ezeket nem a fejlesztés zárta le, hanem én: ahol a rendszer két lehetséges utat mutatott, a választás tulajdonosi döntés maradt.

A legfontosabb megfigyelés az volt, hogy a termékszintű eredmény nem egy jelentés, hanem egy lánc. Ha a lánc egy pontja becslés, az egész becslés marad, akármilyen pontos a többi.

Mi jön ezután: rendszeres leltár, és a lánc teljes

A következő lépés a rendszeres fizikai leltár a leltár-modulban: egy ember számol, egy másik jóváhagy, és a rendszer onnantól minden hónapban azzal az áruval számol, amely ténylegesen a polcon van. Ezzel áll össze végleg a lánc a beszerzéstől a termékszintű eredményig, és a havi kimutatás minden sora mögött ellenőrzött adat áll.

A rendszer a hiányok mentén nőtt, és ugyanígy bővíthető tovább: új hiány, új modul, hozzá ellenőrző szabály. Ha az önköltség szabálya változik, azt mi mondjuk ki, a kapu pedig minden változás után ellenőrzi, hogy a számok összeállnak-e.

Időkeret: nyártól az ősz közepéig

A munka 2026 nyarának közepén indult. A pénzügyi lánc, a B2B-rendelés és a kézikönyvek a nyár folyamán álltak össze. A felület újratervezése az ősz elején zajlott, utána jött a leltár-modul, a hívásnapló és a vevőkereső. Az önköltség-lánc az ősz közepén elkészült, és a döntéscsomaggal együtt átadtuk.

A sorrend a hiányokat követte, nem egy előre megírt tervet. Az alapozó modulok, a pénzügyi lánc és a B2B-rendelés kerültek előre, mert nélkülük a többi modul adatát sem lett volna mihez kötni. A kezelhetőség ezért később jött: a felület újratervezése akkor következett, amikor a lánc már működött.

Az önköltség-lánc azért került a végére, mert a beszerzés, a gyártás és a készlet adatára épül: ezeknek már a rendszerben kellett lenniük, mielőtt össze lehetett kötni őket. Ha a sorrend fordított, a lánc becsült adatokat kötött volna össze, és a kimutatás ugyanúgy becslés maradt volna, mint előtte.

Mit vihetsz el ebből a saját cégedhez

Mielőtt rendszert választasz vagy építesz, írd fel azt a kérdést, amelyre ma nem tudsz válaszolni, és nézd meg, hány adatforrásból kellene összerakni a választ. Ha a válasz több forrásban él, a hiány nem a programokban van, hanem a köztük lévő kapcsolatban, és azt kell először pótolni.

• Kezdd a pénzügyi lánccal, saját, valós adattal. A mintaadat elrejti a forrásaid közötti eltéréseket.
• A számlát a számlázód állítsa ki, ne egy házi rendszer: a számlázó programok a számla adatait a NAV Online Számla rendszerébe küldik (NAV Online Számla, 2026), ezt nem érdemes újraépíteni.
• A leltárhoz rendelj két embert: egy rögzít, egy jóváhagy.
• Döntsd el előre, mit számolsz önköltségnek. Ha ez nincs leírva, a kimutatás minden hónapban vita lesz.

A gyártó cégek oldaláról az AI a gyártó cégnél cikk szól. A havi számlagyűjtés egy kisebb saját eset ugyanazzal a hiánylista-logikával, a többi az AI-bevezetés esettanulmányai között.

A döntés, amit ezen a héten meghozhatsz: ki számolja meg nálad a raktárat, és milyen rendszerességgel.

Gyakori kérdések

Miért nem egy dobozos ügyviteli programot választottatok?

A döntés a meglévő adatforrásokon múlt. A webshopmotor, a számlázó és a bank maradt, a belső rendszer ezekből olvas, és a hiányzó láncszemeket pótolja: termékszintű eredményt, készletet, gyártást. Hogy nálad melyik út jobb, az azon múlik, mennyire illeszkedik a dobozos program a meglévő folyamataidhoz; erre általános válasz nincs.

Mi kell ahhoz, hogy a termékszintű eredmény valós legyen?

Az, hogy az önköltség ne becslés legyen, hanem a beszerzésből, a gyártásból és a készletmozgásból jöjjön. Ehhez pedig a raktárban ténylegesen meglévő árunak egyeznie kell a rendszerrel. Ha a fizikai leltár nem rendszeres, a legszebb kimutatás is csak annyira pontos, amennyire a legutóbbi számolás.

Kezel-e személyes adatot egy ilyen belső rendszer?

Igen, a vevőkereső és a hívásnapló vevői adatot tartalmaz, a pénzügyi rész pedig költségeket. Ezért már a tervezésnél el kell dönteni, ki mit lát, és mi az a legkevesebb adat, ami a célhoz kell. A pontos szabályokhoz adatvédelmi szakember vagy jogász tanácsa szükséges.

Források

• 2000. évi C. törvény a számvitelről – Nemzeti Jogszabálytár, 2026-10-21-i állapot.
• NAV Online Számla rendszer – Nemzeti Adó- és Vámhivatal, 2026.