EU:n digitaalisen tuotepassin opas brändeille

Vaatimustenmukaisuudesta vastaava henkilösi tuijottaa taulukkoa, josta puolet kentistä on tyhjiä, toimittajiesi sähköpostit ovat hajallaan kolmessa postilaatikossa, ja joku lakiosastolta haluaa ennen seuraavaa EU-aiheista keskustelua selkeän vastauksen materiaaleista, korjattavuudesta ja käyttöoikeuksista. Tästä EU:n digitaalinen tuotepassi saa alkunsa – ei politiikkamuistiona vaan sekavana operatiivisena tilanteena, jossa tuotetiedot ovat kaikkialla paitsi yhdessä paikassa, johon tiimisi voisi luottaa. Digitaalinen tuotepassi muuttaa tilanteen kokoamalla hajallaan olevat tietueet eläväksi tuotteen identiteetiksi. Sen sijaan, että vaatimustenmukaisuustietoja käsiteltäisiin staattisena PDF-tiedostona, brändit tarvitsevat hallitun tietueen, jota voidaan päivittää koko tuotteen elinkaaren ajan ja joka tukee jäljitettävyyttä sekä vastaa kuluttajien, korjaajien, kierrättäjien ja viranomaisten erilaisiin kysymyksiin. Euroopan komissio kuvaa passia sisämarkkinoiden toimialat ylittäväksi jäljitettävyysmekanismiksi. Sen sisältö riippuu tuoteryhmästä, ja se voi sisältää tietoja turvallisuudesta, alkuperästä, materiaaleista, korjattavuudesta, ympäristösuorituskyvystä, uudelleenkäytöstä ja kierrätyksestä ([Euroopan komission yleiskatsaus digitaaliseen tuotepassiin]). Muutos on tärkeä, koska haastavinta ei ole pelkästään datan olemassaolo. Haastavinta on osoittaa, että data on jäsenneltyä, ajantasaista ja näyttöön perustuvaa, kun joku pyytää sitä kuukausia myöhemmin. Jos haluat edetä nopeasti, aloita käsittelemällä passia tuotteen identiteettiohjelmana, ei asiakirjojen lataushankkeena. Tämä selitys digitaalisesta tuotepassista tarjoaa hyödyllisen johdannon aiheeseen.

• Johdanto digitaalisiin tuotepasseihin - Miksi paine kohdistuu ensin brändeihin - Keskeisten käsitteiden ymmärtäminen - Keskeiset rakennuspalikat - Sääntelytausta ja rekisteriin kohdistuvat odotukset - Mitä rekisteri tarkoittaa käytännössä - Vaaditut tietokentät ja näyttökäytännöt - Kunkin kentän taustalla olevan näytön rakentaminen - Toteutusmallit ja tunnisteet - Kolme käytännöllistä toteutusmallia - Integraatiosääntö, jonka useimmat tiimit unohtavat - Toimittajaprosessit ja teknologiaintegraatio - Toimiva toimittajaprosessi - Manuaalista työtä vähentävät integraatiovalinnat - Valmiuden tarkistuslista ja siirtymäopas - Yksinkertainen toimintasuunnitelma - Käynnistyksen kyllä–ei-kysymykset - Yhteenveto ja seuraavat vaiheet

Jalkinebrändi on kahden kuukauden päässä EU-markkinoille suuntautuvasta lanseerauksesta, ja vaatimustenmukaisuustiimi yrittää saada kasaan tietoja kuitukoostumuksesta, korjausohjeista ja toimittajien ilmoituksista. Ongelma ei ole se, ettei tietoa olisi olemassa. Se on hajallaan: yksi PDF hankinnasta, yksi taulukko laadunhallinnasta ja joukko sähköposteja, joiden omistajuutta kukaan ei halua ottaa. Juuri tästä syystä EU:n digitaalinen tuotepassi herättää nyt huomiota. Komission kanta on selvä: passi ei ole yksi yleispätevä malli. Sisältö riippuu tuoteryhmästä, ja se voi sisältää tietoja turvallisuudesta, alkuperästä, materiaaleista, korjattavuudesta, ympäristösuorituskyvystä, uudelleenkäytöstä ja kierrätyksestä ([Euroopan komission digitaalista tuotepassia käsittelevä sivu]). Käytännössä tämä tarkoittaa, etteivät brändit voi odottaa lopullista yhtä kaikille sopivaa asiakirjaa. Ne tarvitsevat järjestelmän, joka voi kehittyä tuoteryhmittäin. Strateginen muutos on helppo kuvata mutta vaikeampi toteuttaa. Passi ei ole jaetulle levyasemalle tallennettu staattinen tiedosto. Se on hallittu tuotteen identiteetti, jonka pitäisi säilyä hyödyllisenä, kun tuote myydään, korjataan, myydään jälleen tai kierrätetään. Siksi varhainen valmiuden rakentaminen alkaa yleensä tuotteen perustiedoista, lähteiden jäljitettävyydestä ja näyttöön perustuvista väitteistä – ei hienon PDF:n ulkoasun suunnittelusta.

