Hur ofta måste jag uppdatera data i produktpasset?

Vad du konkret måste göra

Vad som förväntas av dig

Artikel 9 och artikel 10 i ESPR (förordning (EU) 2024/1781) beskriver vad ett digitalt produktpass måste kunna och vilka uppgifter som ska ingå i det, men ger ingen allmän regel för hur ofta dessa uppgifter måste uppdateras. Det som dock framgår av texten är ett antal anknutningspunkter som tillsammans bestämmer hur aktuellt ett produktpass i praktiken måste vara.

Produktpasset måste stämma vid tidpunkten då det konsulteras

Artikel 9 föreskriver att det digitala produktpasset måste vara tillgängligt via databäraren och att informationen i det måste återge produktens egenskaper. För ett företag med tio till hundra anställda innebär detta att produktpasset inte är en ögonblicksbild som ligger på hyllan efter publicering, utan en datasamling som motsvarar vad som är känt om produkten så länge produktpasset är tillgängligt. När en specifikation ändras – en annan underleverantör av en komponent, en justerad sammansättning, ett nytt testresultat – uppstår en skillnad mellan vad produktpasset säger och vad produkten faktiskt är.

Ändringar i produktuppgifter återspeglas i produktpasset

Artikel 10 nämner krav på de uppgifter som finns i produktpasset, inklusive uppgifter som direkt följer av de produktgruppsspecifika regler som fastställs per produktgrupp. Det berör frågan vilka uppgifter ingår i produktpasset för produktereftersom inte varje uppgift har samma känslighet för förändring. En fysisk dimension ändras sällan, ett testresultat för en miljöindikator kan ändras så snart produktionsmetoden ändras eller så snart en ny mätning utförs enligt metoden för att mäta värdena. För ett företag med flera produktvarianter och periodiska justeringar av sortimentet innebär detta att upprätthållandet av produktpassuppgifter är en återkommande punkt, inte en engångsövning vid lansering.

Kopplingen mellan produktpass och produkt måste förbli identifierbar

Ett produktpass som hör till en produkt måste också fortfarande känna igen denna produkt när något ändras på en modellvariant, en batch eller en produktversion. För ett medelstort företag som arbetar med flera modellnummer innebär detta att en ändring av en produkt inte bara påverkar ett tekniskt dossier, utan väcker också en fråga: vilket produktpass hör till vilken version, och är denna distinktion fortfarande tydlig för någon som konsulterar produktpasset via QR-koden på själva produkten.

Där det går fel i praktiken

En leverantörsväxling genomförs inte i produktpasset. En tillverkare byter underleverantör för en komponent, de nya specifikationerna avviker på vissa punkter, men ingen länkar denna förändring tillbaka till det redan publicerade produktpasset. Produktpasset fortsätter att visa de gamla uppgifterna.

Testresultat förväxlas med fasta egenskaper. Ett resultat från en engångsmätning placeras i produktpasset som om det vore en permanent uppgift, medan det egentligen hör till en specifik batch eller testdatum. Vid nästa produktionskörning saknas det tillfälle då någon ställer sig frågan om uppgiften fortfarande är korrekt.

Reparationsinformation överensstämmer inte längre med det aktuella komponentutbudet. Uppgifter om reparation och komponenter i produktpasset fylls i vid lansering, men när en komponent fasas ut eller ersätts med ett annat komponentnummer, förblir den gamla informationen eftersom ingen behandlar denna del av produktpasset som ett "levande" dokument.

Flera språkversioner hamnar ur synk. När en justering av den nederländska texten genomförs glöms det att det även finns en fransk eller tysk version för uppgifter på flera språk. Den ena språkversionen visar då en annan status än den andra, medan båda finns under samma QR-kod.

Ett påvisat fel löses provisoriskt istället för strukturellt. Någon märker att ett paspoort visar en felaktig uppgift, justerar det manuellt i systemet för tillfället, men dokumenterar inte när och varför justeringen genomfördes. Vid nästa ändring går det inte längre att spåra vad den ursprungliga källan till felet var — medan det i stället borde finnas en fast procedur för när ett fel i ett redan publicerat paspoort upptäcks.

Vad ni kan dokumentera

• En översikt över vilka uppgifter i paspoorten som är känsliga för förändring — en skillnad mellan fasta egenskaper (dimensioner, materialtyp) och variabla uppgifter (testresultat, leverantör av en del, tillgänglighet av reservdelar).
• En fast tidpunkt i produktionsprocessen när paspoortuppgifter kontrolleras — till exempel vid varje ändring av den tekniska dokumentationen, vid ett leverantörsbyte, eller vid en periodisk intern granskning.
• En ansvarig för underhållet av varje paspoort per produktgrupp — särskilt relevant för ett företag som är verksamt i flera produktgrupper samtidigt, eftersom uppgifterna och granskningsfrekvensen kan skilja sig åt per produktgrupp.
• En ändringslogg för ett publicerat paspoort — vad som ändrades, när, och baserat på vilket källdokument, så att en ändring kan spåras.
• En kontroll av överensstämmelsen mellan språkversioner vid varje ändring, så att inte en språkversion halkar efter den andra.
• En översikt över vilka uppgifter som publiceras under vilka förutsättningar, särskilt när en del av den underliggande informationen rör frågan om huruvida uppgifter om produkten är affärshemligheter och därför inte utan vidare bör vara synliga för alla — denna skillnad genomsyrar hur en uppdatering genomförts och vem som har åtkomst.

För företag som arbetar med en plattform som hanterar pasportvärdskap och QR-dataöverföraren, förskjuts en del av denna dokumentation till avtalet med denna part: vem genomför ändringen, inom vilken process, och hur säkerställs det att den publicerade versionen överensstämmer med de senast levererade uppgifterna från företaget själv.