Beszerzési szoftver és ERP integrációja: milyen adat merre áramoljon?

A beszerzési igény jóváhagyása megtörtént, a rendelést mégis újra be kell gépelni az ERP-be. A számla már megérkezett, de a teljesítésigazolás egy levelezésben várakozik. Ezek nem feltétlenül egy rosszul kiválasztott szoftver tünetei: gyakran a rendszerek közötti adatáramlás és felelősségmegosztás nincs megfelelően kialakítva.

A beszerzési szoftver ERP integráció tervezésének központi kérdése ezért nem pusztán az, hogy rendelkezésre áll-e API. Azt kell eldönteni, melyik rendszer milyen adatért felel, mikor történik az átadás, és ki intézkedik, ha valami elakad. Az xFLOWer-alapú beszerzési folyamatok tervezésénél is ezt a működési logikát érdemes először rögzíteni, és csak utána kiválasztani a technikai megoldást.

1. Először az adatgazdákat jelöljük ki

Az integráció alapja az elsődleges nyilvántartó rendszer kijelölése. Ez azt jelenti, hogy minden fontos adattípushoz meghatározzuk, hol keletkezik, hol módosítható, és melyik rendszer változatát tekintjük irányadónak. Nem szükséges minden adatot egyetlen rendszerben kezelni, de ugyanannak az adatnak nem lehet két, egymástól független gazdája.

Gyakori felállás, hogy az ERP kezeli a pénzügyi és logisztikai törzsadatokat, míg a beszerzési folyamatkezelő az igényléseket, jóváhagyásokat és kapcsolódó feladatokat. Ez azonban nem kötelező sablon: a meglévő vállalati rendszerek és felelősségek alapján kell meghozni a döntést.

• Szállítók: az ERP vagy egy központi törzsadatkezelő adja át az azonosítót, nevet, státuszt és a szükséges üzleti adatokat.
• Cikkszámok, mértékegységek, adókódok: jellemzően az ERP-ből érkeznek a beszerzési rendszerbe.
• Költséghelyek és projektek: a kijelölt vállalati nyilvántartásból szinkronizálódnak.
• Beszerzési igények és jóváhagyások: a folyamatkezelőben keletkeznek, majd a szükséges eredményadatok kerülnek az ERP-be.
• Könyvelési és fizetési státuszok: az ERP-ből jutnak vissza a beszerzési folyamat résztvevőihez.

Az adatgazda személyét is rögzíteni kell. Egy inaktív költséghely vagy hibás szállítói adat javítása üzleti felelősség, nem automatikusan az informatikáé. Érdemes mezőszintű szabályokat készíteni: ki módosíthatja például a szállító bankszámlaszámát, és milyen ellenőrzés után válhat az új adat felhasználhatóvá?

2. Az API mellé integrációs szerződés is kell

Az API megléte önmagában nem garantál működő kapcsolatot. Tisztázni kell, mely objektumok olvashatók vagy írhatók, milyen jogosultságok szükségesek, és hogyan jelzi a fogadó rendszer az üzleti hibákat. Régebbi ERP esetén köztes integrációs réteg vagy ellenőrzött fájlátadás is szóba jöhet, ha a szükséges interfészek ezt támogatják.

Mit rögzítsünk az adatátadási specifikációban?

• A mezők jelentését, típusát, kötelezőségét és megfeleltetését.
• Az azonosítókat, kódtáblákat, dátumformátumokat és pénznemeket.
• Az átadást kiváltó eseményt és az elvárt feldolgozási határidőt.
• A sikeres átvétel, a visszautasítás és a részleges feldolgozás jelzését.
• A módosítások, törlések, verzióváltások és újraküldések szabályait.

Nem minden adat igényel azonnali szinkronizálást. A ritkán változó törzsadatokhoz elegendő lehet ütemezett frissítés, míg egy jóváhagyott rendelésnél indokolt lehet az eseményvezérelt átadás. A választást az üzleti elvárás, a rendszerterhelés és a rendelkezésre álló interfész együtt határozza meg.

A biztonsági tervben szerepeljen titkosított adatkapcsolat, elkülönített technikai azonosító, minimális jogosultság és szabályozott titokkezelés. Csak a folyamat működéséhez szükséges adatokat adjuk át; egy jóváhagyási feladat például nem feltétlenül igényli a szállító teljes pénzügyi adatlapját.

3. A rendelés útja: igényből ERP-bizonylat

Az igénylés és a rendelés nem ugyanaz az üzleti objektum. Az igény még módosulhat, elutasítható vagy több rendelésre bontható. Ezért általában nem célszerű minden piszkozatból ERP-rendelést létrehozni. Előre ki kell jelölni azt a folyamatállapotot, amely már indokolja a bizonylat létrehozását.

Egy lehetséges működési modellben az xFLOWer kezeli az igényhez kapcsolódó feladatokat és jóváhagyásokat, az ERP pedig a rendelési bizonylatot. Ebben a felállásban az adatáramlás a következő logikát követheti:

1. Az igénylő megadja a tételeket, mennyiségeket, határidőket és elszámolási adatokat.
2. A folyamat ellenőrzi a kötelező adatokat, és lefuttatja a szükséges jóváhagyásokat.
3. A jóváhagyott adatok alapján az integráció rendelést hoz létre az ERP-ben.
4. Az ERP visszaadja a rendelés számát, a tételazonosítókat és a feldolgozás eredményét.
5. A beszerzési folyamatban megjelenik a visszaigazolt rendelési hivatkozás.

