Cum gestionăm feedurile de produse ale furnizorilor?

Într-un magazin online, un produs este disponibil dimineața, furnizorul îl scoate din producție la prânz, iar după-amiaza se primește o comandă pentru acesta. Serviciul clienți oferă explicații, achizițiile caută alternative, finanțele anulează, iar depozitul încearcă să identifice un cod de articol care apare cu statut diferit în mai multe sisteme. În astfel de cazuri, problema nu este doar legată de datele produsului. Fluxul de informații nu este gestionat corespunzător.

Întrebarea nu este doar cum să gestionăm tehnic feedurile de produse ale furnizorilor. Mai întâi trebuie clarificat ce decizii de afaceri se bazează pe aceste date, cine este responsabil pentru ele și ce se întâmplă când sursa de date a furnizorului este incompletă, întârziată sau eronată.

Feedul de produse nu este doar un fișier de import

Un feed de la furnizor poate fi un fișier CSV, XML, Excel, o conexiune API sau chiar un atașament de e-mail primit regulat. Poate conține numele produsului, codul articolului, prețul, stocul, descrierea, imaginea, categoria și informațiile de livrare. Formatul tehnic este însă doar suprafața.

Întrebarea reală este ce se schimbă în funcționarea companiei după ce datele respective sunt introduse. Se actualizează automat prețul în magazinul online? Poate apărea imediat noul produs? Dispare oferta dacă stocul este zero? Codul articolului furnizorului poate fi cu siguranță asociat cu produsul utilizat în ERP-ul propriu, sistemul de depozit sau facturare?

Pentru mulți comercianți în creștere, gestionarea feedurilor devine dificilă deoarece inițial au dezvoltat o rutină funcțională pentru un singur furnizor și câteva sute de produse. Ulterior, datele vin din cinci, zece sau douăzeci de surse, cu structuri și frecvențe de actualizare diferite. Rutina veche necesită adesea tot mai multe verificări manuale, foi de calcul și gestionarea excepțiilor.

Mai întâi trebuie cartografiat traseul datelor

Înainte de a discuta despre o nouă integrare, un sistem PIM sau automatizare, este util să urmăriți traseul unui set concret de date ale produsului. De exemplu: furnizorul schimbă prețul de achiziție, datele sunt introduse într-un fișier, cineva le descarcă, le copiază într-un tabel, verifică diferența procentuală, apoi le încarcă în interfața de administrare a magazinului online. După aceea, altcineva modifică prețul în ERP sau poate nu îl modifică deloc.

În acest proces, de obicei, devine rapid evident unde apare riscul. Datele există în mai multe locuri? Un angajat are în minte regula privind marja de profit pentru anumite mărci? Există un furnizor ale cărui date de stoc nu sunt considerate de încredere, dar sunt totuși publicate automat? Cine observă dacă un feed nu ajunge într-o zi?

Nu toate etapele manuale sunt rele. Aprobarea unui nou produs important din punct de vedere strategic poate fi o decizie comercială conștientă. Investigarea unei mișcări de preț neobișnuit de mari poate fi, de asemenea, justificată. Problema începe atunci când atenția umană este consumată de sarcini repetitive, cum ar fi compararea coloanelor, redenumirea fișierelor sau căutarea erorilor, lăsând puțin timp pentru excepții și decizii.

Fără identificator nu există o conexiune de încredere

Una dintre cele mai frecvente erori ascunse ale feedurilor de produse este identificarea. Codul articolului furnizorului, codul articolului producătorului, codul EAN, identificatorul intern al magazinului online și codul produsului ERP nu coincid întotdeauna. Un produs poate avea mai multe variante, ambalaje sau culori, care apar ca rânduri separate într-un feed, dar ca produs principal și variante într-un alt sistem.

Dacă nu există o regulă clară de corespondență, sistemul poate actualiza prețul sau stocul pentru produsul greșit. Și mai rău, poate crea în tăcere un produs nou, deoarece nu îl găsește pe cel existent. În câteva săptămâni, apar carduri de produs duplicate, valori de stoc diferite și rapoarte incerte.

De aceea, este util să se stabilească un identificator principal pentru fiecare sursă, precum și câmpurile suplimentare care pot verifica corespondența. EAN-ul este adesea un punct de plecare bun, dar nu este o soluție universală: poate lipsi, poate fi greșit sau nu poate distinge corespunzător variantele.

Cum să gestionăm feedurile de produse ale furnizorilor cu reguli?

O bună gestionare a feedurilor nu începe prin a permite totul de la furnizor până la magazinul online. Datele furnizorului sunt date externe. Sunt utile, dar nu sunt automat autentice și nu se potrivesc neapărat cu logica proprie de afaceri.

