Czy mogę powiązać paszport produktu z moim systemem ERP lub zarządzania zapasami?

Powiązanie jest możliwe, pod warunkiem że dane będą strukturalnie dostarczone

Powiązanie cyfrowego paszportu produktu z systemem ERP lub zarządzania zapasami jest zasadniczo możliwe, ponieważ ESPR nakazuje, aby cyfrowy paszport produktu był technicznie skonstruowany w taki sposób, aby wymiana danych przebiegała w sposób interoperacyjny i czytelny dla maszyny (artykuł 11 ESPR, Rozporządzenie (UE) 2024/1781). Oznacza to, że dane, które znajdują się w systemie ERP lub zarządzania zapasami — skład materiałowy, pochodzenie, części składowe, numery partii lub seryjne — mogą w zasadzie być źródłem, z którego budowany jest paszport. Powiązanie nie polega wówczas na bezpośrednim, żywym połączeniu między dwoma systemami, ale na fakcie, że te same dane, które są już prowadzone wewnętrznie, dostarczane są w odpowiednim formacie dla paszportu.

Dla jakich danych to działa, a dla jakich nie

Dotyczy to danych, które już są gdzieś ustalone i które są istotne dla paszportu konkretnego produktu: specyfikacje techniczne, informacje o materiale, dane dotyczące naprawy i konserwacji, lub informacje o pochodzeniu. Dla tego typu danych strukturalne dostarczenie z istniejącego systemu jest logiczne. Nie chodzi o ogólne, trwałe powiązanie systemów nakazane przez ESPR — rozporządzenie nie zobowiązuje żadnego producenta ani importera do korzystania z konkretnej technologii, API lub pakietu oprogramowania. Artykuł 11 dotyczy technicznego ustawienia SAMEGO paszportu: jak nośnik danych, rejestr i dostęp do danych są zorganizowane. Nie określa, JAK przedsiębiorstwo organizuje lub eksportuje swój własny system ERP. Również ważne: które dokładnie dane muszą znaleźć się w paszporcie, różni się w zależności od grupy produktów i jest opracowywane osobno dla każdej grupy produktów w akcie delegowanym. To, co dla jednego produktu jest istotnym polem ERP (na przykład procent materiału), może nie mieć zastosowania dla innej grupy produktów.

Wymogi techniczne już obowiązują, szczegółowość dla grup produktów jeszcze nie wszędzie

ESPR sama w sobie, wraz z ogólnymi wymaganiami dotyczącymi cyfrowego paszportu produktu (artykuł 10) i jego technicznym ustawieniem (artykuł 11), jest ustalona i stanowi ramy, w ramach których każdy paszport produktu musi funkcjonować. To, kiedy konkretny produkt będzie rzeczywiście wymagał paszportu i jakie dokładnie dane muszą się w nim znaleźć, regulowane jest osobno dla każdej grupy produktów. Dla wielu grup produktów ta szczegółowość nie została jeszcze opublikowana lub nie jest jeszcze obowiązująca. Do momentu, w którym dla grupy produktów będzie ustalone, które dane są obowiązkowe, nie ma więc konkretnego obowiązku ustanowienia powiązania lub przepływu danych z systemu ERP — niemniej jednak warto już wiedzieć, skąd wewnętrznie pochodziłyby istotne dane, aby gdy zachodziła potrzeba zastosowania obowiązku, nie trzeba było zaczynać od zera.

Jak to jest realizowane w praktyce

Pierwszym krokiem jest sprawdzenie, które dane w systemie ERP lub inwentarzowym są już dostępne i dotyczą tego, co typowo zawiera pasport: identyfikacja produktu, skład materiałowy, pochodzenie, komponenty, informacje o gwarancji lub naprawie. Następnie warto sprawdzić, jak wyeksportować te dane z systemu — jako plik, raport lub poprzez strukturalne połączenie — w formie, która jest czytelna i transferowalna, zgodnie z otwartą i interoperacyjną strukturą, którą artykuł 11 pasportu przewiduje. Kolejnym krokiem jest powiązanie danych z unikalną identyfikacją produktu wymaganą przez pasport zgodnie z artykułem 10, tak aby każdy pasport był wyraźnie przypisany do właściwego produktu. Ponieważ pasport musi pozostać aktualny przez całą cykl życia produktu, praktyczne jest również rozważenie powtarzającego się procesu: jak zmiana w systemie ERP (na przykład zmieniony komponent lub nowy dostawca) zostanie w pewnym momencie odzwierciedlona w pasporcie. Nie musi to być koniecznie w czasie rzeczywistym — okresowa dostawa, na przykład w przypadku zmian lub nowych produkcji, w większości przypadków działa doskonale. Platforma, która tworzy pasporty z dostarczonych danych, taka jak prodpas.eu, otrzymuje te dane zwykle w ten właśnie sposób: jako strukturalna dostawa z istniejącej administracji producenta lub importera, nie jako stałe połączenie na żywo między dwoma systemami.

Skąd to wynika: artykuł 10 i 11 ESPR

Obowiązek interoperacyjności i możliwości odczytu maszynowego cyfrowego produktu pasportu wynika z artykułu 11 ESPR (Rozporządzenie (UE) 2024/1781), które reguluje aspekty techniczne i funkcjonowanie pasportu. Artykuł 10 tego samego rozporządzenia opisuje ogólne wymogi, którym musi odpowiadać pasport, w tym powiązanie z unikalną identyfikacją produktu. Razem artykuły te stanowią podstawę do tego, dlaczego dane źródłowe z istniejącego systemu, pod warunkiem że są dostarczone w strukturalny sposób, mogą być odpowiednim wejściem dla pasportu — bez konieczności, aby rozporządzenie określało, którą technikę lub który system przedsiębiorstwo musi wewnętrznie wykorzystać.

Kto chce przygotować się już teraz, powinien zacząć od przeglądu danych produktu dostępnych w jego systemie ERP lub inwentarzowym i w jakim formacie mogą być eksportowane. Gdy dla danej grupy produktów będzie jasne, jakie dane musi zawierać pasport, dostawa z istniejącej administracji zwykle będzie praktycznym punktem wyjścia.