Vaatimustenmukaisuustiimit kokevat paineen, koska jokainen puuttuva kenttä aiheuttaa ongelman seuraavassa vaiheessa. Operatiiviset tiimit kokevat sen, kun toimittaja antaa eri materiaalideklaroinnin kuin se, jota luettelossa käytetään. Kaupalliset tiimit kokevat sen, kun asiakkaille suunnattuja väitteitä ei voida yhdistää hyväksyttyyn näyttöön. Nämä ovat piileviä työnkulkujen puutteita, jotka muuttavat sääntelytehtävän liiketoimintariskiksi. > Käytännön sääntö: jos tuotetietoa ei voida jäljittää lähteeseen ja vastuulliseen omistajaan, se ei ole valmis passissa julkaistavaksi. Varhain valmistautuvat brändit saavuttavat yleensä kaksi asiaa samanaikaisesti. Ne vähentävät määräaikoihin liittyvää kiirettä ja rakentavat puhtaamman tietopohjan korjaus-, jälleenmyynti- ja kiertotalouden kaupankäyntiprosesseille. Siksi passia pitäisi käsitellä toimintamallin muutoksena, ei viime hetken vaatimustenmukaisuusasiakirjana.

Hyödyllinen tapa ajatella EU:n digitaalista tuotepassia on nähdä se tuotteen digitaalisena lompakkona. Lompakko ei sisällä yhtä valtavaa asiakirjaa, vaan tarkistettavia kortteja ja tietueita, joita voidaan tarkastella tarpeen mukaan. Passi toimii pikemminkin tällä tavalla kuin perinteisen vaatimustenmukaisuus-PDF:n tavoin. Komission mukaan passin sisältö vaihtelee tuoteryhmittäin, ja data voi kattaa turvallisuuden, alkuperän, materiaalit, korjattavuuden, ympäristösuorituskyvyn, uudelleenkäytön ja kierrätyksen ([Euroopan komission digitaalista tuotepassia käsittelevä sivu]). Joustavuus on tärkeää, koska takki, akku ja tuoli eivät tarvitse samaa kenttäjoukkoa. Skeema mukautuu tuoteryhmään, ei päinvastoin. Brändien on sisäistettävä seuraava peruslogiikka. Ensinnäkin jokaisella tuotteen identiteetillä on oltava pysyvä ankkuri. Toiseksi identiteettiin on päästävä koneellisesti luettavalla tavalla, yleensä tiedonkantajan kautta. Kolmanneksi sen taustalla olevaa dataa on hallittava, jotta passi pysyy täsmällisenä koko elinkaaren ajan. Jos jokin näistä osista on heikko, passiin on vaikea luottaa.

EU:n työssä käytetty identiteettikehys tukee malli-, erä- ja tuotetasoja, joten samaa hallintamallia voidaan käyttää tuoteperheeseen, tuotantoerään tai sarjoitettuun yksikköön (Euroopan komission tekninen asiakirja5423_1/de00000001065679)). Tämä on hyödyllistä, koska kaikki tuotteet eivät tarvitse tuotetason hallintaa. Jotkin brändit hallinnoivat passeja SKU-tasolla, toiset erätasolla, ja jotkin arvokkaat tai säännellyt tuotteet tarvitsevat sarjoittamisen. Suunnittelua pitäisi ajatella hallituilla syötteillä varustettuna elävänä tietueena, ei loputtomilla tekstikentillä täytettynä lomakkeena. Tavoitteena on tehdä datasta hyödyllistä ihmisille ja järjestelmille koko ketjussa. Korjausteknikko saattaa tarvita tietueesta eri osan kuin tullivirkailija, ja kuluttaja saattaa tarvita vain näkyvän osan. > Nopein tapa ajautua umpikujaan on käsitellä passia suunnittelutehtävänä. Todellisuudessa kyse on datahallintatehtävästä, jolla on julkinen käyttöliittymä. Yksi viimeinen erottelu auttaa oikaisemaan yleisen väärinkäsityksen. QR-koodi ei ole passi. Se on vain yksi mahdollinen pääsypiste passin tietoihin. Passi on taustalla oleva hallittu tietue, ja koodi on ovi.

