Ako spravovať produktové feedy dodávateľov?

V internetovom obchode je ráno dostupný produkt, na obed ho dodávateľ vyradí a popoludní naň príde objednávka. Zákaznícky servis sa ospravedlňuje, nákup hľadá alternatívu, financie stornujú a sklad sa snaží identifikovať kód produktu, ktorý má v rôznych systémoch rôzny status. V takýchto prípadoch nejde len o problém s údajmi o produkte. Tok informácií nie je pod kontrolou.

Otázka teda nie je len o tom, ako technicky spracovať dodávateľské produktové feedy. Najprv je potrebné objasniť, aké obchodné rozhodnutia sú založené na týchto údajoch, kto za ne zodpovedá a čo sa stane, keď je zdroj údajov od dodávateľa neúplný, oneskorený alebo chybný.

Produktový feed nie je len importný súbor

Dodávateľský feed môže byť CSV, XML, Excel súbor, API spojenie alebo aj pravidelne prichádzajúca e-mailová príloha. Môže obsahovať názov produktu, kód, cenu, skladové zásoby, popis, obrázok, kategóriu a informácie o doprave. Technický formát je však len povrch.

Skutočná otázka je, čo sa zmení v prevádzke spoločnosti po pridaní daných údajov. Aktualizuje sa cena automaticky v e-shope? Môže sa nový produkt okamžite zobraziť? Zmizne ponuka, ak je sklad na nule? Je dodávateľský kód produktu určite prepojený s produktom používaným vo vlastnom ERP, skladovom systéme alebo fakturačnom systéme?

Pre mnohých rastúcich obchodníkov sa správa feedov stáva náročnou, pretože pôvodne vytvorili fungujúcu rutinu pre jedného dodávateľa a niekoľko stoviek produktov. Neskôr prichádzajú údaje z piatich, desiatich alebo dvadsiatich zdrojov s rôznou štruktúrou a frekvenciou aktualizácie. Staré rutiny potom často vyžadujú čoraz viac manuálnych kontrol, tabuliek a výnimkového spracovania.

Najprv je potrebné zmapovať tok údajov

Predtým, než sa začne hovoriť o novej integrácii, PIM systéme alebo automatizácii, je vhodné sledovať cestu konkrétnych produktových údajov. Napríklad: dodávateľ zmení nákupnú cenu, údaje sa dostanú do súboru, niekto ich stiahne, skopíruje do tabuľky, skontroluje percentuálnu odchýlku a potom ich nahrá na administratívne rozhranie e-shopu. Potom niekto iný zmení cenu v ERP, alebo ju možno ani nezmení.

V tomto procese sa zvyčajne rýchlo ukáže, kde vzniká riziko. Žijú údaje na viacerých miestach? Má zamestnanec v hlave pravidlo, akú maržu použiť pre určité značky? Existuje dodávateľ, ktorého údaje o zásobách sa nepovažujú za spoľahlivé, ale napriek tomu sa automaticky publikujú? Kto si všimne, ak feed jeden deň nepríde?

Nie každý manuálny krok je zlý. Schválenie nového, strategicky dôležitého produktu môže byť vedomé obchodné rozhodnutie. Skúmanie neobvykle veľkého pohybu cien môže byť tiež opodstatnené. Problém nastáva, keď sa ľudská pozornosť zameriava na opakujúce sa úlohy, ako je porovnávanie stĺpcov, premenovávanie súborov alebo hľadanie chýb, zatiaľ čo na výnimky a rozhodnutia zostáva málo času.

Bez identifikátora nie je spoľahlivé prepojenie

Jednou z najčastejších skrytých chýb produktových feedov je identifikácia. Dodávateľský kód produktu, výrobca kód, EAN kód, interný identifikátor e-shopu a kód produktu v ERP sa nie vždy zhodujú. Produkt môže mať viacero variantov, balení alebo farieb, ktoré sa v jednom feede objavujú ako samostatné riadky, v inom systéme ako hlavný produkt a varianty.

Ak neexistuje jednoznačné pravidlo pre zhodu, systém môže aktualizovať cenu alebo zásoby nesprávneho produktu. Ešte horšie je, ak ticho vytvorí nový produkt, pretože nenájde existujúci. Po niekoľkých týždňoch vznikajú duplikované karty produktov, rozdielne hodnoty zásob a nejasné správy.

Preto je vhodné pre každý zdroj určiť primárny identifikátor a doplnkové polia, ktorými sa zhodu overuje. EAN je v mnohých prípadoch dobrým východiskom, ale nie je univerzálnym riešením: môže chýbať, byť chybný alebo nedostatočne rozlišovať varianty.

Ako spravovať dodávateľské produktové feedy s pravidlami?

Dobrý manažment feedov nezačína tým, že všetko okamžite prejde od dodávateľa do e-shopu. Dodávateľské údaje sú externé údaje. Sú užitočné, ale nie automaticky spoľahlivé a nemusia sa nevyhnutne zhodovať s vlastnou obchodnou logikou.

