Могa ли да свържа продуктовия паспорт със своята ERP или система за управление на запасите?

Свързването е възможно, при условие че данните се предоставят по структуриран начин

Свързването на цифров пасспорт на продукт към ERP система или система за управление на запасите е в основата възможно, тъй като ESPR предписва, че цифровият пасспорт на продукта трябва да бъде технически построен по такъв начин, че обменът на данни да протича с интероперабилност и да е четлив от машини (член 11 на ESPR, Регламент (EU) 2024/1781). Това означава, че данните, които вече се намират в ERP система или система за управление на запасите — състав на материали, произход, компоненти, номера на партиди или сериални номера — в принцип могат да бъдат източникът, от който се изгражда пасспортът. Свързването тогава не е в преки живи връзки между две системи, а в факта, че едни и същи данни, които вътрешно вече се отчитат, се предоставят в подходящ формат за пасспорта.

За кои данни това работи и за кои не

Това касае данни, които вече са зафиксирани някъде и са релевантни за пасспорта на конкретен продукт: технически спецификации, информация за материали, данни за ремонт и обслужване, или информация за произход. За този вид данни структурираното предоставяне от съществуваща система е логично. Не се касае за обща, постоянна системна интеграция, която се предписва от ESPR — регламентът не задължава никой производител или вносител да използва конкретна технология, API или софтуерен пакет. Член 11 се отнася до технологията на самия пасспорт: как са организирани носителят на данни, регистърът и достъпът до данни. Той не определя как една компания организира или експортира собствената си ERP система. Също важно: кои точно данни трябва да се намират в пасспорта, варира по групи продукти и се разработва отделно за всяка група продукти чрез преносен акт. Това, което е релевантно ERP поле за един продукт (например процент на материал), може да не е приложимо за друга група продукти.

Техническите изисквания вече действат, но запълването на конкретни продуктови групи все още не е навсякъде

Самият ESPR, с общите изисквания към цифровия пасспорт на продукта (член 10) и неговата техническа организация (член 11), е установен и е на основата, в рамките на която всеки пасспорт на продукта трябва да функционира в бъдеще. Кога конкретен продукт наистина ще има нужда от пасспорт и кои точно данни трябва да се съдържат в него, се решава отделно за всяка група продукти. За много групи продукти това разработване все още не е публикувано или все още не е в сила. До момента, когато за една група продукти е установено кои данни са задължителни, няма конкретна задължение да се организира интеграция или поток от данни от ERP система — но е полезно вече да знаете откъде могат вътрешно да дойдат релевантните данни, за да не е необходимо да се започна от нула при старта на едно задължение.

Как се решава това в практиката

Първата стъпка е да проверите какви данни в вашата ERP или система за инвентар вече са налице и са свързани с това, което типично съдържа едно удостоверение: идентификация на продукта, състав на материалите, произход, компоненти, информация за гаранция или ремонт. След това е целесъобразно да разгледате как тези данни могат да бъдат експортирани от системата — като файл, като доклад, или чрез структурирана връзка — в форма, която е четима и преносима, в съответствие с отворената и взаимосвързаната структура, която член 11 предписва за удостоверението. Впоследствие е важно да свържете данните с уникалния идентификатор на продукта, който удостоверението изисква според член 10, така че всяко удостоверение да е доказуемо свързано с правилния продукт. Тъй като удостоверението трябва да остане актуално през целия жизнен цикъл на продукта, е практично да помислите и за повтарящ се процес: как една промяна в ERP системата (например адаптиран компонент или нов доставчик) се прилага към удостоверението в даден момент. Това не трябва непременно да бъде в реално време — периодично подаване, например при адаптации или нова производство, обикновено работи перфектно в повечето случаи. Платформа, която събира удостоверения от подадени данни, както prodpas.eu, обикновено получава тези данни точно по този начин: като структурирано подаване от съществуващата администрация на производител или вносител, не като постоянна пряка връзка между две системи.

Откъде следва това: членове 10 и 11 на ESPR

Задължението за взаимосвързаност и четимост от машини на цифровото удостоверение за продукт е предписано в член 11 на ESPR (Регламент (EU) 2024/1781), който регулира техническата структура и функционирането на удостоверението. Член 10 на същия регламент описва общите изисквания, на които трябва да отговаря едно удостоверение, включително връзката с уникален идентификатор на продукта. Заедно тези членове формират основата, поради която първоначалните данни от съществуваща система, при условие че са структурирано подадени, могат да бъдат подходящи като вход за удостоверение — без регламентът да предписва каква техника или каква система едно предприятие използва вътрешно за това.

Кой сега иска да се подготви предварително, може най-добре да започне с преглед на това кои данни за продукта стоят във вашата ERP или система за инвентар и в какъв формат те могат да бъдат експортирани. Веднага след като за вашата собствена група продукти е ясно кои данни трябва да съдържа едно удостоверение, подаването от съществуващата администрация обикновено е практичната начална точка.