Kiek kainuoja produkto pasas?

Ką konkrečiai turėtumėte daryti

Ko iš jūsų tikimasi

ESPR (Reglamentas (ES) 2024/1781) 9 straipsnyje numato, kad produkto pasas turėtų būti, kas jame turėtų būti ir kaip jis turėtų būti prieinamas per duomenų nešiklį. Tai, ko reglamentas nedaro, yra kainų nustatymas. Tekste nėra nei tarifų, nei atskaitos sumos, nei išlaidų viršutinės ribos. Tai reiškia, kad "kiek tai kainuoja" nėra klausimas, į kurį atsakytų įstatymų leidėjas — tai klausimas, kuris kiekvienai įmonei ir kiekvienai produktų grupei yra kitoks, priklausomai nuo to, kokie duomenys ir sistemos jau turimi. Tai, ką galima aprašyti: kokie įsipareigojimai sukelia išlaidas ir kur tos išlaidos paprastai atsiranda.

Surinkite ir suorganizuokite duomenis

Produkto pasas susideda iš duomenų: medžiagų, kilmės, remonto galimybių, atitikties ir to, ką reikalauja atitinkama produktų grupė. Įmonei su 10–100 darbuotojų pirmoji išlaidų pozicija beveik visada yra čia: ne pačiame pasporte, bet tame, kad tie duomenys dažnai yra išsibarstę po nusipirkimą, kokybės užtikrinimą ir kartais pas tiekėją. Tų duomenų paieška ir patvirtinimas yra darbas, kuris turi būti atliktas išsamiai vieną kartą, o vėliau – prižiūrimas. Kas čia pradeda pirm nei jų produktų grupė bus eilėje, tas išskleidžia tą išlaidą per ilgesnį laiką — žr. Ar protinga pradėti prieš mano produktų grupei atėjus eilei?

Duomenų nešiklį ir serverio paslaugą sutvarkykite

9 straipsnis reikalauja QR kodo arba panašaus nešiklio, kuris nukreiptų į produkto paso duomenis, o duomenys turi būti prieinami per nustatytą laikotarpį. Tai reiškia dvi atskiras sąnaudų kategorijas: nešiklio sukūrimą pagal produktą (arba pagal variantą) ir duomenų serverio paslaugą per kelias metų. Įmonė, norinti tai pati kurti techniškai, moka daugiausia programavimo laiko ir priežiūros sąnaudas; įmonė, kuri tai išduoda užsakovu, moka už produktą arba prenumeratą. Kai yra keli to paties produkto variantai, iškyla klausimas, ar pakanka vieno paso, ar ne — žr. ar galiu naudoti produkto pasą kelioms to paties produkto variantams, nes tai tiesiogiai sumažina turėtinų sukurti ir prižiūrėti pasportų skaičių.

Nuolat atnaujinti laikui bėgant

Pasportas nėra momentinis vaizdas. Remontai, sudėties pakeitimai arba naujas atitikties statusas turi būti jame atsispindėti. Tai yra nuolatinė išlaidų pozicija, ne vienkartinė. Įmonei su ribotu produktų linijų skaičiumi tai yra lengvai suprantama; įmonei su daugybe variantų ir dažnais pakeitimais tai greitai gali viršyti pačią pradinę sąmatą.

Darbuotojai, kurie turi su tuo dirbti

Pareiga neapsiriboja tik sistemas, bet ir žmones: kas organizacijoje užtikrina, kad naujus produkto duomenis patektų į pasportą, kas patikrina, ar pasportas yra teisingas prieš išleidžiant produktą. Tai yra organizacinės išlaidos, kurios lengvai pamiršamos biudžete, kuris žvelgia tik į techniką. Žr. kaip paruošti savo darbuotojus darbui su produkto pasu dėl to, ką ta paruošti praktikoje reiškia.

Kur praktikoje susiduriama su problemomis

Pirmoji situacija: įmonė prašo pasiūlymo remiantis "vienu pasportu per produktą" neatsižvelgdama į variantus ir vėliau atkleidžia, kad pasportų skaičius yra tris ar keturis kartus didesnis nei buvo planuota.

Antroji: duomenų rinkimo išlaidos yra nepakankamai įvertintos, nes jos viduje yra rūšiuojamos kaip "įprastas kokybės ar pirkimų darbas", dėl kurio bendras diegimo vaizdas niekur nebeakyvaizdu.

Trečia: hosting yra traktuojamas kaip vienkartinė išlaida, tačiau įpareigojimas reikalauja prieinamumo ilgesniam laikotarpiui — todėl po kelių metų įmonė susiduria su nenumatytu papildomu sąskaitu, arba dar blogiau, su pasaportu, kuris nebėra prieinamas.

Ketvirtoji: investuojama į techninę sprendimą, kol dar nėra aišku, ar pati produktų kategorija apskritai patenka į įpareigojimą, ar kokie tiksliai reikalavimai toje kategorijoje taikomi — žr. Ar skaitmeninis produkto pasas taikomas mano produktams? Pinigus skirti neteisingai specifikacijai yra išlaidų straipsnis, kurio lengvai galima išvengti atsakant į šį klausimą pirmiausia.

Penktoji: įmonės delsia su bet kokiais investicijomis, kol jų produktų kategorijos taisyklės yra galutinės, ir tada trumpu laiku turi užpildyti tai, kas būtų buvę pigesne dalis ilgesniam laikotarpiui. Žr. taip pat Ką galiu daryti dabar, kol taisyklės dar nėra galutinės?

Ką galite užfiksuoti

• Produkto grupių ir variantų, kurie patenka į prievolę, ir kurie dar nepatenka — apžvalga, skirta realistiškam išlaidų vertinimui.
• Reikalingų duomenų šaltinių (pirkimas, kokybė, tiekėjai) inventorizacija ir nustatymas, kokių duomenų trūksta arba turi būti patvirtinti.
• Pasirinkimas tarp savadarbės ir savihosting arba subrangos, su aiškiai išdėstyta išlaidu struktūra (vienkartinės versus nuolatinės) šalia viena kitos.
• Susitarimai dėl to, kas organizacijoje yra atsakingas už produkto paso informacijos aktualumą, įskaitant laiką, kada produkto pasikeitimas turi lemti paso pasikeitimą.
• Bandomoji sąranka prieš įsigaliojant prievolei jūsų produkto grupei, kad būtų matyti techniniai trūkumai ir nesuvertinti išlaidu straipsniai — prieš tai, kai jų sprendimas tampa privalomas — žr. ar galiu iš anksto sukurti produkto paso testinę versiją
• Įgyvendinimo veiksmų planas, kad išlaidos būtų matomos etapais, o ne iš karto po to — žr. Kaip žingsnis po žingsnio pradėti produkto pasą?

Kiek tiksliai kainuoja produkto pasas, nėra klausimas, kuriems galima atsakyti vienu skaičiumi — ne todėl, kad atsakymas paslėptas, bet todėl, kad pati reguliavimas nesiremia konkrečia suma, o praktika skiriasi kiekvienam įmonei. Tačiau tai, ką galima aprašyti ir ką įmonė gali kontroliuoti, yra sprendimai, kurie lemia išlaidas: kiek variantų, kiek savadarbės veiklos ir subrangos, ir kada pradedama tvarkytis su pagrindine duomenimis.