EU ottaa digitaalisen tuotepassin velvoitteita käyttöön tuoteryhmittäin, ei kaikkea kerralla. Tämä on tärkeää, koska vaatimustenmukaisuustiimit esittävät usein ensin väärän kysymyksen: ”Onko passi jo käytössä?” Parempi kysymys on: ”Mitkä tuoteryhmät kuuluvat tällä hetkellä soveltamisalaan, ja mikä tietomalli niihin soveltuu?” Komission kehys on nimenomaisesti vaiheistettu, ja tuoteryhmäkohtaiset delegoidut säädökset määrittävät, mitä passiin sisällytetään ja milloin ([Euroopan komission digitaalista tuotepassia käsittelevä sivu]). Ensimmäinen lainsäädännössä konkreettinen etappi on akkupassi. Toimialakohtaisten ohjeiden ja alan aikataulujen mukaan teollisuusakut ja sähköajoneuvojen akut, joiden kapasiteetti on yli 2 kWh, tarvitsevat digitaalisen tuotepassin 18. helmikuuta 2027 alkaen ([Circularisen toimialakohtainen aikajana]). Muiden merkittävien tuoteryhmien odotetaan tulevan mukaan myöhemmin: tekstiilit, elektroniikka, huonekalut ja muut ryhmät seuraavat vaiheittain 2020-luvun loppupuolella, ja useimpien jäljellä olevien tuoteryhmien tavoitteena on noin vuosi 2030 ([Circularisen toimialakohtainen aikajana]).

Rekisteriä koskeva odotus ei ole vain sitä, että data tallennetaan jonnekin. Arkkitehtuuri perustuu yhteen viralliseen passiin kutakin tuoteidentiteettiä kohden, ja tiedonkantaja yhdistää sen pysyvään yksilölliseen tuotetunnisteeseen. Tunnistekehyksen on tuettava malli-, erä- ja tuotetason tarkkuutta ([Euroopan komission tekninen asiakirja]5423_1/de00000001065679)). Tämä kertoo, mitä järjestelmällä pyritään ehkäisemään: päällekkäisiä tietueita, ristiriitaisia tietueita ja passeja, joita ei voida luotettavasti kohdentaa. Brändeille tämä tarkoittaa, että rekisterivalmius on osittain järjestelmäongelma ja osittain omistajuusongelma. Jonkun on päätettävä, mikä tiimi omistaa tunnisteen, kuka voi muokata tietuetta ja mitä tapahtuu, kun lähdedata muuttuu. Ilman näitä sääntöjä rekisteriyhteys vain levittää huonoa dataa nopeammin. > Operatiivinen havainto: määräajat paljastavat hallinnon puutteet kauan ennen teknisten puutteiden paljastumista. Kaikkia tuoteryhmäkohtaisia sääntöjä ei tarvita ensimmäisenä päivänä, mutta tarvitset siirtymäpolun, joka pystyy ottamaan ne vastaan. Tuoteryhmä voi aluksi kuulua rajattuun soveltamisalaan ja laajentua myöhemmin, kun delegoidut säädökset lisäävät kenttiä ja käyttöoikeuksia koskevia vaatimuksia. Ne brändit, jotka kartoittavat tietomallinsa varhain, sopeutuvat myöhemmin vähemmällä kaaoksella.

