Kako upravljati dobavljačkim proizvodnim feedovima?

U webshopu je proizvod dostupan ujutru, dobavljač ga povlači u podne, a popodne stiže narudžbina za njega. Korisnička podrška se izvinjava, nabavka traži alternativu, finansije storniraju, a skladište pokušava da identifikuje šifru artikla koja se u više sistema pojavljuje u različitim statusima. U takvim situacijama problem nije samo u podacima o proizvodu. Put informacija nije pod kontrolom.

Pitanje nije samo kako tehnički upravljati dobavljačkim feedovima proizvoda. Prvo treba razjasniti koje poslovne odluke se zasnivaju na tim podacima, ko je za njih odgovoran i šta se dešava kada je izvor podataka dobavljača nepotpun, kasni ili je netačan.

Feed proizvoda nije samo uvozna datoteka

Feed dobavljača može biti CSV, XML, Excel datoteka, API veza ili čak redovno primljeni e-mail prilog. Može sadržati naziv proizvoda, šifru artikla, cenu, zalihu, opis, sliku, kategoriju i informacije o isporuci. Tehnički format je samo površina.

Pravo pitanje je šta se menja u poslovanju kompanije nakon unosa tih podataka. Da li se cena automatski ažurira u webshopu? Može li se novi proizvod odmah pojaviti? Da li ponuda nestaje kada je zaliha postavljena na nulu? Da li je šifra artikla dobavljača sigurno povezana sa proizvodom koji se koristi u sopstvenom ERP-u, skladišnom sistemu ili fakturisanju?

Kod mnogih rastućih trgovaca upravljanje feedovima postaje teško jer je prvobitno razvijena rutina za jednog dobavljača i nekoliko stotina proizvoda. Kasnije podaci dolaze iz pet, deset ili dvadeset izvora, sa različitim strukturama i frekvencijama ažuriranja. Stara rutina tada često zahteva sve više ručnih provera, tabela i obrade izuzetaka.

Prvo treba mapirati put podataka

Pre nego što se razmotri nova integracija, PIM sistem ili automatizacija, vredi pratiti put konkretnih podataka o proizvodu. Na primer: dobavljač menja nabavnu cenu, podaci se unose u datoteku, neko je preuzima, kopira u tabelu, proverava procentualnu razliku, a zatim postavlja na administrativni interfejs webshopa. Nakon toga neko drugi menja ERP cenu, ili možda i ne menja.

U ovom procesu obično brzo postaje jasno gde nastaje rizik. Da li podaci žive na više mesta? Da li je pravilo o marži za određene brendove u glavi zaposlenog? Da li postoji dobavljač čije podatke o zalihama ne smatraju pouzdanim, a ipak ih automatski objavljuju? Ko primećuje ako feed ne stigne jednog dana?

Nisu svi ručni koraci loši. Odobravanje novog, strateški važnog proizvoda može biti svesna poslovna odluka. Ispitivanje neobično velikog pomeranja cena takođe može biti opravdano. Problem nastaje kada ljudska pažnja odlazi na ponavljajuće zadatke kao što su upoređivanje kolona, preimenovanje datoteka ili traženje grešaka, dok za izuzetke i odluke ostaje malo vremena.

Bez identifikatora nema pouzdane veze

Jedna od najčešćih skrivenih grešaka u feedovima proizvoda je identifikacija. Šifra artikla dobavljača, šifra proizvođača, EAN kod, interni identifikator webshopa i ERP šifra proizvoda nisu uvek isti. Proizvod može imati više varijanti, pakovanja ili boja, koje se u jednom feedu pojavljuju kao zasebni redovi, a u drugom sistemu kao glavni proizvod i varijante.

Ako nema jasnog pravila za usklađivanje, sistem može ažurirati cenu ili zalihu pogrešnom proizvodu. Još gore je ako tiho kreira novi proizvod jer ne može pronaći postojeći. Za nekoliko nedelja nastaju duplikati kartica proizvoda, različite vrednosti zaliha i nesigurni izveštaji.

Zato je vredno odrediti primarni identifikator za svaki izvor, kao i dodatna polja pomoću kojih se može proveriti usklađenost. EAN je često dobra polazna tačka, ali nije univerzalno rešenje: može nedostajati, biti netačan ili ne razlikovati dovoljno varijante.

Kako upravljati dobavljačkim feedovima proizvoda pravilima?

Dobra uprava feedovima ne počinje time što se sve odmah propušta od dobavljača do webshopa. Podaci dobavljača su spoljašnji podaci. Korisni su, ali nisu automatski verodostojni i ne moraju se nužno uklapati u sopstvenu poslovnu logiku.

