Kto odpowiada za dane do Digital Product Passport? RACI dla zespołu DPP

Status funkcji: ten artykuł opisuje model operacyjny i docelowy wzorzec Data Stewardship Queue. Zadania dla luk, automatyczne przypomnienia, reguły przypisania, eskalacje i supplier task links nie są obecnie oferowane jako aktywna funkcja samoobsługowa DPP Compliance. W aplikacji można już wskazać źródło i właściciela luki w Data Mapperze, ale nie należy utożsamiać tego z pełnym workflow z terminami i eskalacją.

Krótka odpowiedź: kto odpowiada za dane DPP?

Komisja Europejska wskazuje, że podstawowa odpowiedzialność za utworzenie i poprawność DPP spoczywa na operatorze gospodarczym wprowadzającym produkt na rynek Unii. Do jego zadań należy zebranie danych, rejestracja, gdy wymaga jej właściwy akt, oraz utrzymanie poprawnych informacji w cyklu życia produktu.

ESPR wymaga, aby dane w DPP były dokładne, kompletne i aktualne dla produktów objętych właściwymi aktami delegowanymi. Rozporządzenie nie narzuca jednak każdej firmie jednej wewnętrznej macierzy z nazwami działów Product, Compliance, Procurement i IT.

RACI jest więc narzędziem organizacyjnym, a nie urzędowym certyfikatem ani gotowym podziałem odpowiedzialności prawnej. Pomaga wskazać osobę wykonującą zadanie i osobę odpowiedzialną za jego wynik. Nie przenosi obowiązków operatora gospodarczego na dostawcę software'u, konsultanta albo pracownika wpisanego w arkuszu.

Co oznaczają R, A, C i I?

Dla jednej aktywności warto wskazać jedną funkcję A. Kilka osób może wykonywać pracę, ale wielu równorzędnych accountable zwykle powoduje, że nikt nie czuje się właścicielem wyniku.

RACI nie powinno być tworzone wyłącznie na poziomie całego projektu. Najbardziej użyteczny podział powstaje dla konkretnych działań lub klas danych, takich jak identyfikatory, skład materiałowy, deklaracje dostawców, dokumenty evidence, mapowanie ERP i publikacja.

Przykładowa macierz RACI dla Digital Product Passport

Poniższa tabela jest punktem startowym. Trzeba ją dostosować do produktu, właściwego aktu, struktury firmy i faktycznego operatora gospodarczego.

W małej firmie jedna osoba może pełnić kilka funkcji. To nie unieważnia macierzy. Nadal warto zapisać, kiedy działa jako Product Owner, kiedy jako Compliance, a kiedy jako osoba publikująca DPP.

Product: właściciel danych podstawowych i zmian produktu

Zespół Product lub Product Data zwykle utrzymuje:

• nazwę, model, wariant i podstawowe identyfikatory;
• relacje między rodziną produktu, wariantem, partią i sztuką;
• cechy techniczne pochodzące z zatwierdzonej specyfikacji;
• datę oraz zakres zmian wpływających na DPP;
• decyzję, które źródło jest kanoniczne dla danego pola.

Product nie powinien samodzielnie interpretować każdego obowiązku prawnego ani akceptować evidence poza swoim zakresem kompetencji. Jego ważnym zadaniem jest zapewnienie, że zmiana produktu wywoła ponowną ocenę readiness i nie nadpisze po cichu opublikowanej wersji paszportu.

Compliance: wymagania, evidence i granica decyzji

Compliance zwykle odpowiada za:

• wybór właściwego, wersjonowanego profilu wymagań;
• rozstrzygnięcie, czy wymaganie dotyczy konkretnego produktu;
• ocenę zakresu, ważności i przydatności evidence;
• klasyfikację informacji jako publicznej, restricted lub przeznaczonej dla organu;
• review przed publikacją, jeżeli polityka firmy tego wymaga;
• śledzenie zmian aktu i ponowną ocenę profilu.

Status complete w Data Mapperze nie może być automatycznie tłumaczony jako legal compliance. Pole może mieć wartość, ale nadal wymagać evidence, właściwego zakresu, aktualności albo interpretacji dla określonej kategorii produktu.

Procurement: dane i dokumenty od dostawców

Procurement jest naturalnym ownerem działań, które wymagają odpowiedzi dostawcy:

• deklaracji składu lub pochodzenia materiału;
• informacji o zawartości z recyklingu;
• certyfikatu albo raportu badania;
• identyfikacji komponentu;
• korekty niejednoznacznej lub niepełnej wartości;
• potwierdzenia aktualności danych po zmianie partii lub dostawcy.

