Pot conecta pasaportul digital al produsului la sistemul meu ERP sau de inventar?

Ce trebuie să faceți în mod concret

Ce se așteaptă de la dumneavoastră

Pașaportul trebuie să poată primi date din sisteme sursă

Articolul 10 din ESPR (Regulamentul (UE) 2024/1781) stabilește cerințe privind datele care trebuie să apară într-un pașaport digital al produsului și cum sunt accesibile. Aceste date nu apar din nimic: ele se află deja în sisteme existente, cum ar fi un pachet ERP, un sistem PLM sau un pachet de gestionare a inventarului — compoziția materială, date despre furnizori, numere de loturi, instrucțiuni de îngrijire. Pentru o companie cu 10 până la 100 de angajați, aceasta înseamnă din punct de vedere practic că trebuie să existe o conexiune între sistemul în care se află deja aceste date și sistemul care asamblează și publică pașaportul. Aceasta poate fi o cuplare automatizată, dar și o exportare periodică care este încărcată manual. Ambele sunt posibile în principiu; care formă este practică depinde de câte produse și variante sunt și cât de des se modifică datele.

Funcționarea tehnică trebuie să se alinieze la standardele stabilite

Articolul 11 din ESPR (Regulamentul (UE) 2024/1781) descrie designul tehnic și funcționarea pașaportului, inclusiv modul în care are loc schimbul de date. Aceasta se referă direct la întrebarea cum este configurată o cuplare din punct de vedere tehnic: nu orice format de export din orice sistem ERP se aliniază fără procesare la ceea ce se așteaptă dintr-un sistem de pașaport. Pentru o companie de dimensiuni medii, aceasta înseamnă că este necesară o traducere între propria structură de date și formatul utilizat pentru pașaport. Aceasta este o problemă tehnică, nu una juridică — dar are de-a face cu întrebarea ce este GS1 Digital Link și dacă este necesar pentru pasaportul produsuluicare este o parte a standardizării de așteptat care trece prin acest tip de sisteme.

Fiecare produs trebuie să fie urmăribile până la datele corecte din pașaport

O cuplare cu un sistem ERP sau de inventar funcționează doar dacă există o modalitate consecventă de a potrivi un produs fizic cu pașaportul corect. Aceasta necesită o cheie consistentă între sisteme: același număr de articol, același cod de lot sau aceeași identificare de variantă în sistemul ERP ca și în pașaport. Fără această aliniere, apare riscul ca un sistem cuplat să transmită date, dar la pașaportul greșit, sau ca o modificare dintr-un sistem să nu se reflecte în celălalt. Aceasta este strâns legată de modul în care fiecare produs primește un cod de identificare unic; fără o logică clară de identificare, o cuplare între sisteme are puțin folos.

Unde merge prost în practică

O primă situație care apare frecvent: o companie are un sistem ERP în care articolele sunt înregistrate pe stil, dar nu pe culoare sau mărime. Pașaportul trebuie totuși să fie corect la nivel de variantă, iar apoi se dovedește că cuplarea transmite date care sunt corecte pentru o mărime și incorecte pentru alta.

O a doua situație: datele sunt transferate o singură dată la lansarea unei colecții, dar o modificare ulterioară în sistemul ERP — de exemplu, un furnizor diferit pentru un lot parțial — nu este transferată automat la pașaportul publicat. Pașaportul se desprinde astfel de realitate fără ca cineva să observe, până când cineva descoperă o eroare și se întreabă dacă un pașaport al produsului publicat poate fi încă modificat.

O a treia situație: o cuplare este configurată din punct de vedere tehnic de o terță parte IT, dar nimeni din cadrul companiei nu verifică ulterior dacă datele care ajung în pașaport se potrivesc efectiv cu ceea ce apare pe etichetă sau ambalaj. O cuplare tehnică care funcționează nu este automat o cuplare care este corectă.

O a patra situație: sistemul de inventar este utilizat pentru a face automat ca pașaporturile să expire odată ce un produs este vândut, fără a ține seama de întrebarea cât timp trebuie să rămână disponibil un pașaport. Aceasta poate duce la o nepotrivire între ceea ce este operațional convenabil pentru administrarea inventarului și ceea ce se așteaptă în ceea ce privește cât timp trebuie să rămână disponibil un pasaport de produs.

O a cincea situație: în cazul unei fuziuni, achiziții sau încetării unei unități de afaceri, legătura este deconectată fără să se fi gândit la cine va gestiona datele apoi, ceea ce se aliniază din nou la întrebarea ce se întâmplă cu pașaportul produsului atunci când o companie se oprește.

Ce puteți documenta

• O privire de ansamblu asupra sistemelor care furnizează care date de pasaport: ERP pentru material și origine, sistem de inventar pentru disponibilitate, PLM pentru date de design și asamblare.
• Un acord stabilit privind frecvența sincronizării: legătură în timp real, export zilnic sau actualizare manuală per colecție.
• Un document în care se descrie cheia de identificare utilizată pentru a potrivi un produs din sistemul ERP cu pasaportul corect — inclusiv cum funcționează aceasta pentru variante în mărime sau culoare.
• O funcție de responsabilitate sau o persoană care verifică dacă datele care vin prin legătură sunt cu adevărat corecte înainte ca un pasaport să fie publicat sau actualizat.
• O procedură pentru ceea ce se întâmplă atunci când se produce o modificare în sistemul sursă: cine semnalizează aceasta și cum se efectuează modificarea în pasaportul publicat.
• Acorduri cu un furnizor IT sau departament IT intern privind formatul tehnic al legăturii, inclusiv ceea ce se întâmplă în caz de schimbare de sistem sau migrare.
• O privire de ansamblu asupra datelor care sunt furnizate în mod automat printr-o legătură și care sunt completate manual, pentru ca să nu existe gol între ceea ce sistemul crede că transmite și ceea ce se găsește cu adevărat în pasaport.