Akkupassi on hyvä esimerkki siitä, miksi EU:n digitaalista tuotepassia ei voida käsitellä markkinointiesitteen tavoin. Teollisuusakkujen ja sähköajoneuvojen akkujen osalta ohjeissa viitataan esimerkiksi seuraaviin kenttiin: nimelliskapasiteetti, nimellisjännite, nimellisenergia, suurin sallittu teho, sisäinen resistanssi, odotettu käyttöikä sykleinä, akun kunnon kynnysarvot sekä vaiheittain eritelty elinkaaren hiilijalanjälki-ilmoitus. Vuodesta 2027 alkaen sähköajoneuvojen akkujen osalta tähän sisältyy A–E-hiilijalanjälkiluokka ([Brightestin akkupassiohje]). Tämä on paljon täsmällisempää kuin bränditarina tai vastuullisuussivu. Opetus ulottuu akkuja laajemmalle. Passia pitäisi käsitellä skeemaan perustuvana tietosäiliönä, koska vaaditut tietokentät muuttuvat tuoteryhmän ja delegoidun säädöksen mukaan. Et täytä kiinteää mallia kerran ja siirry eteenpäin. Kartoitat säännellyt kentät oikeisiin mittausmenetelmiin, oikeisiin lähdeasiakirjoihin ja oikeille hyväksyjille.

Vahva näyttömalli alkaa yleensä kolmesta kysymyksestä. Mistä data on peräisin? Kuka hyväksyi sen? Mitä tapahtuu, jos lähde muuttuu? Kysymykset kuulostavat yksinkertaisilta, mutta juuri ne erottavat käyttökelpoisen passin tietueesta, johon kukaan ei luota. Jos toimittaja esimerkiksi lähettää materiaalideklaroinnin, se pitäisi yhdistää täsmälleen siihen versioon, jota passissa käytetään. Jos sisäinen laboratorio mittaa suorituskykyominaisuuden, menetelmä ja päivämäärä on säilytettävä tietueen yhteydessä. Jos lakitiimi merkitsee kentän arkaluonteiseksi, julkaisupäätöksen pitäisi olla nimenomainen eikä syntyä vahingossa. Kirjaamiskäytännöillä on merkitystä, koska heikko ylävirran tietoaineisto ei pysy heikkona yhdessä järjestelmässä. Se voi levitä vaatimustenmukaisuusriskeiksi, korjattavuutta koskevaksi epäselvyydeksi, jälleenmyyntiongelmiksi tai kierrätysvirheiksi. Siksi brändit tarvitsevat näytön hallintaa, eivät vain datan vastaanottoa. Käytä tätä lähestymistapaa, kun kartoitat kenttiä: - Pakolliset kentät: kerää vain ne tiedot, joita sovellettava tuoteryhmä ja delegoitu säädös edellyttävät, ja liitä mukaan lähde ja omistaja. - Ennakoivat kentät: tallenna ne, kun tiedät tulevien säädösten todennäköisesti tarvitsevan niitä, vaikka ne eivät vielä olisi pakollisia. - Valinnaiset kentät: säilytä ne, jos ne auttavat operaatioissa, mutta erota ne selkeästi säännellystä sisällöstä. Avain on jäljitettävyys. Ilman näyttöä kenttä on vain väite. > Käytännön sääntö: jos väite ei kestä toimittajan tai henkilöstön vaihtumista, sitä ei ole hallittu riittävän hyvin julkaisemista varten. Hyödyllinen lähde näytön keräämiseen ja tietojen kirjaamiseen on opas siitä, mitä näyttöä tuotepassitietueessa pitäisi säilyttää. Pääajatus on yksinkertainen: rakenna kerran laadukkaan näytön varaan ja hyödynnä samaa mallia eri tuoteryhmissä sen sijaan, että keksisit sen uudelleen joka kerta.

Yleisin toteutusvirhe on aloittaa QR-koodista. Parempi lähtökohta on tuotteen identiteetti. Jos valitset väärän tunnistelogiiikan, muun teknisen kokonaisuuden hallinta vaikeutuu, vaikka skannauskokemus näyttäisi viimeistellyltä. EU:n arkkitehtuuri perustuu yhteen viralliseen passiin kutakin tuoteidentiteettiä kohden, ja tiedonkantaja yhdistää sen pysyvään yksilölliseen tuotetunnisteeseen ([Euroopan komission tekninen asiakirja]5423_1/de00000001065679)). Tämä on tärkeää, koska passin pitäisi johtaa yhteen luotettavaan tietueeseen, ei kolmeen keskenään kilpailevaan totuuden versioon. Tunnistekehyksen on toimittava myös malli-, erä- ja tuotetasoilla, joten brändien on päätettävä, kuinka yksityiskohtaista vaatimustenmukaisuuden hallintaa ne todella tarvitsevat.

