Jak dystrybutor elektroniki planuje pilotaż, by zakończyć ręczne wyszukiwanie produktów w ERP

Czy oprogramowanie może uzupełnić kartotekę produktu w ERP, na którą czeka oferta? W dużej mierze tak: może znaleźć dane producenta, odwzorować je na pola ERP i wskazać, co człowiek nadal musi sprawdzić. To właśnie z takim pytaniem zwrócił się do nas dystrybutor elektroniki przemysłowej. Jego zespół sprzedaży nie może wycenić pozycji RFQ, dopóki produkt nie istnieje w ERP, a dla każdego nowego elementu ktoś otwiera stronę producenta i kopiuje dane pole po polu. Automa.Net zaproponował automatyczne zbieranie tych danych, z pokazaniem źródła każdej wartości, odwzorowanie ich na własne pola ERP dystrybutora oraz dostarczenie ich gotowych do importu lub przez API, zaczynając od pól, które blokują ofertę. Projekt jest obecnie na etapie uzgadniania zakresu pilotażu, więc ten artykuł opisuje problem i plan, a nie wyniki. To drugi przypadek w naszej serii o projektach pilotażowych, po automatyzacji ofert na podstawie surowych list magazynowych: Automa.Net to nie tylko gotowe oprogramowanie, ale także rozwiązania budowane wokół procesu jednego klienta, a zaczynamy od pilotażu.

Przypadek w skrócie:

• Problem: każdy element RFQ, którego nie ma jeszcze w ERP, czeka na ręczne wyszukanie produktu na stronie producenta.
• Koszt: oferty są blokowane, dopóki nie istnieje kartoteka produktu, nakład pracy rośnie z każdą pozycją RFQ, brak zapisu o pochodzeniu wartości, a błędy w kodzie lub marce wychodzą na jaw zbyt późno.
• Proponowane rozwiązanie: automatyczne wzbogacanie danych produktowych z źródeł producenta w pierwszej kolejności, odwzorowane na pola ERP dystrybutora, z podanym źródłem i statusem weryfikacji dla każdej wartości.
• Pierwszy krok: pilotaż, obecnie w fazie określania zakresu: pola, reguły, producenci, przykładowe RFQ i sposób mierzenia sukcesu.
• Obecny etap: jeszcze bez wyników, zgodnie z założeniem.

Czym jest wzbogacanie danych produktowych w ERP?

Wzbogacanie danych produktowych w ERP oznacza automatyczne uzupełnianie kartoteki produktu na podstawie źródeł zewnętrznych zamiast ręcznego wpisywania: opisów, kategorii, wymiarów, wagi, kodów celnych i eksportowych, EAN, kraju pochodzenia oraz danych o cyklu życia. Dla dystrybutora części przemysłowych głównym źródłem jest producent, ponieważ tylko jego dane są wystarczająco wiarygodne dla celów celnych, wysyłki i pytań klientów. Dobre wzbogacanie robi trzy rzeczy poza kopiowaniem wartości: przelicza je na jednostki i definicje pól używane w ERP, zapisuje, skąd pochodzi każda wartość, oraz oznacza wartości sprzeczne lub brakujące, aby człowiek mógł podjąć decyzję.

Problem: brak kartoteki produktu, brak oferty

Dystrybutor posiada duży zapas elektroniki przemysłowej. Mimo to wiele RFQ dotyczy części, których wcześniej nie sprzedawał. W jego ERP cenę można podać dopiero wtedy, gdy istnieje kartoteka produktu. Dlatego każda nowa pozycja RFQ przechodzi przez ten sam ręczny proces:

1. RFQ wpływa z listą numerów części.
2. Produktu nie ma w ERP.
3. Ktoś wyszukuje na stronie producenta dokładną część i wariant.
4. Dane są kopiowane pole po polu do ERP.
5. Kartoteka produktu zostaje utworzona, i dopiero wtedy można wycenić pozycję.