Procurement odpowiada za pozyskanie informacji, ale nie powinien sam potwierdzać jej technicznej albo prawnej wystarczalności, jeżeli wymaga to udziału Quality, Engineering lub Compliance.

Dobry request do dostawcy wskazuje produkt lub komponent, wymagane pole, oczekiwany format, termin i podstawę biznesową. Nie powinien przesyłać pełnego prywatnego profilu produktu ani udostępniać innych rekordów organizacji.

IT / Data: źródła, mapowanie i niezawodny przepływ

IT albo zespół Data zwykle odpowiada za:

• dostęp do właściwego ERP, PIM, PLM lub repozytorium dokumentów;
• mapowanie pola źródłowego do kanonicznego modelu DPP;
• transformacje jednostek, formatów i słowników;
• identyfikację błędów integracji;
• idempotencję, retry, monitoring i ślad techniczny;
• przekazanie zmiany do ponownej walidacji.

IT nie powinno zgadywać wartości biznesowej, której nie ma w źródle. Brak źródła pozostaje brakiem. Automatyczna transformacja nie dowodzi też prawdziwości deklaracji dostawcy.

Od ownera pola do zadania: czego brakuje w zwykłej checkliście?

Samo wskazanie Missing i nazwiska nie odpowiada na pytanie, czy ktoś rozpoczął pracę. Operacyjny rekord powinien zawierać co najmniej:

Produkt: ABC-123
Wymaganie: recycled_content_pct
Problem: Missing evidence
Owner: Anna / Procurement
Źródło: Supplier Stahl GmbH
Termin: 25 Sep 2026
Priorytet: Blocking
Status: Waiting for supplier
Profil wymagań: battery-passport v2
Rewizja produktu: 7

To właśnie różnica między ownerem w mapie danych a kolejką Data Stewardship. Pierwszy mówi, do kogo zwykle należy pole. Drugie tworzy konkretną sprawę z terminem, stanem i śladem wykonania.

Prosty cykl życia luki danych

Open
→ Assigned
→ In progress
→ Waiting for supplier
→ Ready for review
→ Closed

• Open — system wykrył actionable gap, ale zadanie nie ma jeszcze ownera;
• Assigned — aktywny członek organizacji przejął odpowiedzialność za wykonanie;
• In progress — trwa poprawa danych albo zebranie evidence;
• Waiting for supplier — następna odpowiedź musi przyjść z zewnątrz;
• Ready for review — nowe dane usunęły finding i mogą zostać sprawdzone;
• Closed — uprawniona osoba potwierdziła rozstrzygnięcie.

Zmiana danych powinna uruchomić ponowną walidację. Nie powinna jednak usuwać zadania bez historii. Jeżeli dokument wygaśnie albo nowy profil ponownie wykaże lukę, zadanie może zostać otwarte ponownie z informacją o przyczynie.

Data Stewardship a Approval Workflow

Te mechanizmy obsługują różne decyzje:

Zamknięcie zadania nie powinno automatycznie oznaczać approval. Approval nie powinien z kolei zamykać innej, nadal otwartej luki. Oba zdarzenia wymagają osobnego audit trail.

Automatyczne przypisanie: reguły, nie kod na stałe

Gdy katalog rośnie, ręczne przypisanie każdej luki staje się wąskim gardłem. Organizacja może przygotować wersjonowane reguły:

material fields → Sustainability
certificate / evidence → Compliance
supplier declaration → Procurement
ERP identifier / integration_required → IT/Data

Reguła powinna mieć zakres, priorytet, autora, datę aktywacji i fallback Unassigned. Konflikt dwóch reguł wymaga review. Zmiana reguły nie może po cichu przepisać ownerów historycznych zadań ani zmienić opublikowanego DPP.

Przypomnienia bez zalewania skrzynki

Praktyczny model może rozróżniać:

• powiadomienie natychmiast po przypisaniu zadania;
• przypomnienie kilka dni przed terminem;
• eskalację po przekroczeniu terminu;
• komunikat, gdy ponowna walidacja przeniesie zadanie do review;
• ponowne otwarcie po wygaśnięciu evidence lub regresji danych.

Powiadomienie nie powinno zawierać poufnej wartości pola ani całego dokumentu. Bezpieczniejszy jest identyfikator produktu, ogólny typ sprawy, termin i link wymagający logowania. Dostarczenie e-maila nie może być warunkiem zatwierdzenia zmiany danych.

Jak mierzyć backlog danych DPP?

Sam procent readiness nie pokazuje, czy zespół kontroluje pracę. Przydatne metryki to:

