Digital Product Passport: แบรนด์ไทยต้องเตรียมข้อมูลสินค้าอย่างไร ก่อนส่งออกสหภาพยุโรป

DPP คือโครงสร้างข้อมูลของสินค้า ไม่ใช่แคมเปญ QR Code

คณะกรรมาธิการยุโรปอธิบาย Digital Product Passport ว่าเป็นภาชนะดิจิทัลสำหรับสินค้า ชิ้นส่วน และวัสดุ ซึ่งเก็บข้อมูลที่เกี่ยวข้องเพื่อสนับสนุนความยั่งยืน การหมุนเวียนทรัพยากร และการปฏิบัติตามกฎหมาย ผู้บริโภค ผู้ซ่อม ผู้รีไซเคิล ธุรกิจ และหน่วยงานรัฐจะเห็นข้อมูลต่างกันตามบทบาทและสิทธิ์ จึงไม่ควรตีความ DPP ว่าเป็น Landing Page การตลาดหนึ่งหน้า หรือไฟล์ PDF ที่ทุกคนเปิดเห็นเหมือนกัน

เส้นทางทำงานเริ่มจากผู้ประกอบการรวบรวมข้อมูลตามกฎหมายที่ใช้กับสินค้าของตน สร้างและลงทะเบียน DPP แล้วผูกกับ Data Carrier เช่น QR Code บนสินค้า บรรจุภัณฑ์ หรือเอกสารประกอบ ระบบ Registry เก็บตัวระบุเฉพาะและข้อมูลทะเบียนที่จำเป็น ขณะที่ข้อมูลผลิตภัณฑ์ฉบับเต็มจัดเก็บแบบกระจายโดยผู้ประกอบการหรือผู้ให้บริการ DPP เมื่อสแกนแล้ว ผู้ใช้แต่ละกลุ่มจึงเข้าถึงเฉพาะข้อมูลที่เกี่ยวข้อง

ความต่างจาก QR Code ทั่วไปอยู่ที่ความเป็นระบบและความต่อเนื่อง รหัสต้องเชื่อมกับตัวตนสินค้าที่ไม่คลุมเครือ ข้อมูลต้องเป็นปัจจุบัน อ่านได้ด้วยเครื่อง แลกเปลี่ยนกับระบบอื่นได้ และคงอยู่ตามช่วงเวลาที่กฎหมายกำหนด หาก QR Code พาไปหน้าเว็บที่เปลี่ยน URL บ่อย ไม่มี Version หรือไม่รู้ว่าข้อมูลเป็นของรุ่น ล็อต หรือชิ้นใด ก็ยังไม่ใช่รากฐาน DPP ที่พร้อมใช้งาน

สถานะล่าสุด: Registry เปิดแล้ว แต่การบังคับใช้ทยอยตามประเภทสินค้า

เมื่อ 20 กรกฎาคม 2026 คณะกรรมาธิการยุโรปเปิด DPP Registry พร้อมสภาพแวดล้อมทดสอบ ผู้ประกอบการสามารถลงทะเบียนผ่านหน้าจอที่ปลอดภัยหรือ API และขอหลักฐานการลงทะเบียนในรูปเอกสารอิเล็กทรอนิกส์ได้ ระบบยังมี Semantic Repository สำหรับโมเดลข้อมูล คำจำกัดความ และคำศัพท์ที่เครื่องอ่านได้ รวมถึงกลไกตรวจสอบและบันทึกเหตุการณ์เพื่อสนับสนุนความปลอดภัยและความรับผิดชอบ

อย่างไรก็ดี วันที่ Registry เปิดไม่ใช่วันบังคับใช้ร่วมของสินค้าทุกชนิด เว็บไซต์ DPP ทางการของ EU ระบุว่ากฎหมายเฉพาะของแต่ละกลุ่มจะกำหนดรายละเอียดและกำหนดเวลา โดยหลัง Delegated Act ภายใต้ ESPR ประกาศ ผู้ประกอบการจะมีช่วงเปลี่ยนผ่านอย่างน้อย 18 เดือนตามกรอบที่ระบุ หมุดหมายแรกคือวันที่ 18 กุมภาพันธ์ 2027 ซึ่ง DPP จะบังคับกับแบตเตอรี่บางประเภท ได้แก่ แบตเตอรี่รถยนต์ไฟฟ้า แบตเตอรี่สำหรับยานพาหนะขนาดเบา และแบตเตอรี่อุตสาหกรรมตามขอบเขตกฎหมาย

