Hogyan kezeljük a beszállítói termékfeedeket?

Egy webshopban reggel még elérhető egy termék, délben a beszállító kifuttatja, délután pedig érkezik rá egy megrendelés. Az ügyfélszolgálat magyarázkodik, a beszerzés alternatívát keres, a pénzügy sztornóz, a raktár pedig olyan cikkszámot próbál azonosítani, amely már több rendszerben is más státuszban szerepel. Ilyenkor nem egyszerűen termékadat-probléma van. Az információ útja nincs kézben tartva.

A kérdés tehát nem csak az, hogyan kezeljük a beszállítói termékfeedeket technikailag. Előbb azt kell tisztázni, milyen üzleti döntések épülnek ezekre az adatokra, ki felel értük, és mi történik, amikor a beszállító adatforrása hiányos, késik vagy hibás.

A termékfeed nem pusztán importfájl

Egy beszállítói feed lehet CSV, XML, Excel-fájl, API-kapcsolat vagy akár rendszeresen érkező e-mailes melléklet. Tartalmazhat terméknevet, cikkszámot, árat, készletet, leírást, képet, kategóriát és szállítási információt. A technikai formátum azonban csak a felszín.

A valós kérdés az, hogy az adott adat bekerülése után mi változik a vállalat működésében. Frissül-e automatikusan az ár a webshopban? Megjelenhet-e az új termék azonnal? Nullára állított készlet esetén eltűnik-e az ajánlat? A beszállítói cikkszám biztosan összekapcsolható-e a saját ERP-ben, raktári rendszerben vagy számlázóban használt termékkel?

Sok növekvő kereskedőnél a feedek kezelése azért válik nehézzé, mert eredetileg egyetlen beszállítóra és néhány száz termékre alakítottak ki egy működő rutint. Később öt, tíz vagy húsz forrásból érkeznek adatok, eltérő struktúrával és frissítési gyakorisággal. A régi rutin ekkor gyakran egyre több kézi ellenőrzést, táblázatot és kivételkezelést igényel.

Először az adat útját kell feltérképezni

Mielőtt új integráció, PIM-rendszer vagy automatizáció kerül szóba, érdemes végigkövetni egy konkrét termékadat útját. Például: a beszállító megváltoztatja a beszerzési árat, az adat bekerül egy fájlba, valaki letölti, átmásolja egy táblázatba, ellenőrzi a százalékos eltérést, majd feltölti a webshop adminfelületére. Ezután valaki más módosítja az ERP árat, vagy talán nem is módosítja.

Ebben a folyamatban általában gyorsan láthatóvá válik, hol keletkezik kockázat. Az adatok több helyen élnek? Egy munkatárs fejében van a szabály, hogy bizonyos márkáknál milyen árrést kell használni? Van olyan beszállító, amelyiknek a készletadatait nem tekintik megbízhatónak, mégis automatikusan publikálják? Ki veszi észre, ha a feed egy nap nem érkezik meg?

Nem minden kézi lépés rossz. Egy új, stratégiailag fontos termék jóváhagyása lehet tudatos kereskedelmi döntés. Egy szokatlanul nagy ármozgás vizsgálata is indokolt lehet. A gond ott kezdődik, amikor az emberi figyelem olyan ismétlődő feladatokra megy el, mint az oszlopok összevetése, fájlok átnevezése vagy hibák keresése, miközben a kivételekre és döntésekre alig marad idő.

Azonosító nélkül nincs megbízható kapcsolat

A termékfeedek egyik leggyakoribb rejtett hibája az azonosítás. A beszállító cikkszáma, a gyártói cikkszám, az EAN-kód, a webshop belső azonosítója és az ERP termékkódja nem mindig egyezik. Egy terméknek lehet több változata, kiszerelése vagy színe, amelyek egy feedben külön sorok, egy másik rendszerben pedig főtermék és variáns kapcsolatban jelennek meg.

Ha nincs egyértelmű megfeleltetési szabály, a rendszer rossz termékhez frissíthet árat vagy készletet. Ennél is rosszabb, ha csendben új terméket hoz létre, mert nem találja a meglévőt. Néhány hét alatt duplikált termékkártyák, eltérő készletértékek és bizonytalan riportok keletkeznek.

Ezért érdemes minden forrásnál meghatározni az elsődleges azonosítót, valamint azokat a kiegészítő mezőket, amelyekkel az egyezés ellenőrizhető. Az EAN sok esetben jó kiindulópont, de nem univerzális megoldás: hiányozhat, hibás lehet, vagy nem különbözteti meg megfelelően a változatokat.

Hogyan kezeljük a beszállítói termékfeedeket szabályokkal?

A jó feedkezelés nem azzal kezdődik, hogy mindent azonnal átengedünk a beszállítótól a webshopig. A beszállítói adat külső adat. Hasznos, de nem automatikusan hiteles és nem feltétlenül illeszkedik a saját üzleti logikához.