• liczba otwartych luk bez ownera;
• liczba spraw oczekujących na dostawcę;
• liczba zadań po terminie;
• liczba zadań blokujących publikację;
• czas od wykrycia do pierwszego przypisania;
• czas od przypisania do Ready for review;
• liczba ponownie otwartych spraw;
• rozkład wieku zadań, np. 0–3, 4–7, 8–14, 15+ dni.

Progi i SLA są polityką organizacji. Nie wynikają automatycznie z ESPR ani ze wspólnego terminu dla wszystkich branż.

Dane prywatne, dane publiczne i ownerzy

Macierz odpowiedzialności, komentarze, terminy, prywatne źródła i nazwiska ownerów są danymi wewnętrznymi organizacji. Nie powinny stawać się częścią publicznego DPP przez sam import albo przypisanie zadania.

Przed publikacją trzeba osobno określić:

• które pole może być publiczne;
• które jest restricted;
• które ma być dostępne właściwemu organowi;
• która zatwierdzona wartość trafia do niezmiennej wersji DPP;
• czy publiczny paszport nadal odpowiada bieżącym, zatwierdzonym danym.

RACI opisuje ludzi i decyzje. Model access rights opisuje odbiorców danych. Nie należy łączyć tych dwóch warstw w jedną flagę.

Pobierz darmowy szablon RACI dla danych DPP

Pobierz szablon RACI dla Digital Product Passport (XLSX)

Szablon zawiera:

• krótką instrukcję użycia;
• przykładową macierz dla Product, Compliance, Procurement i IT/Data;
• kolumny dla właściciela, źródła, terminu, statusu i uwag;
• listy wyboru dla statusu oraz priorytetu;
• przykłady obejmujące identyfikatory, supplier evidence, mapowanie ERP i publikację DPP.

Przed użyciem usuń lub dostosuj przykładowe role. Dla każdej aktywności potwierdź faktycznego operatora gospodarczego, właściwy profil wymagań i osobę uprawnioną do decyzji. Arkusz pomaga zarządzać pracą. Nie jest certyfikatem, opinią prawną ani dowodem zgodności produktu.

Jak przeprowadzić warsztat RACI w 60 minut?

1. Wybierz jedną rodzinę produktów i właściwą wersję profilu wymagań.
2. Wypisz pola i evidence, które Data Mapper wskazuje jako brakujące, niepoprawne lub wymagające integracji.
3. Dla każdej pozycji wskaż system źródłowy albo dostawcę.
4. Przypisz jedną funkcję R i jedną funkcję A.
5. Dodaj osoby konsultowane tylko tam, gdzie ich decyzja rzeczywiście jest potrzebna.
6. Określ termin, priorytet i kryterium zamknięcia.
7. Wybierz pierwsze zadania blocking i sprawdź, czy ownerzy mogą je realnie wykonać.
8. Po zmianie danych wykonaj ponowną walidację i zachowaj wynik review.

Nie zaczynaj od idealnej macierzy dla całego katalogu. Pierwszy warsztat powinien przetestować jeden powtarzalny przepływ, na przykład deklarację materiałową dostawcy albo identyfikator pochodzący z ERP.

Najczęstsze pytania

Czy Compliance powinno odpowiadać za wszystkie dane DPP?

Nie. Compliance może odpowiadać za interpretację wymagań i review evidence, ale dane podstawowe, informacje dostawców i integracje mają innych właścicieli operacyjnych. Próba przeniesienia całej pracy do jednego działu tworzy kolejkę bez dostępu do faktycznych źródeł.

Czy dostawca może być Responsible w RACI?

Może dostarczać informacje w uzgodnionym zakresie, ale organizacja nadal musi określić wewnętrznego ownera requestu i osobę, która oceni wynik. Zewnętrzny dostawca nie powinien otrzymywać dostępu do całego prywatnego katalogu ani cudzych zadań.

Czy właściciel pola jest tym samym co approver?

Nie zawsze. Owner może poprawić wartość lub pozyskać dokument, a inna osoba sprawdza zakres i zatwierdza publikację. Taki podział jest szczególnie ważny przy polach publicznych i evidence o istotnym wpływie.

Czy zamknięte zadania potwierdzają zgodność produktu?

Nie. Pokazują wykonanie zdefiniowanej pracy. Legal compliance zależy od właściwego aktu, zakresu produktu, kompletności dokumentacji i innych obowiązków, których nie zastępuje status zadania.

Od czego zacząć?

Od mapy pole DPP → system źródłowy → Responsible → Accountable → termin → kryterium zamknięcia. Następnie sprawdź ją na jednym produkcie i jednym realnym supplier request. Zobacz zakres wdrożenia DPP.