แผนปัจจุบันระบุกรอบการออกข้อกำหนดสำหรับเหล็กและเหล็กกล้าในปี 2026 สิ่งทอ อะลูมิเนียม และยางรถยนต์ในปี 2027 เฟอร์นิเจอร์ในปี 2028 และที่นอนกับข้อกำหนดบางด้านในปี 2029 กรอบเหล่านี้เป็นกำหนดการเชิงบ่งชี้และอาจเปลี่ยนตามการประกาศจริง ผู้ส่งออกไทยจึงต้องติดตามกฎหมายเฉพาะของ Product Group, HS Code, บทบาทในห่วงโซ่ และเงื่อนไขของผู้นำเข้าหรือ Marketplace ไม่ควรใช้ Timeline จากบทความทั่วไปแทนการตรวจฉบับกฎหมายล่าสุด

ใครในธุรกิจไทยควรเริ่มเตรียมก่อน

กลุ่มที่ควรเริ่มก่อนคือผู้ผลิต เจ้าของแบรนด์ OEM ผู้ส่งออก และซัพพลายเออร์ที่เกี่ยวข้องกับแบตเตอรี่ เหล็กและเหล็กกล้า อะลูมิเนียม สิ่งทอ ยางรถยนต์ เฟอร์นิเจอร์ ที่นอน ICT อิเล็กทรอนิกส์ และสินค้าที่ใช้วัสดุเหล่านี้ในสัดส่วนสำคัญ แม้บริษัทจะไม่ได้ขายตรงถึงผู้บริโภคในยุโรป ผู้นำเข้าหรือแบรนด์ปลายทางอาจขอข้อมูลจากโรงงานไทยเพื่อจัดทำ DPP ของสินค้าสำเร็จรูป

คำถามแรกไม่ใช่ “ต้องซื้อแพลตฟอร์มอะไร” แต่คือ “เราเป็นใครในห่วงโซ่ของสินค้านี้” ระบุผู้ผลิตตามกฎหมาย เจ้าของเครื่องหมายการค้า ผู้นำเข้า ผู้แทนใน EU ผู้ประกอบการที่วางสินค้าในตลาด และผู้ที่รับผิดชอบสร้างหรืออัปเดตข้อมูล หากหน้าที่ไม่ชัด ทีมไทยอาจส่งไฟล์ให้คู่ค้าซ้ำหลายรอบ แต่ไม่มีใครรับรองว่าข้อมูลชุดใดเป็นฉบับอนุมัติ

จากนั้นทำ Scope Matrix ต่อ Product Family โดยบันทึกตลาดปลายทาง ประเภทสินค้า กฎหมายหลัก กฎหมายเฉพาะ ระดับรหัสที่คาดว่าจะใช้ ผู้ขอข้อมูล เจ้าของข้อมูลภายใน แหล่งหลักฐาน และวันทบทวน ช่องว่างที่พบบ่อยคือชื่อวัสดุคนละแบบระหว่างฝ่ายจัดซื้อกับฝ่ายออกแบบ น้ำหนักส่วนประกอบรวมไม่ครบ 100% เอกสารรับรองหมดอายุ และข้อมูลรุ่นในเว็บไซต์ไม่ตรงกับฉลากจริง การเห็นช่องว่างเหล่านี้เร็วมีค่ากว่าการสร้างหน้า DPP ที่สวยแต่พิสูจน์ไม่ได้

สร้าง Product Data Foundation ห้าชั้น

ชั้นแรกคือ Identity: รหัสผลิตภัณฑ์ รุ่น ล็อตหรือ Serial เจ้าของข้อมูล โรงงาน ประเทศ และวันที่ผลิต ชั้นที่สองคือ Composition: วัสดุ ส่วนประกอบ สารที่ต้องติดตาม ปริมาณและแหล่งที่มา ชั้นที่สามคือ Compliance: มาตรฐาน ผลทดสอบ ใบรับรอง คำประกาศ และ Version ชั้นที่สี่คือ Circularity: อายุใช้งาน วิธีดูแล ซ่อม ถอด ใช้ซ้ำ รีไซเคิล และจัดการเมื่อหมดอายุ ชั้นที่ห้าคือ Lifecycle & Access: ประวัติการเปลี่ยนแปลง สถานะสินค้า ผู้มีสิทธิ์เห็นข้อมูล และระยะเวลาที่ต้องเก็บ

ทุก Field ควรมีชื่อ นิยาม หน่วย รูปแบบข้อมูล ระดับที่ใช้ เช่น Model, Batch หรือ Item เจ้าของ ผู้อนุมัติ แหล่งหลักฐาน ความถี่อัปเดต และสถานะการเปิดเผย นี่คือ Product Data Dictionary ที่ช่วยให้คำว่า “วัสดุรีไซเคิล” หรือ “ประเทศต้นกำเนิด” มีความหมายเดียวกันทั้ง ERP, PLM, PIM, เว็บไซต์ ฉลาก และไฟล์ของคู่ค้า หากยังไม่มีระบบใหญ่ สามารถเริ่มด้วยตารางควบคุมที่มีสิทธิ์เข้าถึงและ Version ก่อน แต่ต้องหลีกเลี่ยงไฟล์แยกหลายชุดที่ไม่มี Source of Truth