Spoločnosť preto potrebuje jasné pravidlá. Ktoré polia môžu prísť priamo od dodávateľa? Ktoré údaje spravuje vlastný tím, napríklad popis produktu, kategóriu alebo marketingový názov? Aká zmena ceny môže byť automaticky publikovaná a aká odchýlka vyžaduje schválenie? Čo sa stane, ak je zásoba neznáma, nie nulová?

Pravidlá nemusia byť príliš zložité, ale musia byť zdokumentované a konzistentné. Dobre definovaný proces môže napríklad oddeliť vytváranie nových produktov, aktualizáciu existujúcich produktov a spracovanie chybných záznamov. Takto chýbajúca cena alebo obrázok nezastaví celý proces, ale ani sa neobjaví pred zákazníkmi bez povšimnutia.

Zásoby a cena nie sú rovnaké údaje

Údaje o zásobách majú často iný rytmus a obchodný význam ako popis produktu. Týždenná aktualizácia popisu zvyčajne nespôsobuje problémy. Meškanie zásob rýchlo sa predávajúceho produktu o deň alebo hodinu môže priamo ovplyvniť plnenie objednávok.

To isté platí pre ceny. Dodávateľ môže zmeniť nákupnú cenu, ale pre vlastnú predajnú cenu je potrebné zohľadniť maržu, akcie, náklady na dopravu, zmluvné podmienky a prípadne aj trhovú pozíciu. Aktualizácia dodávateľskej ceny teda nemusí nevyhnutne znamenať okamžitú zmenu ceny v e-shope.

Je vhodné oddeliť aj dostupnosť. „Na sklade“ môže znamenať, že produkt je skutočne okamžite k dispozícii na odoslanie, ale môže to tiež znamenať, že je teoreticky dostupný v externom sklade dodávateľa. Ak sú tieto stavy zjednodušené na jedno binárne pole, môže sa ľahko stať, že dodacia lehota pre zákazníka bude nepresná.

Bez validácie a spracovania výnimiek sa chyba škáluje

Keď človek nahráva produkty, veľa chýb si všimne intuitívne. Všimne si nulovú cenu, desaťnásobné zásoby alebo chýbajúcu kategóriu. Pri automatizovanom spracovaní je potrebné tieto obchodné kontroly nahradiť pravidlami.

Validácia môže skúmať napríklad, či je kód produktu povinný, či je cena platná, či sa zásoby nezmenili nereálne veľa alebo či nový produkt spĺňa podmienky na publikovanie. Cieľom nie je zabrániť každej odchýlke. Cieľom je, aby systém dokázal rozlíšiť normálnu zmenu od udalosti, ktorá si vyžaduje preskúmanie.

Výnimky by sa mali zobrazovať v zozname úloh, z ktorého je jasné, čo sa stalo, prečo sa daný záznam zastavil a kto o ňom musí rozhodnúť. Ak sa chybové oznámenia posielajú len na všeobecnú technickú e-mailovú adresu alebo zostávajú v poštovej schránke jediného kolegu, proces je stále závislý na osobách.

Pre prevádzku je potrebná aj sledovateľnosť. Malo by byť viditeľné, kedy naposledy prišiel feed, koľko záznamov bolo spracovaných, koľko produktov bolo aktualizovaných, koľko bolo vo výnimkách a aké odchýlky sa opakujú. Tieto čísla nie sú IT dekoráciou. Pre obchodného a prevádzkového manažéra znamenajú, či je ponuka produktov, z ktorej predaj pracuje, spoľahlivá.

Nepovažujte to za jeden veľký projekt

Ak je prepojených viac dodávateľov, e-shopov, ERP a skladových procesov, môže byť lákavé všetko naraz prepracovať. To je často príliš veľké riziko. Je rozumnejšie začať tam, kde vzniká najviac manuálnej práce, chýb v objednávkach alebo obchodnej neistoty.

Možno prvá oprava spočíva len v tom, že sa zjednotia pravidlá pre zhodu kódov produktov a pripraví sa denná správa o neúspešných importoch. V inom prípade môže byť odôvodnená stabilná integrácia medzi dodávateľom, správou produktových údajov a e-shopom. Ak produktové údaje idú do viacerých kanálov, s mnohými výnimkami a bohatým obsahom, môže byť odôvodnená aj samostatná centrálna vrstva pre správu produktových údajov.

Správne riešenie závisí od počtu zdrojov údajov, rýchlosti zmeny údajov, rozsahu produktového sortimentu a obchodnej škody spôsobenej chybou. Nie každá spoločnosť potrebuje rovnaký systém. Ale každá spoločnosť potrebuje vedieť, odkiaľ údaje pochádzajú, podľa akého pravidla sa menia a kto je zodpovedný za výnimky.

Dobre spravovaný dodávateľský feed nie je cenný len preto, že je potrebné otvoriť menej súborov. Je cenný preto, že predaj, sklad a zákaznícky servis môžu pracovať z rovnakého spoľahlivejšieho obrazu, zatiaľ čo pozornosť ľudí sa môže sústrediť na skutočné obchodné rozhodnutia namiesto kopírovania.