A vállalatnak ezért világos szabályokra van szüksége. Mely mezők érkezhetnek közvetlenül a beszállítótól? Mely adatokat kezeli a saját csapat, például a termékleírást, kategóriát vagy marketingnevet? Milyen árváltozás publikálható automatikusan, és milyen eltérés igényel jóváhagyást? Mi történjen, ha a készlet ismeretlen, nem pedig nulla?

A szabályoknak nem kell túl bonyolultnak lenniük, de dokumentáltnak és következetesnek kell maradniuk. Egy jól meghatározott folyamat például elkülönítheti az új termékek létrehozását, a meglévő termékek frissítését és a hibás rekordok kezelését. Így egy hiányzó ár vagy kép nem állítja le a teljes feldolgozást, de nem is kerül észrevétlenül az ügyfelek elé.

A készlet és az ár nem egyforma adat

A készletadatnak gyakran más a ritmusa és üzleti jelentősége, mint a termékleírásnak. Egy leírás heti frissítése általában nem okoz gondot. Egy gyorsan fogyó termék készletének napi vagy óránkénti késése viszont közvetlenül érintheti a rendelésteljesítést.

Ugyanez igaz az árakra. Egy beszállító változtathat beszerzési árat, de a saját eladási árhoz figyelembe kell venni az árrést, akciókat, szállítási költséget, szerződéses feltételeket és esetenként a piaci pozíciót is. A beszállítói ár frissítése tehát nem szükségszerűen jelent azonnali webshopos árváltozást.

Érdemes külön kezelni a rendelkezésre állást is. A „van készleten” jelentheti azt, hogy a termék valóban azonnal szállítható, de jelentheti azt is, hogy a beszállító külső raktárában elméletileg elérhető. Ha ezeket az állapotokat egyetlen igen-nem mezőre egyszerűsítik, a vevő számára vállalt szállítási idő könnyen pontatlanná válik.

Validáció és kivételkezelés nélkül a hiba skálázódik

Amikor egy ember tölti fel a termékeket, sok hibát ösztönösen észrevesz. Feltűnik neki a nulla forintos ár, a tízszeres készlet vagy a hiányzó kategória. Automatizált feldolgozásnál ezt az üzleti kontrollt szabályokkal kell pótolni.

A validáció vizsgálhatja például, hogy kötelező-e a cikkszám, van-e érvényes ár, irreálisan nagyot változott-e a készlet, vagy az új termék megfelel-e a publikálási feltételeknek. Nem az a cél, hogy minden eltérést megakadályozzunk. Az a cél, hogy a rendszer meg tudja különböztetni a normális változást a vizsgálatra szoruló eseménytől.

A kivételeket olyan munkalistában érdemes megjeleníteni, amelyből egyértelmű, mi történt, miért állt meg az adott rekord, és kinek kell döntenie róla. Ha a hibaértesítések csak egy általános technikai e-mail címre érkeznek, vagy egyetlen kolléga postaládájában maradnak, a folyamat továbbra is személyfüggő.

A működéshez szükség van megfigyelhetőségre is. Látható legyen, mikor érkezett utoljára feed, hány rekordot dolgoztak fel, hány termék frissült, hány került kivételbe, és milyen eltérések ismétlődnek. Ezek a számok nem informatikai díszletek. A kereskedelmi és operációs vezető számára azt jelzik, megbízható-e az a termékkínálat, amelyből az értékesítés dolgozik.

Ne egyetlen nagy projektként kezeljék

Ha több beszállító, webshop, ERP és raktári folyamat kapcsolódik egymáshoz, csábító lehet mindent egyszerre újratervezni. Ez gyakran túl nagy kockázat. Célszerűbb azzal kezdeni, ahol a legtöbb kézi munka, rendelési hiba vagy üzleti bizonytalanság keletkezik.

Lehet, hogy az első javítás mindössze annyi, hogy egységesítik a cikkszám-megfeleltetéseket és napi riportot készítenek a sikertelen importokról. Más esetben egy stabil integráció indokolt a beszállító, a termékadat-kezelés és a webshop között. Ha a termékadatok több csatornába mennek, sok kivétellel és gazdag tartalommal, akkor egy külön központi termékadat-kezelési réteg is indokolt lehet.

A helyes megoldás attól függ, hány adatforrás van, milyen gyorsan változnak az adatok, mekkora a termékválaszték, és mekkora üzleti kárt okoz egy hiba. Nem minden vállalatnak ugyanarra a rendszerre van szüksége. De minden vállalatnak szüksége van arra, hogy tudja, melyik adat honnan jön, milyen szabály szerint módosul, és ki felel a kivételekért.

A jól kezelt beszállítói feed végül nem attól értékes, hogy kevesebb fájlt kell megnyitni. Attól, hogy az értékesítés, a raktár és az ügyfélszolgálat ugyanabból a megbízhatóbb képből dolgozhat, miközben az emberek figyelme a másolás helyett a valódi üzleti döntésekre fordulhat.