ให้ทำ Evidence Link ต่อข้อมูลสำคัญ เช่น เลขที่ใบรับรอง รายงานทดสอบ Bill of Materials เอกสารซัพพลายเออร์ หรือวิธีคำนวณ พร้อมวันที่และผู้อนุมัติ หลักฐานไม่จำเป็นต้องเปิดสู่สาธารณะทั้งหมด แต่ทีมต้องย้อนกลับได้ว่าค่าหนึ่งมาจากไหน เปลี่ยนเมื่อไร และใครรับผิดชอบ วิธีนี้เชื่อม DPP กับหลัก Evidence Chain เดียวกับการป้องกัน Greenwashing และลดความเสี่ยงเมื่อข้อมูลเว็บไซต์ บรรจุภัณฑ์ หรือข้อเสนอขายขัดกัน

• กำหนด Unique Identifier และระดับข้อมูลให้ชัดว่าเป็น Model, Batch หรือ Item
• ทำ Data Dictionary ก่อนออกแบบหน้าจอหรือเลือกผู้ให้บริการ
• เชื่อมทุก Claim สำคัญกับหลักฐานและผู้อนุมัติที่ตรวจสอบย้อนหลังได้
• แยก Public, Partner, Authority และ Restricted Data ตั้งแต่ต้น

ออกแบบประสบการณ์แบรนด์โดยไม่ทำลายการทำงานของ DPP

DPP สามารถสร้างความเชื่อมั่นได้ หากข้อมูลทางการอ่านง่ายและเชื่อมกับประโยชน์ของผู้ใช้ เช่น แหล่งที่มาของวัสดุ วิธีดูแลให้ใช้นาน จุดซ่อม อะไหล่ วิธีคืนสินค้า และการรีไซเคิล แต่หน้าสาธารณะต้องไม่กลบข้อมูลบังคับด้วย Animation หนัก Pop-up หรือข้อความโฆษณาเกินจริง ผู้ใช้ควรเห็นชื่อสินค้า รุ่น สถานะข้อมูล และวันที่อัปเดตทันที พร้อมเข้าถึงภาษาและระดับรายละเอียดที่เหมาะสม

แยก Compliance Layer ออกจาก Brand Experience Layer อย่างชัดเจน ชั้นแรกดูแลโครงสร้างข้อมูล Identifier, Access Control, API, Version และหลักฐาน ชั้นที่สองดูแลภาษา ภาพ ลำดับเนื้อหา Accessibility และเส้นทางไปยังบริการหลังการขาย ทั้งสองชั้นใช้ข้อมูลต้นทางเดียวกัน การแยกนี้ช่วยให้ทีม Creative ปรับประสบการณ์ได้โดยไม่เปลี่ยนความหมายทางกฎหมาย และช่วยให้ระบบอื่นเรียกข้อมูลได้แม้หน้าเว็บถูกออกแบบใหม่

เว็บไซต์องค์กรควรมีหน้าศูนย์กลางอธิบายการตรวจสอบข้อมูลสินค้าและนโยบายอัปเดต แต่ไม่ควรสร้างหน้าสาธารณะที่ Search Engine พบได้สำหรับทุกข้อมูลโดยอัตโนมัติ เพราะ DPP บางส่วนมีสิทธิ์จำกัดและอาจมีข้อมูลเชิงพาณิชย์ จัด Canonical เฉพาะหน้าสาธารณะที่ตั้งใจให้ค้นพบ ใช้ข้อความ Alt ที่อธิบายภาพสินค้าอย่างถูกต้อง ตรวจ Keyboard และ Mobile และอย่าใส่ข้อมูลในภาพแทนข้อความที่เครื่องอ่านต้องใช้

หลีกเลี่ยงห้าความผิดพลาดที่ทำให้โครงการต้องรื้อใหม่

ข้อผิดพลาดแรกคือเริ่มจาก QR Code แล้วค่อยตามหาข้อมูล ข้อสองคือคัดลอกคำอธิบายการตลาดมาเป็นข้อมูลทางเทคนิค ข้อสามคือใช้ SKU เดียวครอบคลุมสินค้าหลาย Version ข้อสี่คือเปิดข้อมูลทั้งหมดหรือปิดทั้งหมดโดยไม่แยกบทบาท และข้อห้าคือผูกระบบกับผู้ให้บริการรายเดียวจนย้ายข้อมูลไม่ได้ ESPR ให้ความสำคัญกับความสามารถในการทำงานร่วมกันและการแลกเปลี่ยนผ่านเครือข่ายแบบเปิด จึงควรถามเรื่อง Export, API, Data Ownership, Backup และ Exit Plan ตั้งแต่ก่อนเซ็นสัญญา