A jóváhagyás nem azonos a sikeres ERP-rögzítéssel. A felületen külön állapotként érdemes megjeleníteni az átadásra váró, sikeresen rögzített és hibás tételeket. A szállítói kiküldés felelős rendszerét szintén rögzíteni kell, különben ugyanaz a rendelés kétszer is eljuthat a partnerhez.

A későbbi módosításokra külön szabály szükséges. Meghatározott értékhatár vagy feltétel változásakor új jóváhagyás lehet indokolt, teljesítés után pedig már korrekciós eljárásra lehet szükség. A rendelés fejadatai mellett a tételszintű kapcsolatot is meg kell őrizni, különösen részszállítások esetén.

4. Teljesítés és számla: zárjuk vissza a folyamatot

Az integráció nem ér véget a rendelés átadásával. A beszerzés résztvevőinek tudniuk kell, hogy az áru beérkezett-e, a szolgáltatást elfogadták-e, illetve a számla feldolgozható-e. Ehhez a logisztikai, üzleti és pénzügyi állapotokat össze kell kapcsolni, de nem szabad összemosni.

Árubeszerzésnél a bevételezés jellemzően a raktári rendszerben vagy az ERP-ben történik. Szolgáltatásnál a teljesítésigazolás külön üzleti munkafolyamat lehet. Mindkét esetben szükséges a rendeléshez és lehetőség szerint a rendelési tételhez kapcsolódó hivatkozás.

A számlaegyeztetés során összevethető a rendelés, az átvétel vagy teljesítésigazolás, valamint a számla tartalma. Az eltérések kezelése üzleti döntési pont: előre meg kell határozni a mennyiségi és értékbeli toleranciákat, valamint az eltérést jóváhagyó szerepkört.

A számlaadatok iránya a feldolgozási modell függvénye. Ha a számla először egy dokumentumkezelő vagy számlafeldolgozó rendszerbe érkezik, onnan indulhat az ellenőrzés, majd az ERP-be történő átadás. Ha az ERP fogadja a számlát, a folyamatkezelőnek az ellenőrzési feladathoz szükséges adatokra és dokumentumhivatkozásra lehet szüksége.

A könyvelt, jóváhagyott és kifizetett állapotokat külön kell kezelni. A fizetésről az arra kijelölt pénzügyi nyilvántartás adjon visszajelzést, ne a beszerzési rendszer következtesse ki más státuszokból.

5. Hibakezelés: ne a felhasználó legyen az integráció

A stabil működéshez a hibás eseteket ugyanolyan részletesen kell megtervezni, mint a sikeres adatátadást. Más eljárást igényel egy átmeneti hálózati hiba, egy lejárt hozzáférés és egy lezárt pénzügyi időszak.

• Technikai hiba: korlátozott, késleltetett újrapróbálkozás és szükség esetén üzemeltetői riasztás.
• Adathiba: értelmezhető hibaüzenet és javítási feladat a kijelölt adatgazdának.
• Üzleti elutasítás: visszalépés a megfelelő folyamatszakaszba vagy külön döntési feladat.
• Bizonytalan eredmény: ellenőrzés a fogadó rendszerben az újraküldés előtt.

Kulcsfontosságú az idempotens feldolgozás: ugyanannak az üzenetnek az ismételt elküldése ne hozzon létre újabb rendelést vagy számlát. Ehhez egyedi átadási azonosító és megfelelő fogadóoldali ellenőrzés szükséges. Egy időtúllépés ugyanis nem bizonyítja, hogy a fogadó rendszer nem végezte el a műveletet.

A naplózás kapcsolja össze a folyamatot, az üzenetet és az ERP-bizonylatot. Emellett időszakos egyeztetés is kell, amely kimutatja a hiányzó visszaigazolásokat és eltérő állapotokat. Az üzleti felhasználó azt lássa, mi akadt el és ki intézi; az üzemeltető pedig kapja meg a diagnózishoz szükséges technikai részleteket.

6. Bevezetés: teljes folyamatot teszteljünk

Az interfészteszt mellett végig kell próbálni a teljes beszerzési életciklust. Legyen teszteset részszállításra, több számlára, rendelésmódosításra, inaktív szállítóra, jogosultsági hibára és rendszerleállás utáni újraindulásra is.

Az élesítés előtt három kérdésre mindenképpen legyen válasz: mi történik a már nyitott rendelésekkel, hogyan állítható le biztonságosan az adatátadás, és ki felel az elakadt tételek napi ellenőrzéséért? A szűkített pilot, egyértelmű elfogadási feltételekkel, segít még a teljes kiterjesztés előtt feltárni a működési hiányosságokat.

Összegzés: egyértelmű felelősségek, követhető adatút

A jó beszerzési integráció nem mindent másol mindenhova. Kijelöli az adatgazdákat, szabályozza az átadás időpontját, visszajelzi az eredményt, és kezelhetővé teszi a kivételeket. Ettől válik a beszerzés és a pénzügy közös folyamattá, párhuzamos adminisztráció helyett.

ERP-hez kapcsolódó beszerzési folyamatot tervez? Egyeztessen a Click On szakértőivel az xFLOWer alkalmazási lehetőségeiről. A közös tervezés első lépése legyen az adatáramlási térkép, a felelősségi rend és a kritikus hibaforgatókönyvek áttekintése.

Ez a cikk a teljes útmutatónk része: Beszerzési szoftverek: teljes útmutató a választástól a hatékony működésig