Jest to wykonywane ręcznie, po jednym produkcie na raz. Zanim produkt może zostać utworzony i wyceniony, musi być uzupełniony zestaw pól obowiązkowych: identyfikacja i opisy, kategoria i producent, kod towaru celnego, wymiary, masa netto oraz klasyfikacja kontroli eksportowej. Dodatkowe pola, takie jak kody alternatywne, EAN, kraj pochodzenia i dane o cyklu życia, uzupełniają rekord i mogą zostać dodane później. Powiązany przewodnik na pokonywanie silosów danych w łańcuchach dostaw produkcji wyjaśnia, dlaczego dane kopiowane ręcznie między systemami mają tendencję do rozjeżdżania się.

Koszt problemu: czas i błędy

Nie zmierzyliśmy jeszcze czasu wyszukiwania u dystrybutora; uzgodnienie, jak go mierzyć, jest częścią zakresu pilotażu. Koszt nadal łatwo dostrzec w sposobie wykonywania pracy:

• Wycena jest zablokowana. Klient czekający na cenę najpierw czeka na rekord produktu. Im więcej nowych pozycji w jednym RFQ, tym dłużej czeka cała wycena.
• Nakład pracy rośnie z każdą pozycją. Każda nowa pozycja oznacza kolejne wyszukiwanie, kolejną wariantę do zidentyfikowania i kolejną rundę kopiowania. Długi RFQ to mnoży.
• Brak zapisu, skąd pochodziła wartość. Gdy masa lub kraj pochodzenia trafią do ERP, nikt nie może stwierdzić, czy pochodzą od producenta, z oferty sprzedawcy czy z przypuszczenia.
• Błędy są wykrywane późno. Pozycje RFQ zawierają kody pasujące do kilku produktów, błędy pisowni lub OCR w numerach części oraz części przypisane do niewłaściwej marki. Wykryte ręcznie pojawiają się dopiero po utworzeniu rekordu produktu albo po wysłaniu wyceny.
• Jednostki się nie zgadzają. Producenci często podają masę i wymiary opakowania, podczas gdy reguły dystrybutora wymagają wartości dotyczących samego produktu we własnych jednostkach. Każde wyszukiwanie oznacza też konwersję.

Jak planujemy to rozwiązać: dane producenta mapowane do ERP

Propozycja zastępuje wyszukiwanie po jednym produkcie jednym wsadem na listę RFQ: cała lista trafia do systemu, a każdy produkt wraca z wartościami zmapowanymi do pól ERP dystrybutora.

Najpierw dane producenta. Wartości są pobierane z trzech rodzajów źródeł, w ustalonej kolejności:

1. Strona internetowa producenta. Dane wyodrębniane bezpośrednio od producenta i mapowane do pól dystrybutora. Ekstrakcja działa już dla 21 producentów, w tym Siemens, Allen-Bradley, Schneider Electric, ABB, Omron, Lenze, Phoenix Contact i Pilz, a kolejne można dodać na podstawie wolumenu RFQ.
2. Baza danych Automa.Net, z danymi produktowymi o częściach od ponad 9 000 producentów, używana tylko dla pól lub produktów, których nie obejmuje źródło producenta.
3. Źródła zewnętrzne, używane tylko dla pozostałych luk i tylko tych, które dystrybutor akceptuje, w kolejności, w jakiej je akceptuje.

Każda wartość pokazuje swoje źródło i status. Dla każdego pola wynik pokazuje, skąd pochodzi wartość i czy można jej użyć: potwierdzona, wymaga weryfikacji, konflikt między źródłami lub brak. Gdy źródła się nie zgadzają, wartość producenta wygrywa, a konflikt pozostaje widoczny. Jednostki są zgodne z własnymi zasadami dystrybutora, z oznaczeniem, gdy producent publikuje wyłącznie wartości dla opakowań.

