Събиране на данни за DPP от доставчици: скритото тясно място

Каква част от един DPP реално идва от доставчици

За паспорт на батерия, от 91-те задължителни полета, приблизително 47 произлизат извън компанията ви: доставчикът на клетки осигурява химията, декларациите за опасни вещества и кривите на вътрешното съпротивление; доставчиците на суровини за катод/анод предоставят произход и доказателства за due diligence за кобалт, литий, никел и естествен графит; доставчикът на електролит осигурява SDS. За текстилен DPP пропорциите са подобни, но на повече нива — красилен цех, текстилна мелница, предачница, производител на влакна — всеки с по две-три полета, които само той може да осигури.

Правило на палеца: 40–70% от данните в един DPP съществуват нагоре по веригата спрямо икономическия оператор. Ако планът на вашия DPP проект няма тримесечен блок за контакти с доставчици, планът е грешен.

Защо е по-трудно от работен процес с таблици и имейли

Наивният подход — да изпратите на всеки доставчик 30-страничен Excel шаблон — изглежда разумен на първия ден и се срива към третата седмица. Четири причини да не работи в мащаб:

• Доставчиците на ниво 2 и 3 не знаят, че клиентът на клиента им е обхванат от EU DPP. Те виждат непознат формуляр, го депритизират и регулаторният ви отдел започва да пише студени имейли на език, на който доставчикът не работи.
• Данните съществуват — в записи за контрол на качеството, PDF тестови протоколи, експорти от системи на доставчици — но не във формата, който вашият формуляр изисква. Доставчик с всичко необходимо може пак да отговори „нямаме това“, защото преводът на вътрешната му таксономия към вашия формуляр е ден работа.
• Доказателството е PDF, не стойност. EU DPP изисква връзки към доказателства (тестови протоколи, EPD, SDS файлове, сертификати за съответствие). Поле за „въведете % рециклирано съдържание“, без да поиска PDF, който да го докаже, е непълно — а поле, което иска и двете, е двойно повече триене.
• Процентът на отговори на студени имейли от типа „моля, попълнете формуляра“ обикновено е 15–25%. Гоненето на останалите 75% отнема повече време от първоначалната комуникация.

Как всъщност изглежда 16-седмичният имейл процес

Седмица 1–2: идентифициране на доставчици, съставяне на заявката, превод на три езика, прикачване на шаблона. Седмица 3: изпращане. Седмица 4: гонене на тези, които не отговарят. Седмица 5–6: трииране на първите 8 отговора — половината са непълни, един е в напълно грешен формат (PDF с ръкописни бележки). Седмица 7–10: ново гонене, съгласуване на несъвместими единици (kWh срещу Wh, kg срещу g, % срещу съотношение), въпроси за уточнение. Седмица 11–14: втора вълна на гонене за прикачени доказателства (формулярът имаше стойност, но без PDF). Седмица 15: QA проверка — хващане на доставчика, който е използвал SVHC списъка от 2022 г. вместо текущия. Седмица 16: подаване на изчистените данни в паспорта. Току-що сте използвали целия календарен бюджет за това, което е планирано като двуседмична задача.

Какво съкращава цикъла

Четири промени в процеса вършат по-голямата част от работата:

• Достъп с токен, без регистрация. Доставчикът кликва на уникален линк в имейла си и попада на предварително попълнен формуляр за конкретния му материал. Без акаунт за създаване, без парола за забравяне, без одобрение от IT отдел. Процентът на отговори скача от ~20% на 60–70%.
• Езикът на доставчика по подразбиране. Разпознайте държавата на доставчика от метаданните за контакт, рендирайте формуляра на неговия език, автоматично превеждайте полетата. Китайски QC мениджър в клетъчна фабрика е 5× по-склонен да попълни формуляр на китайски, отколкото на английски.
• PDF влиза, стойности излизат. Позволете на доставчика да качи документа, който вече има (техническа спецификация, тестов протокол, SDS), и извлечете стойностите автоматично, вместо да го карате да ги препечатва. „Качете този SDS“ е 10-секундна молба; „препишете 14-те полета на страница 3 от този SDS в моята таблица“ е 20-минутна.
• Живо табло за регулаторния ви отдел, показващо състоянието на отговора на всеки доставчик. Спира седмичния имейл ритуал „от кого не сме чули“. Прави ясно къде да похарчите бюджета за гонене.

