DPPC jako element strategii danych produktowych, compliance i SEO

DPPC ma sens jako element strategii danych produktowych wtedy, gdy nie traktujesz go jako kolejnego miejsca do ręcznego wpisywania parametrów, tylko jako warstwę publikacji: pobiera dane z ERP, PIM i od dostawców, łączy je z dokumentami i identyfikatorem produktu, a potem udostępnia w jednej, wersjonowanej postaci – dla klienta skanującego kod QR, dla partnera handlowego, dla sklepu internetowego i dla wyszukiwarek. Jeśli te same dane obsługują compliance, sprzedaż i widoczność w wyszukiwarce, cyfrowy paszport produktu przestaje być kosztem regulacyjnym, a staje się porządkiem, który firma i tak powinna mieć.

Skąd w ogóle potrzeba strategii

W większości firm produkcyjnych i handlowych dane o produkcie powstają w kilku miejscach jednocześnie. Dział techniczny prowadzi karty katalogowe w plikach, jakość przechowuje deklaracje zgodności i certyfikaty na dysku sieciowym, marketing uzupełnia opisy w sklepie, a ERP zna tylko indeks, jednostkę i cenę. Każdy kanał dostaje nieco inną wersję prawdy.

Do tego dochodzi presja regulacyjna. Rozporządzenie w sprawie ekoprojektu dla zrównoważonych produktów (ESPR, rozporządzenie (UE) 2024/1781) obowiązuje od lipca 2024 roku i wprowadza cyfrowy paszport produktu jako standardowy sposób przekazywania informacji o produkcie w całym cyklu życia. Konkretne obowiązki pojawiają się stopniowo, w aktach delegowanych dla poszczególnych grup produktów. Osobny harmonogram mają baterie: zgodnie z rozporządzeniem (UE) 2023/1542 paszport baterii będzie wymagany od 18 lutego 2027 roku m.in. dla baterii do pojazdów elektrycznych i baterii przemysłowych powyżej 2 kWh.

Strategia polega na tym, żeby na te wymagania odpowiedzieć raz, porządnie, a nie osobnym projektem dla każdego kanału.

Kto za co odpowiada: ERP, PIM, DPPC i sklep

Najwięcej nieporozumień bierze się z oczekiwania, że jeden system zrobi wszystko. W praktyce każdy ma swoją rolę:

• ERP – indeksy, identyfikatory, partie, numery seryjne, stany i ceny. Źródło prawdy dla tego, co zostało wyprodukowane i sprzedane.
• PIM – opisy, zdjęcia, atrybuty techniczne i tłumaczenia przygotowane pod kanały sprzedaży.
• DPPC – publikacja danych produktu powiązanych z identyfikatorem i kodem QR, dokumenty z datami ważności, poziomy dostępu, historia wersji i API dla innych systemów.
• E-commerce lub portal B2B – prezentacja oferty, koszyk, konta klientów. Pobiera dane z PIM i może linkować do karty produktu w DPPC.

Nie każda firma potrzebuje wszystkich czterech elementów. Mniejszy producent bez PIM może zasilać DPPC bezpośrednio z ERP i plików, a rozbudowany PIM wprowadzić dopiero wtedy, gdy liczba kanałów sprzedaży tego wymaga. Szerzej rozpisujemy to w artykule PIM, ERP, DPPC – kiedy potrzebujesz każdego systemu.

Model danych, który wytrzyma kolejne wymagania

Skoro dokładna lista pól dla wielu grup produktów nie jest jeszcze znana, model danych trzeba zaprojektować tak, żeby nowe atrybuty dało się dodawać bez przebudowy. Kilka zasad, które stosujemy:

• Poziomy identyfikacji. Rozróżnienie modelu, partii i pojedynczego egzemplarza od pierwszego dnia. Dane modelu wpisuje się raz i dziedziczy, dane partii lub numeru seryjnego dochodzą z produkcji.
• Atrybuty zamiast pól na sztywno. Grupy atrybutów przypisane do kategorii produktów, z typem, jednostką, walidacją i informacją o źródle.
• Dokumenty jako obiekty. Deklaracja zgodności czy raport z badań ma wersję, datę ważności, język i przypisanie do modeli, a nie jest po prostu plikiem w folderze.
• Wersje i daty obowiązywania. Zmiana materiału czy dostawcy tworzy nową wersję. Produkt sprzedany wcześniej nadal pokazuje dane aktualne w chwili produkcji.
• Poziomy dostępu. Część informacji jest publiczna, część przeznaczona dla serwisów, recyklerów czy organów nadzoru – to powinno wynikać z modelu, a nie z ukrytego linku.