Mallitason toteutus toimii, kun tuote pysyy samana tietyn tyylin tai SKU-tuoteperheen sisällä. Muotibrändi voisi käyttää sitä esimerkiksi perus-T-paitamallissa, jonka materiaalikoostumus ja hoito-ohjeet ovat samat koko tuotantoerän ajan. Erään linkitetty toteutus sopii tuotantoeriin, joissa lähde- tai valmistustiedot muuttuvat erästä toiseen. Se on tärkeää, kun brändi haluaa yhdistää tietyn ilmoituskokonaisuuden tiettyyn tehdaserään ilman, että jokaista kappaletta sarjoitetaan. Sarjoitettuun tuotteeseen perustuva toteutus on täsmällisin. Se sopii arvokkaille tuotteille, elektroniikalle tai tuotteille, joiden omistajuuden, korjauksen ja jälleenmyynnin on seurattava yhtä yksittäistä kappaletta ajan mittaan. Nämä eivät ole vain teknisiä valintoja. Ne vaikuttavat siihen, kuka syöttää datan, kuinka usein data muuttuu ja mitkä myöhemmän vaiheen tiimit voivat luottaa siihen. Jos yritys valitsee tuotetason hallinnan vähäriskiselle tuotteelle, seurauksena voi olla tarpeetonta työtä. Jos se pysyy mallitason hallinnassa tuotteella, joka todella tarvitsee sarjatason jäljitettävyyttä, tärkeitä elinkaaritapahtumia voi jäädä huomaamatta. Verkossa toimivassa tunnistamisessa monet brändit tarkastelevat GS1:n kaltaisia tunnistemalleja. Hyödyllinen tekninen lähde on GS1 Digital Link -tuki tuotteiden käyttöön. Tärkeää on, että tiedonkantajan, tunnisteen ja passitietueen on vastattava toisiaan. Jos näin ei ole, käyttäjä skannaa yhden asian ja päätyy toiseen, jolloin järjestelmä menettää uskottavuutensa.

Integraatio-ongelma ei ole ”Voimmeko tulostaa koodin?” vaan ”Pystyykö jokainen järjestelmä ratkaisemaan saman tuotteen identiteetin joka kerta?” Tämä tarkoittaa, että PIM-järjestelmän, ERP-järjestelmän, toimittajaportaalin ja julkaisukerroksen on keskusteltava keskenään hallitusti. Jos tunnisteet ovat eri järjestelmissä epäjohdonmukaisia, viranomaiset ja myöhempien vaiheiden käyttäjät eivät voi luotettavasti löytää oikeaa passia, ja järjestelmään syntyy päällekkäisiä tai ristiriitaisia tietueita. EU:n standardointityössä pyritään estämään tämä ennen kuin siitä tulee yleinen ongelma. Selkein toteutusmalli on yleensä yksinkertaisin malli, joka sopii tuotteen riskeihin ja monimutkaisuuteen. Liian aikaisin liian monimutkaisen tunnistejärjestelmän rakentavat brändit hidastavat itseään. Liian kevyesti toteuttavat brändit joutuvat korjaamaan rikkoutuneita linkkejä loputtomasti.

Toimittajat hidastavat DPP-ohjelmia yleensä eniten. Se ei johdu siitä, etteivätkö he olisi yhteistyöhaluisia, vaan siitä, että heiltä pyydetään jäsenneltyä dataa, jota heidän ei ole aiemmin tarvinnut toimittaa hallitusti. Jos tukeudut edelleen sähköpostiketjuihin ja taulukkolaskentatiedostojen liitteisiin, jokaisesta päivityksestä tulee manuaalinen siivoustehtävä. Euroopan komission mukaan DPP:t ovat käytettävissä skannaamalla tiedonkantaja, EU:n verkkoportaalin kautta ja verkkomarkkinapaikoilla, mutta käyttöoikeudet vaihtelevat käyttäjäroolin ja sovellettavan lainsäädännön mukaan ([Euroopan komission DPP-pääsyä koskevat usein kysytyt kysymykset].pdf&prefLang=sl)). Tämä on tärkeää, koska et palvele yhtä yleisöä. Kuluttajat, korjaajat, kierrättäjät, tulliviranomaiset ja markkinavalvontaviranomaiset eivät tarvitse samoja kenttiä.