На какво всъщност отговарят доставчиците

Повечето студени запитвания към доставчици се провалят, защото рамката е грешна, а не защото доставчикът не желае. Представете си, че управлявате контрол на качеството в литиева клетъчна фабрика в Корея: получавате по 30 имейла на ден от компании-купувачи, половината от които искат данни в несъвместими формати. Непознат 30-страничен Excel шаблон от марка, за която едва сте чували, попада някъде между дъното на купчината и кошчето. Моделите, които реално повишават процента на отговори от 20% на 60–70%:

• Започнете с регламента, не с формуляра. „Регламент (ЕС) 2023/1542 за батерии изисква да публикуваме вашето X до февр. 2027 г.“ действа по-силно от „моля, попълнете този шаблон“. Регулаторният отдел на доставчика може да действа по първото; обучителният, който чете второто, трябва да го ескалира.
• Стеснете заявката до ТЕХНИЯ продукт, не до целия ви схема. Ако доставчикът предоставя 4 от 91-те полета, поискайте точно тези 4 с предварително попълнени имена на продукти. Запитване за целите 91 кани отговори от типа „това не е наше“.
• Направете крайния срок реален и споделен. „Имаме нужда от това до 30 март, защото подаването ни за одобрение на типа е на 18 април“ пътува по-добре по веригата, отколкото „възможно най-скоро“.
• Предложете малка реципрочна стойност: копие на публикувания паспорт, извадка от методологията за въглероден отпечатък, която сте използвали, или сертификат, доказващ надлежна проверка. Нищо трансформиращо; просто достатъчно заявката да изглежда като двупосочна.

Когато доставчикът пита ВАС

Половината SaaS литература третира събирането на DPP данни от доставчици като еднопосочна улица: марката пита, доставчикът предоставя. На практика всеки икономически оператор е надолу по веригата спрямо някого и нагоре спрямо друг. Същата текстилна мелница, която събира данни за произхода на памука от своя доставчик на прежди, бива питана за състав на тъканите от своя клиент-марка на облекло. Същият производител на батерийни пакети, който гони данни за химията на клетките от Корея, бива питан за данни за производителността на пакета от EV OEM, който пуска превозното средство на пазара на ЕС.

Две практически импликации: първо, данните, които събирате от доставчиците си, обикновено могат да бъдат препубликувани чисто към клиента надолу по веригата с минимални допълнителни усилия — същите полета, същият формат. Второ, регулаторният отдел на клиента ви надолу по веригата минава през абсолютно същото, през което минавате и вие. Ако можете да им предоставите данните си чрез портал с токен на техния език, спестявате 12 седмици имейл нишки и те ще ви благодарят. Платформите, които печелят дългата игра, са тези, които правят това двустранно.

Често срещани грешки в процеса

Грешки, които съм виждал да се повтарят в около двадесет внедрявания на DPP в различни категории:

• Третиране на първото внедряване на DPP като проект, а не като оперативна способност. Първите 5 SKU са проект; следващите 500 — и тези, които всеки месец излизат на пазара след това — имат нужда от процесен собственик, а не от Гант диаграма.
• Оставяне на маркетинга да съставя имейлите към доставчиците. Маркетингът оптимизира за ангажираност; регулаторният отдел на доставчика чете ангажираността като пух и я изхвърля. Гласът на регулаторен или качествен екип конвертира при около 3 пъти по-висок процент.
• Без специализиран имейл адрес. Изпращането от лично name@yourcompany.com се филтрира като спам от MTA-тата на доставчиците от ниво 2/3. Използвайте специализиран dpp@ или compliance@ alias с конфигурирани SPF + DKIM записи. Половината от случаите „доставчикът не отговори“ всъщност са „доставчикът никога не го е получил“.
• Запитване за данни, които регламентът не изисква. Регулаторните отдели добавят приятни-за-има към запитването, защото порталът за доставчици го позволява. Всяко излишно поле сваля процента на отговори с 5–10%.
• Невъзможност да се отдели чернова от одобрени данни. Паспорт със стойности от 12 различни рецензенти, нито една от които не е маркирана като одобрена-от-X, не е одитируем. Най-простото решение: статусен флаг за поле — `чернова`, `одобрено`, `маркирано` — с ID на рецензента, печатан върху всеки преход. Органите в крайна сметка ще питат.