Compliance jako proces, nie jednorazowy import

Paszport, który raz uzupełniono i zostawiono, szybko się zdezaktualizuje. Dlatego w DPPC projektujemy przepływ pracy, a nie tylko formularz:

1. Import z ERP i PIM (przez API lub plik) tworzy lub aktualizuje wersję roboczą.
2. Walidacja sprawdza wymagane atrybuty i dokumenty dla danej grupy produktów, a braki trafiają jako zadania do osób odpowiedzialnych.
3. Dział jakości lub compliance zatwierdza wersję.
4. Nowa wersja jest publikowana, a poprzednia pozostaje w historii.
5. Dokumenty z kończącą się datą ważności generują przypomnienie, zanim na publicznej karcie pojawi się nieaktualny certyfikat.

Warto też ustalić, kto może zatrzymać publikację. Jeśli dział jakości zgłasza wątpliwość co do deklaracji, wersja nie powinna trafić na publiczną kartę tylko dlatego, że import przeszedł walidację techniczną.

Najtrudniejszym elementem bywa zwykle nie technika, tylko dane od dostawców – skład materiałowy, substancje, pochodzenie. Warto od początku ustalić z najważniejszymi dostawcami format i terminy przekazywania tych informacji.

Publiczne karty produktów a SEO

Publiczna karta produktu, do której prowadzi kod QR, to też strona internetowa. Dobrze przygotowana może pracować na widoczność producenta w Google i w odpowiedziach narzędzi AI, bo zawiera dokładnie to, czego szukają specjaliści: parametry, materiały, instrukcje, dokumenty. Żeby tak się stało:

• karta musi być indeksowalna i mieć stabilny, czytelny adres,
• treść powinna być unikalna, a nie kopią opisu ze sklepu,
• dane strukturalne schema.org (np. Product) powinny odpowiadać temu, co widać na stronie,
• karty trzeba podlinkować z serwisu firmy i ze sklepu, żeby nie były „wyspą” dostępną tylko ze skanu,
• dokumenty PDF warto uzupełnić o treść w HTML, bo ta jest łatwiejsza do przeczytania dla ludzi i robotów.

Nie każda informacja z paszportu powinna być indeksowana – dane dla partnerów i organów nadzoru zostają za logowaniem. Więcej o samych kartach i kodach QR piszemy w tekście kody QR i publiczne karty produktu DPPC.

Typowe błędy

• Zaczynanie od etykiety z QR. Kod na produkcie to ostatni krok. Bez identyfikatorów i uporządkowanych danych prowadzi do statycznej strony, którą trzeba będzie przebudować.
• Ręczne kopiowanie danych. Sprawdza się w pilotażu na kilku produktach, nie przy całym asortymencie.
• Brak właściciela danych. Produkt, jakość, marketing i IT zakładają, że odpowiada ktoś inny. Każdy atrybut powinien mieć przypisaną rolę.
• Wszystko publicznie albo wszystko za hasłem. Oba skrajne podejścia mijają się z celem.
• Osobne projekty dla compliance i dla sklepu. Kończą się dwiema bazami danych, które zaczynają się różnić po kilku miesiącach.

Plan na pierwsze etapy

1. Mapa danych dla jednej rodziny produktów – atrybuty, dokumenty, źródła i osoby odpowiedzialne.
2. Pilotaż DPPC – import z ERP lub PIM, publiczne karty z kodami QR, proces zatwierdzania.
3. Integracja zwrotna – sklep lub portal B2B pobiera dane i dokumenty z DPPC przez API.
4. Rozszerzenie – kolejne rodziny produktów, dane od dostawców, poziomy dostępu dla partnerów.

Następny krok

Wybierz jedną rodzinę produktów i spisz, jakie dane i dokumenty będą potrzebne w paszporcie, gdzie są dziś przechowywane i kto je aktualizuje. To zwykle wystarcza, żeby zobaczyć, czy głównym problemem są dane, integracje czy odpowiedzialności. Na stronie DPPC i dane produktowe opisujemy, jak prowadzimy takie wdrożenia, a jeśli chcesz przejść przez mapę danych razem z nami, napisz do nas.