Aloita määrittelemällä määräaikainen pyyntöprosessi. Toimittajien on tiedettävä, mitä tietoja on toimitettava, mihin tuotteisiin pyyntö kohdistuu ja millainen todentavan aineiston muoto hyväksytään. Jos pyyntö on epämääräinen, myös vastaus on epämääräinen. Järjestä tiedonkeruu sen jälkeen kolmeen kanavaan. Yksi kanava jäsennellyille tuotetiedoille, yksi tukiasiakirjoille ja yksi tarkastelua vaativille poikkeamille. Näin ydintietue pysyy siistinä ja tiimeillä on samalla paikka poikkeustapausten hallintaan. Lisää tiedonkeruun jälkeen hyväksyntävaihe ennen kuin mitään julkista tietuetta julkaistaan. Hyväksynnän on oltava kohdennettu. Vaatimustenmukaisuudesta tai tuoteturvallisuudesta vastaava henkilö vahvistaa kentän tietojen hyväksyttävyyden, operatiivinen tiimi varmistaa, että ne vastaavat toimitusta tai erää, ja lakitiimi tarkistaa arkaluonteiset tiedot. Käytännön käyttöönotto etenee yleensä näin: - Pyynnön määrittely: Laadi tuoteryhmittäin kenttäluettelo ja nimeä vastuuhenkilöt sekä määräajat. - Toimittajien tiedonkeruu: Käytä jäsenneltyjä lomakkeita avointen sähköpostiviestien sijaan. - Validointi: Tarkista pakolliset kentät, yksiköt ja liitteiden laatu ennen hyväksymistä. - Hyväksyntä: Ohjaa kyseenalaiset tuoteväitteet ihmisen tarkistettaviksi ennen julkaisemista. - Julkaisu: Vie tuotepassikerrokseen ja siihen yhdistettyihin kanaviin vain hyväksytyt tiedot.

API-yhteyksistä on hyötyä, kun tuotetiedot sijaitsevat jo useissa sisäisissä järjestelmissä. Rajatut käyttöoikeudet, validointisäännöt ja lähtevät ilmoitukset vähentävät tietojen uudelleensyöttöä. QR-koodin luominen auttaa, kun tuotteelle tarvitaan fyysinen yhteyspiste, mutta sen tulee perustua toimivaan identiteettilogiikkaan eikä korvata sitä. Webhookit ovat hyödyllisiä, kun tiedot muuttuvat julkaisun jälkeen. Jos korjauksen tila, omistajuus tai materiaalitiedot muuttuvat, taustajärjestelmien on saatava tieto muutoksesta. Silloin jatkuvan hallinnan merkitys korostuu alkuperäistä julkaisupäivää enemmän. > Käytännön sääntö: suunnittele toimittajien työnkulku niin, että virheellinen tiedosto voidaan hylätä ennen kuin siitä tulee julkinen tuoteväite. Toimivin teknologiakokonaisuus on se, joka vastaa toimintaympäristöäsi. Jos toimittajasi ovat edistyneitä ja sisäiset järjestelmäsi on integroitu, panosta automaatioon syvällisemmin. Jos tietosi ovat edelleen pirstaloituneita, keskity ensin jäsenneltyyn tiedonkeruuseen ja kurinalaiseen hyväksyntäkäytäntöön. Joka tapauksessa tuotepassi toimii vain, jos sitä ympäröivä työnkulku on yhtä kurinalainen.