Wartości są zapisywane zgodnie z definicjami dystrybutora, a nie formatem producenta. Alternatywne kody zamówieniowe są przechowywane obok siebie, więc każdy z kodów pozwala znaleźć produkt, a dane o cyklu życia zawierają powiązane następniki i poprzedniki, jeśli producent je publikuje. Nasz przewodnik na temat śledzenia wycofanych części przemysłowych wyjaśnia, dlaczego te pola są ważne dla dystrybutora.

Każdy produkt jest klasyfikowany według tego, czego jeszcze potrzebuje przed przygotowaniem oferty:

• Gotowe do wyceny: wszystkie pola tworzenia produktu, wyceny i wysyłki są kompletne na podstawie zaakceptowanych źródeł.
• Wymaga weryfikacji: niejednoznaczne dopasowanie, poprawiony kod lub sprzeczne wartości. Przed utworzeniem rekordu potwierdza to człowiek.
• Brakujące dane: obowiązkowe pola nie zostały znalezione w żadnym uzgodnionym źródle. Trafiają one z powrotem do ręcznej obsługi.

Wynik jest przygotowany do importu do ERP lub dostarczany przez API, w zależności od tego, czy zespół chce wyszukiwać pojedyncze produkty, czy przesyłać całe listy RFQ. To te same dane produktowe, które stoją za usługą wzbogacania danych produktowych Automa.Net usługa wzbogacania danych produktowych, tutaj odwzorowana na definicje pól jednej firmy.

Pilotaż jako pierwszy krok

Wdrożenie zaczyna się od pól, które blokują wycenę:

• Faza 1, odblokowanie wyceny: witryna producenta jako jedyne źródło, pola tworzenia produktu, wyceny i wysyłki oraz mapowanie na pola i kategorie ERP dystrybutora.
• Faza 2, uzupełnienie rekordu: baza danych Automa.Net i uzgodnione źródła zewnętrzne, pozostałe pola wzbogacania oraz dodatkowe kontrole tam, gdzie kończą się dane producenta.

Zanim cokolwiek zostanie zbudowane, pilotaż wymaga pięciu decyzji i właśnie te kwestie uzgadniamy teraz z dystrybutorem:

1. Mapowanie pól: kategorie produktów, jednostki i definicje cyklu życia.
2. Zasady dotyczące niekompletnych danych producenta, na przykład gdy publikowana jest tylko waga lub wymiary opakowania.
3. Producenci, przykładowe RFQ i daty, z celowym połączeniem czystych kodów, alternatywnych kodów i problematycznych wpisów, aby pilotaż testował trudne przypadki, a nie tylko łatwe.
4. Źródła zewnętrzne dla pozostałych braków: które z nich dystrybutor akceptuje i w jakiej kolejności.
5. Jak mierzony jest pilotaż, na przykład oszczędność czasu wyszukiwania na każdej pozycji RFQ.

Obecny etap

Projekt znajduje się na etapie określania zakresu. Pokazaliśmy dystrybutorowi, jak dane byłyby pozyskiwane, z jakich źródeł i jak sortowane, i uzgadniamy mapowanie pól, zasady oraz próbkę pilotażową. Nie opublikujemy żadnych liczb, dopóki pilotaż nie zostanie przeprowadzony na rzeczywistych RFQ dystrybutora i nie zostanie zmierzony w sposób uzgodniony przez obie strony. Przedstawimy wyniki w kolejnym raporcie.

Porozmawiaj z nami o pilotażu na Twoich własnych danych

Taki pilotaż ma sens wtedy, gdy rekordy produktów są wąskim gardłem między RFQ a ofertą:

• Nowe pozycje pojawiają się wraz z każdym RFQ, a każda z nich wymaga rekordu produktu, zanim będzie można ją wycenić.
• Twój system ERP ma własne definicje pól, jednostki i kategorie, które dane producenta nie odwzorowują jeden do jednego.
• Musisz wiedzieć, skąd pochodzi każda wartość, na potrzeby celne, kontroli eksportu lub pytań klienta.
• Twój proces RFQ ma już ustaloną strukturę. Nasz przewodnik o jak usprawnić proces RFQ dla części opisuje etapy, na których dane zwykle się blokują.