อีกความเสี่ยงคือการประกาศว่า “พร้อม DPP” ทั้งที่กฎหมายเฉพาะของสินค้าและ Data Model ยังไม่สิ้นสุด คำที่ปลอดภัยกว่าในช่วงเตรียมคือ “จัดทำโครงสร้างข้อมูลเพื่อรองรับ DPP” พร้อมระบุขอบเขตที่ทดสอบแล้ว อย่าใช้ตรา EU หรือภาพที่ทำให้เข้าใจว่าได้รับการรับรองหากไม่มีฐานทางกฎหมาย และอย่านำข้อมูลจากซัพพลายเออร์มาเผยแพร่โดยไม่ตรวจสิทธิ์ ความถูกต้อง และช่วงเวลาที่อ้างอิง

กำหนด Quality Gate ก่อนเผยแพร่ DPP ทุกฉบับ ได้แก่ Identifier ไม่ซ้ำ ข้อมูลบังคับครบ หลักฐานเปิดได้ วันที่และ Version ตรงกัน สิทธิ์เข้าถึงถูกต้อง QR ทนต่อการพิมพ์และสภาพใช้งาน ลิงก์ไม่พึ่ง Session หน้าสาธารณะรองรับ Mobile และ Accessibility ระบบเก็บ Log และมีเจ้าของรับ Incident หากข้อใดไม่ผ่าน ให้คงสถานะ Draft แทนการปล่อยข้อมูลที่สร้างความเสี่ยงให้ทั้งแบรนด์และคู่ค้า

แผนเตรียมความพร้อม 90 วันสำหรับแบรนด์และผู้ส่งออกไทย

วันที่ 1–30 ทำ Regulatory & Product Scope ระบุสินค้าที่ส่ง EU บทบาทของบริษัท คู่ค้า และกฎหมายที่เกี่ยวข้อง เลือก Pilot หนึ่ง Product Family ที่มีความสำคัญแต่ข้อมูลไม่ซับซ้อนเกินไป แต่งตั้ง Product Data Owner, Compliance Owner และผู้ตัดสินใจด้านแบรนด์ เก็บตัวอย่างคำขอข้อมูลจากผู้นำเข้า แล้วทำ Gap Assessment เทียบกับข้อมูลและหลักฐานที่มีจริง

วันที่ 31–60 สร้าง Data Dictionary, Identifier Policy, Evidence Register และ Access Matrix เชื่อมข้อมูลจากฝ่ายออกแบบ จัดซื้อ โรงงาน คุณภาพ โลจิสติกส์ เว็บไซต์ และบริการหลังการขาย ทำ Prototype ที่แสดงทั้งข้อมูลสาธารณะและข้อมูลจำกัดสิทธิ์ ทดสอบการเปลี่ยน Version, การเรียกข้อมูลผ่าน API หรือไฟล์มาตรฐาน และการกู้คืนเมื่อปลายทางล่ม อย่าลืมกำหนดผู้รับผิดชอบเมื่อซัพพลายเออร์เปลี่ยนวัสดุหรือใบรับรองหมดอายุ

วันที่ 61–90 ทดสอบ Pilot กับสินค้าจริง ฉลากจริง อุปกรณ์มือถือ และผู้ใช้สี่กลุ่ม ได้แก่ ทีมภายใน คู่ค้า ลูกค้า และผู้ซ่อมหรือรีไซเคิล ตรวจความถูกต้องกับฝ่ายกฎหมายหรือผู้เชี่ยวชาญของตลาดปลายทางก่อนอ้างว่า Compliance เสร็จสมบูรณ์ สรุปต้นทุนต่อ SKU เวลาที่ใช้แก้ข้อมูล อัตราข้อมูลครบ และจำนวนข้อผิดพลาด จากนั้นจึงตัดสินใจเลือกแพลตฟอร์ม ขยาย Product Family และเชื่อม Registry ตามข้อกำหนดที่ใช้จริง

เป้าหมายของ 90 วันไม่ใช่ทำ DPP ครบทุกสินค้า แต่คือพิสูจน์ว่าบริษัทสามารถสร้างข้อมูลหนึ่งชุดที่ถูกต้อง มีเจ้าของ อัปเดตได้ แลกเปลี่ยนได้ และสื่อสารกับคนได้ หากทำจุดนี้สำเร็จ DPP จะไม่ใช่โปรเจกต์เร่งด่วนก่อนส่งออก แต่กลายเป็นโครงสร้างข้อมูลกลางที่ช่วยทั้ง Compliance, Website, Customer Service, Product Innovation และความน่าเชื่อถือของแบรนด์ในระยะยาว