Jak spravovat dodavatelské produktové feedy?

V internetovém obchodě je ráno dostupný produkt, v poledne ho dodavatel stáhne a odpoledne na něj přijde objednávka. Zákaznický servis se omlouvá, nákup hledá alternativu, finance stornují a sklad se snaží identifikovat číslo položky, které má v různých systémech odlišný status. V takovém případě nejde jen o problém s produktovými daty. Tok informací není pod kontrolou.

Otázka tedy není jen o tom, jak technicky zpracovat dodavatelské produktové feedy. Nejprve je třeba vyjasnit, jaká obchodní rozhodnutí jsou na těchto datech založena, kdo za ně odpovídá a co se stane, když je dodavatelský zdroj dat neúplný, opožděný nebo chybný.

Produktový feed není jen importní soubor

Dodavatelský feed může být CSV, XML, Excelový soubor, API připojení nebo dokonce pravidelně přicházející e-mailová příloha. Může obsahovat název produktu, číslo položky, cenu, sklad, popis, obrázek, kategorii a informace o dopravě. Technický formát je však jen povrch.

Skutečná otázka je, co se změní v provozu společnosti po přijetí těchto dat. Aktualizuje se automaticky cena v e-shopu? Může se nový produkt okamžitě zobrazit? Zmizí nabídka, pokud je sklad nastaven na nulu? Je dodavatelské číslo položky jistě propojeno s produktem používaným ve vlastním ERP, skladovém systému nebo fakturačním systému?

U mnoha rostoucích obchodníků se správa feedů stává obtížnou, protože původně vytvořili funkční rutinu pro jednoho dodavatele a několik stovek produktů. Později přicházejí data z pěti, deseti nebo dvaceti zdrojů, s různou strukturou a frekvencí aktualizací. Stará rutina pak často vyžaduje stále více ručních kontrol, tabulek a výjimek.

Nejprve je třeba zmapovat tok dat

Než se začne uvažovat o nové integraci, PIM systému nebo automatizaci, je dobré sledovat cestu konkrétních produktových dat. Například: dodavatel změní nákupní cenu, data se dostanou do souboru, někdo je stáhne, zkopíruje do tabulky, zkontroluje procentuální odchylku a poté nahraje do administrace e-shopu. Poté někdo jiný změní cenu v ERP, nebo možná ani nezmění.

V tomto procesu se obvykle rychle ukáže, kde vzniká riziko. Žijí data na více místech? Má zaměstnanec v hlavě pravidlo, jakou marži použít u určitých značek? Existuje dodavatel, jehož skladová data nejsou považována za spolehlivá, ale přesto se automaticky publikují? Kdo si všimne, když feed jeden den nepřijde?

Ne každý ruční krok je špatný. Schválení nového, strategicky důležitého produktu může být vědomé obchodní rozhodnutí. Zkoumání neobvykle velkého pohybu cen může být také oprávněné. Problém nastává, když lidská pozornost směřuje na opakující se úkoly, jako je porovnávání sloupců, přejmenovávání souborů nebo hledání chyb, zatímco na výjimky a rozhodnutí zbývá málo času.

Bez identifikátoru není spolehlivé propojení

Jednou z nejčastějších skrytých chyb produktových feedů je identifikace. Dodavatelské číslo položky, výrobní číslo položky, EAN kód, interní identifikátor e-shopu a kód produktu v ERP se ne vždy shodují. Produkt může mít více variant, balení nebo barev, které se v jednom feedu objeví jako samostatné řádky, v jiném systému jako vztah hlavního produktu a variant.

Pokud neexistuje jednoznačné pravidlo pro přiřazení, systém může aktualizovat cenu nebo sklad u nesprávného produktu. Ještě horší je, když tiše vytvoří nový produkt, protože nenajde stávající. Během několika týdnů vzniknou duplikované produktové karty, rozdílné skladové hodnoty a nejisté reporty.

Proto je vhodné u každého zdroje určit primární identifikátor a doplňkové pole, kterými lze ověřit shodu. EAN je často dobrým výchozím bodem, ale není univerzálním řešením: může chybět, být chybný nebo nedostatečně rozlišovat varianty.

Jak spravovat dodavatelské produktové feedy pomocí pravidel?

Dobrá správa feedů nezačíná tím, že vše okamžitě propustíme od dodavatele do e-shopu. Dodavatelská data jsou externí data. Jsou užitečná, ale nejsou automaticky důvěryhodná a nemusí nutně zapadat do vlastní obchodní logiky.