Pierwszym krokiem jest rozmowa, a nie umowa. Prześlij nam próbkę rzeczywistych pozycji RFQ oraz listę pól z Twojego ERP, a pokażemy Ci, które pola można uzupełnić na podstawie źródeł producenta, które wymagają weryfikacji, a których brakuje, zanim cokolwiek zostanie zbudowane. Skontaktuj się z zespołem Automa.Net aby porozmawiać o pilotażu.

Najczęściej zadawane pytania

Czy oprogramowanie może automatyzować wyszukiwanie produktów dla elektronicznych RFQ?

W dużej mierze tak. Oprogramowanie może dopasować każdą pozycję RFQ do produktu producenta, wyodrębnić dane potrzebne ERP i przypisać je do właściwych pól. Pozycje z niejednoznacznymi kodami, błędami w pisowni lub sprzecznymi źródłami nadal wymagają potwierdzenia przez człowieka, więc dobre wdrożenie dzieli produkty na gotowe do wyceny, wymagające weryfikacji i z brakującymi danymi, zamiast zgadywać.

Jakie dane produktu są potrzebne w ERP przed przygotowaniem oferty?

Zazwyczaj kod, opisy, kategorię, producenta i kod towaru celnego, aby utworzyć pozycję, a także wymiary, masę netto i klasyfikację kontroli eksportowej, aby wycenić i wysłać towar. EAN, kraj pochodzenia, faza cyklu życia, następca i poprzednik uzupełniają rekord i mogą zostać dodane później.

Skąd pochodzą wzbogacone dane produktowe?

Najpierw ze strony internetowej producenta. Baza danych Automa.Net uzupełnia pola lub produkty, których producent nie obejmuje, a uzgodnione źródła zewnętrzne wypełniają tylko to, co pozostaje. Każda wartość ma przypisane źródło, a gdy źródła się różnią, decyduje wartość producenta, podczas gdy konflikt pozostaje widoczny.

Co się dzieje, gdy producent publikuje niekompletne dane?

Pilotaż z góry uzgadnia dla tego zasadę. Częstym przypadkiem jest producent, który publikuje tylko masę i wymiary opakowania, podczas gdy ERP potrzebuje wartości dotyczących samego produktu: taka wartość jest oznaczana, zamiast być wpisywana tak, jakby była poprawna. Pola obowiązkowe, dla których nie ma żadnego uzgodnionego źródła, wracają do ręcznej obsługi.

Czy wzbogacone dane mogą trafić do ERP bez podwójnego wprowadzania danych?

Tak. Dane są mapowane do własnych pól ERP i dostarczane jako plik importu lub przez API, więc nikt nie przepisuje ich ręcznie. To, czy zespół wysyła całe listy RFQ w jednym batchu, czy wyszukuje pojedyncze produkty przez API, jest jedną z decyzji podejmowanych podczas pilotażu.

Czym są ECCN i numer statystyczny w rekordzie produktu?

ECCN, czyli Export Control Classification Number, określa, czy produkt podlega kontroli eksportowej i jakiej; jest wymagany, zanim niektóre produkty będą mogły zostać wysłane za granicę. Numer statystyczny to kod towarowy celny, oparty na międzynarodowym kodzie HS i rozszerzony przez UE, Wielką Brytanię lub USA do ich własnych kodów krajowych. Oba są polami, od których może zależeć oferta lub wysyłka, a producenci nie zawsze je publikują, dlatego każda wartość zawiera swoje źródło.

Jak mierzyć pilotaż wzbogacania danych?

Obie strony uzgadniają miarę przed rozpoczęciem pilotażu, na przykład zaoszczędzony czas wyszukiwania na linię RFQ, odsetek produktów, które wracają gotowe do wyceny, oraz odsetek tych, które wymagają weryfikacji. Próba powinna obejmować poprawne kody, alternatywne kody i problematyczne wpisy, aby wynik odzwierciedlał rzeczywiste RFQ.