Kompanija zato treba jasna pravila. Koja polja mogu dolaziti direktno od dobavljača? Koje podatke upravlja sopstveni tim, kao što su opis proizvoda, kategorija ili marketinški naziv? Koje promene cena se mogu automatski objaviti, a koje zahtevaju odobrenje? Šta se dešava kada je zaliha nepoznata, a ne nula?

Pravila ne moraju biti previše složena, ali moraju biti dokumentovana i dosledna. Dobro definisan proces može, na primer, odvojiti kreiranje novih proizvoda, ažuriranje postojećih proizvoda i obradu pogrešnih zapisa. Tako nedostajuća cena ili slika ne zaustavljaju celokupnu obradu, ali ne prolaze neprimećeno pred kupcima.

Zaliha i cena nisu isti podaci

Podaci o zalihama često imaju drugačiji ritam i poslovni značaj od opisa proizvoda. Nedeljno ažuriranje opisa obično ne predstavlja problem. Kašnjenje u zalihama brzo prodavanog proizvoda na dnevnom ili satnom nivou može direktno uticati na ispunjenje narudžbina.

Isto važi za cene. Dobavljač može promeniti nabavnu cenu, ali za sopstvenu prodajnu cenu treba uzeti u obzir maržu, akcije, troškove isporuke, ugovorne uslove i ponekad tržišnu poziciju. Ažuriranje dobavljačke cene stoga ne znači nužno trenutnu promenu cene u webshopu.

Vredi posebno tretirati i dostupnost. "Na zalihama" može značiti da je proizvod zaista odmah dostupan za isporuku, ali može značiti i da je teoretski dostupan u eksternom skladištu dobavljača. Ako se ovi statusi pojednostave na jedno da-ne polje, vreme isporuke obećano kupcu lako može postati netačno.

Bez validacije i obrade izuzetaka greška se skalira

Kada osoba unosi proizvode, mnoge greške se instinktivno primećuju. Primećuje nultu cenu, desetostruku zalihu ili nedostajuću kategoriju. Kod automatizovane obrade, ovu poslovnu kontrolu treba nadomestiti pravilima.

Validacija može ispitivati, na primer, da li je šifra artikla obavezna, da li postoji važeća cena, da li je zaliha nerealno mnogo promenjena ili da li novi proizvod ispunjava uslove za objavljivanje. Cilj nije sprečiti svaku razliku. Cilj je da sistem može razlikovati normalnu promenu od događaja koji zahteva ispitivanje.

Izuzetke je najbolje prikazati na radnoj listi iz koje je jasno šta se dogodilo, zašto je određeni zapis zaustavljen i ko treba da donese odluku o njemu. Ako obaveštenja o greškama stižu samo na opštu tehničku e-mail adresu ili ostaju u poštanskom sandučetu jednog kolege, proces i dalje zavisi od osobe.

Za rad je potrebna i mogućnost praćenja. Treba biti vidljivo kada je feed poslednji put stigao, koliko zapisa je obrađeno, koliko proizvoda je ažurirano, koliko ih je izuzeto i koje razlike se ponavljaju. Ovi brojevi nisu informatički dekor. Za komercijalnog i operativnog menadžera oni pokazuju da li je ponuda proizvoda na kojoj se zasniva prodaja pouzdana.

Ne tretirajte kao jedan veliki projekat

Ako se više dobavljača, webshopova, ERP i skladišnih procesa povezuje, može biti primamljivo sve redizajnirati odjednom. To je često preveliki rizik. Bolje je početi tamo gde nastaje najviše ručnog rada, grešaka u narudžbinama ili poslovne nesigurnosti.

Možda je prvo poboljšanje samo ujednačavanje usklađivanja šifri artikala i izrada dnevnog izveštaja o neuspelim uvozima. U drugim slučajevima, stabilna integracija između dobavljača, upravljanja podacima o proizvodima i webshopa može biti opravdana. Ako podaci o proizvodima idu u više kanala, sa mnogo izuzetaka i bogatim sadržajem, tada može biti opravdan poseban centralni sloj za upravljanje podacima o proizvodima.

Pravo rešenje zavisi od broja izvora podataka, brzine promene podataka, veličine asortimana proizvoda i poslovne štete koju greška može izazvati. Nije svakom preduzeću potreban isti sistem. Ali svakom preduzeću je potrebno da zna odakle dolazi koji podatak, po kojem pravilu se menja i ko je odgovoran za izuzetke.

Dobro upravljan dobavljački feed na kraju nije vredan zbog toga što treba otvoriti manje datoteka. Vredan je zato što prodaja, skladište i korisnička podrška mogu raditi iz iste pouzdanije slike, dok se pažnja ljudi može usmeriti na stvarne poslovne odluke umesto na kopiranje.