Compania are nevoie de reguli clare. Ce câmpuri pot veni direct de la furnizor? Ce date sunt gestionate de echipa proprie, cum ar fi descrierea produsului, categoria sau numele de marketing? Ce schimbare de preț poate fi publicată automat și ce diferență necesită aprobare? Ce se întâmplă dacă stocul este necunoscut, nu zero?

Regulile nu trebuie să fie prea complicate, dar trebuie să fie documentate și consecvente. Un proces bine definit poate separa, de exemplu, crearea de produse noi, actualizarea produselor existente și gestionarea înregistrărilor eronate. Astfel, un preț sau o imagine lipsă nu oprește întregul proces, dar nici nu ajunge neobservat în fața clienților.

Stocul și prețul nu sunt date identice

Datele de stoc au adesea un ritm și o semnificație de afaceri diferită față de descrierea produsului. O actualizare săptămânală a unei descrieri nu cauzează de obicei probleme. Întârzierea zilnică sau orară a stocului unui produs care se vinde rapid poate afecta direct îndeplinirea comenzilor.

Același lucru este valabil și pentru prețuri. Un furnizor poate schimba prețul de achiziție, dar pentru prețul de vânzare propriu trebuie luate în considerare marja de profit, promoțiile, costurile de livrare, condițiile contractuale și uneori poziția pe piață. Actualizarea prețului furnizorului nu înseamnă neapărat o schimbare imediată a prețului în magazinul online.

Este de asemenea util să se trateze separat disponibilitatea. „În stoc” poate însemna că produsul este cu adevărat disponibil imediat pentru livrare sau că este teoretic disponibil în depozitul extern al furnizorului. Dacă aceste stări sunt simplificate într-un singur câmp da-nu, timpul de livrare promis clientului poate deveni ușor inexact.

Fără validare și gestionarea excepțiilor, eroarea se extinde

Când o persoană încarcă produsele, observă instinctiv multe erori. Remarcă prețul de zero lei, stocul de zece ori mai mare sau categoria lipsă. În procesarea automatizată, acest control de afaceri trebuie înlocuit cu reguli.

Validarea poate verifica, de exemplu, dacă codul articolului este obligatoriu, dacă există un preț valid, dacă stocul a suferit o schimbare nerealist de mare sau dacă noul produs îndeplinește condițiile de publicare. Scopul nu este să împiedicăm fiecare abatere. Scopul este ca sistemul să poată distinge între o schimbare normală și un eveniment care necesită examinare.

Excepțiile ar trebui afișate într-o listă de sarcini din care să fie clar ce s-a întâmplat, de ce s-a oprit înregistrarea respectivă și cine trebuie să ia o decizie. Dacă notificările de eroare ajung doar la o adresă de e-mail tehnică generală sau rămân în căsuța poștală a unui singur coleg, procesul rămâne dependent de persoane.

Pentru funcționare este necesară și observabilitatea. Trebuie să fie vizibil când a sosit ultima dată feedul, câte înregistrări au fost procesate, câte produse au fost actualizate, câte au intrat în excepție și ce abateri se repetă. Aceste cifre nu sunt decoruri informatice. Pentru conducerea comercială și operațională, ele indică dacă oferta de produse pe care se bazează vânzările este de încredere.

Nu tratați ca un singur proiect mare

Dacă mai mulți furnizori, magazine online, procese ERP și de depozit sunt conectate între ele, poate fi tentant să reproiectați totul deodată. Acest lucru implică adesea un risc prea mare. Este mai indicat să începeți cu zona unde se generează cea mai mare muncă manuală, erori de comandă sau incertitudini de afaceri.

Poate că prima îmbunătățire este doar uniformizarea corespondenței codurilor de articole și realizarea unui raport zilnic despre importurile nereușite. În alt caz, o integrare stabilă este justificată între furnizor, gestionarea datelor produsului și magazinul online. Dacă datele produsului merg în mai multe canale, cu multe excepții și conținut bogat, atunci poate fi justificată o strat de gestionare centrală a datelor produsului.

Soluția corectă depinde de câte surse de date există, cât de rapid se schimbă datele, cât de mare este gama de produse și cât de mare este dauna de afaceri cauzată de o eroare. Nu toate companiile au nevoie de același sistem. Dar fiecare companie are nevoie să știe de unde provin datele, conform cărei reguli sunt modificate și cine este responsabil pentru excepții.

Un feed de furnizor bine gestionat nu este valoros doar pentru că trebuie deschise mai puține fișiere. Este valoros pentru că vânzările, depozitul și serviciul clienți pot lucra din aceeași imagine mai de încredere, în timp ce atenția oamenilor se poate concentra pe decizii reale de afaceri, nu pe copiere.