Společnost proto potřebuje jasná pravidla. Která pole mohou přijít přímo od dodavatele? Která data spravuje vlastní tým, například popis produktu, kategorii nebo marketingový název? Jaká změna ceny může být automaticky publikována a jaká odchylka vyžaduje schválení? Co se stane, když je sklad neznámý, nikoli nulový?

Pravidla nemusí být příliš složitá, ale musí být zdokumentovaná a konzistentní. Dobře definovaný proces může například oddělit vytváření nových produktů, aktualizaci stávajících produktů a zpracování chybných záznamů. Tím pádem chybějící cena nebo obrázek nezastaví celý proces, ale ani se neobjeví nepozorovaně před zákazníky.

Sklad a cena nejsou stejná data

Skladová data mají často jiný rytmus a obchodní význam než popis produktu. Týdenní aktualizace popisu obvykle nepředstavuje problém. Zpoždění skladových dat u rychle se prodávajícího produktu denně nebo hodinově může však přímo ovlivnit plnění objednávek.

Totéž platí pro ceny. Dodavatel může změnit nákupní cenu, ale pro vlastní prodejní cenu je třeba zohlednit marži, akce, náklady na dopravu, smluvní podmínky a někdy i tržní pozici. Aktualizace dodavatelské ceny tedy nemusí nutně znamenat okamžitou změnu ceny v e-shopu.

Je také vhodné oddělit dostupnost. "Na skladě" může znamenat, že produkt je skutečně okamžitě k dispozici k odeslání, ale může také znamenat, že je teoreticky dostupný ve vnějším skladu dodavatele. Pokud se tyto stavy zjednoduší na jedno pole ano-ne, může se snadno stát, že dodací lhůta pro zákazníka bude nepřesná.

Bez validace a správy výjimek se chyba škáluje

Když člověk nahrává produkty, mnoho chyb si instinktivně všimne. Zaznamená nulovou cenu, desetinásobný sklad nebo chybějící kategorii. U automatizovaného zpracování je třeba tento obchodní kontrol nahradit pravidly.

Validace může například zkoumat, zda je číslo položky povinné, zda je cena platná, zda se sklad změnil nereálně velkým způsobem nebo zda nový produkt splňuje podmínky pro publikaci. Cílem není zabránit každé odchylce. Cílem je, aby systém dokázal rozlišit mezi normální změnou a událostí, kterou je třeba prozkoumat.

Výjimky je vhodné zobrazit v pracovním seznamu, ze kterého je jasné, co se stalo, proč se daný záznam zastavil a kdo o něm musí rozhodnout. Pokud chybová oznámení přicházejí pouze na obecnou technickou e-mailovou adresu nebo zůstávají v poštovní schránce jediného kolegy, proces je stále závislý na osobě.

Pro provoz je také potřeba sledovatelnost. Mělo by být vidět, kdy naposledy přišel feed, kolik záznamů bylo zpracováno, kolik produktů bylo aktualizováno, kolik se dostalo do výjimek a jaké odchylky se opakují. Tyto čísla nejsou IT dekorace. Pro obchodní a provozní vedení signalizují, zda je nabídka produktů, ze které prodej pracuje, spolehlivá.

Neřešte to jako jeden velký projekt

Pokud se propojuje více dodavatelů, e-shopů, ERP a skladových procesů, může být lákavé vše najednou přepracovat. To je často příliš velké riziko. Je lepší začít tam, kde vzniká nejvíce ruční práce, chyb v objednávkách nebo obchodní nejistoty.

První oprava může být například sjednocení přiřazení čísel položek a denní report o neúspěšných importech. V jiném případě je vhodná stabilní integrace mezi dodavatelem, správou produktových dat a e-shopem. Pokud produktová data směřují do více kanálů, s mnoha výjimkami a bohatým obsahem, může být vhodná i samostatná centrální vrstva pro správu produktových dat.

Správné řešení závisí na počtu zdrojů dat, rychlosti změn dat, rozsahu produktové nabídky a obchodních škodách způsobených chybou. Ne každá společnost potřebuje stejný systém. Ale každá společnost potřebuje vědět, odkud data pocházejí, podle jakého pravidla se mění a kdo je odpovědný za výjimky.

Dobře spravovaný dodavatelský feed nakonec není cenný tím, že je třeba otevřít méně souborů. Je cenný tím, že prodej, sklad a zákaznický servis mohou pracovat ze stejného spolehlivějšího obrazu, zatímco pozornost lidí se může místo kopírování soustředit na skutečná obchodní rozhodnutí.