Oikea ratkaisu ei ole odottaa kaikkien sääntöjen täsmentymistä ennen toimia. Rakenna sen sijaan tuotepassin käyttöönottoon valmis toimintamalli jo nyt ja tarkenna sitä tuoteryhmä kerrallaan, kun velvoitteet täsmentyvät ja tulevat voimaan. Viimeiseen vaiheeseen asti odottavat brändit huomaavat yleensä, että suurin pullonkaula on tietojen siivous, ei sääntely. Käytännön siirtymisen pelikirja alkaa tuotteista, jotka todennäköisimmin kuuluvat soveltamisalaan. Jos myyt paristoja tai akkuja, vuoden 2027 etappi on jo konkreettinen suunnittelun kiintopiste. Jos myyt vaatteita, tekstiilit kuuluvat toimialojen aikajanoissa kuvattuun laajempaan vaiheittaiseen käyttöönottoon ([Circularisen toimialakohtainen aikajana]). Hyödynnä näitä tuoteryhmiä koskevia viitteitä työn priorisointiin, älä sen lykkäämiseen.

1. Kartoita tuotteet, joita asia koskee. Erottele tuotteet todennäköisen tuoteryhmän, tunnistetyypin ja erittelytason mukaan. 2. Luettele kaikki säännellyt kentät. Kirjaa kunkin tuoteryhmän osalta, mitä on julkaistava, mikä vaatii todentavaa aineistoa ja mikä on vielä epävarmaa. 3. Yhdenmukaista tunnisteet. Varmista, että tuotetunnisteet ovat yhdenmukaisia ERP-järjestelmässä, PIM-järjestelmässä, toimittajatietueissa ja julkaisujärjestelmissä. 4. Laita toimittajien tiedonkeruu kuntoon. Korvaa sähköpostipohjainen tiedonkeruu jäsennellyillä pyynnöillä ja tarkistettavilla latauksilla. 5. Testaa tunnisteiden ohjautuminen ja käyttöoikeudet. Varmista, että oikea käyttäjä näkee oikeat kentät oikean käyttöreitin kautta. 6. Pilotoi yksi tuoteperhe. Käytä rajattua käyttöönottoa työnkulkuongelmien esiin tuomiseen ennen laajentamista. 7. Nimeä hallinnasta vastaava omistaja. Anna yhdelle tiimille toimivalta tietojen tarkkuudesta, hyväksynnöistä ja elinkaaripäivityksistä. 8. Seuraa jatkuvasti. Käsittele tuotepassia jatkuvasti päivittyvänä tietueena, ei kertaluonteisena käyttöönottoprojektina.

Ennen julkaisemista kysy, kestääkö tuotepassi toimittajan vaihdoksen, luettelopäivityksen ja käyttäjäroolin muutoksen. Jos vastaus johonkin näistä on ei, tietue vaatii lisätyötä. Tämä on todellinen testi, sillä tuotepassin on pysyttävä täsmällisenä pitkään sen jälkeen, kun julkaisukokous on päättynyt. Yleinen epäonnistumismalli on käynnistää toiminta liian monien manuaalisten poikkeusten varassa. Toinen on se, että vastuu hajautetaan tiimeille, jotka eivät jaa yhtä totuuden lähdettä. Molemmat ongelmat ovat korjattavissa, mutta vain, jos brändi käsittelee DPP-valmiutta siirtymäohjelmana, jolla on vastuuhenkilöt, määräajat ja tarkistuspisteet.

EU:n digitaalinen tuotepassi ei ole yksittäinen tiedosto eikä pelkkä vastuullisuusmerkki. Se on tuotetunnistejärjestelmä, joka pakottaa brändit järjestämään tiedot, todentavan aineiston, käyttöoikeuksien hallinnan ja omistajuuden yhteen paikkaan. Yritykset, jotka tekevät tämän hyvin, ovat paremmin valmistautuneita vaatimustenmukaisuuteen, pystyvät vastaamaan paremmin jäljitettävyyttä koskeviin kysymyksiin ja ovat paremmassa asemassa korjaus- ja jälleenmyyntiprosessien kehittämisessä. Keskeiset toimet ovat selvät. Ymmärrä tuoteryhmän soveltamisala, kartoita säännellyt kentät, yhdenmukaista tunnisteet, laita toimittajien tiedonkeruu kuntoon ja testaa käyttöoikeudet ennen käyttöönottoa. Jos käsittelet edelleen passitietoja pelkkänä asiakirjojen latausongelmana, olet jo jäänyt toiminnallisesta kehityksestä jälkeen. Aloita yhdestä tuoteperheestä, yhdestä näyttömallista ja yhdestä nimetystä vastuuhenkilöstä ja laajenna siitä. --- Toimintakehotus: DPP Grid.