ระบบตรวจสอบย้อนกลับในไทย: RFP และ PoC 90 วันสำหรับยุค EU DPP

ระบบตรวจสอบย้อนกลับในไทยจะกลายเป็นความสามารถด้านการส่งออกได้ ก็ต่อเมื่อทำได้มากกว่าพิมพ์ QR Code หรือเก็บประวัติรายการ ระบบที่ใช้งานจริงต้องเชื่อมการรับวัตถุดิบ การผลิต การตรวจสอบ การบรรจุ และปลายทางจัดส่งด้วยรหัสระบุและ Event ที่สอดคล้องกัน อีกทั้งต้องเปิดเผยเฉพาะหลักฐานที่ลูกค้า ผู้ตรวจประเมิน หรือหน่วยงานมีสิทธิเห็น EU Digital Product Passport (DPP) Registry เปิดดำเนินการเมื่อ 20 กรกฎาคม 2026 แต่เหตุการณ์นี้ไม่ได้ทำให้ DPP เป็นข้อบังคับทันทีกับสินค้าทุกชนิด บทความนี้อธิบายวิธีที่โรงงานส่งออกในประเทศไทยจะไม่ตีความกฎเกินจริง และใช้ RFP กับ Proof of Concept 90 วันพิสูจน์สิ่งที่ตรวจสอบย้อนกลับได้จริง

ตรวจให้ชัดก่อน: DPP บังคับสินค้าทุกชนิดแล้วหรือไม่

คำตอบคือ “ยังไม่ใช่” คณะกรรมาธิการยุโรปอธิบายว่า DPP เป็น Digital Container สำหรับข้อมูลของผลิตภัณฑ์ ชิ้นส่วน และวัสดุ การวางกรอบ Registry ในเดือนกรกฎาคม 2026 และเปิดใช้งานจริงวันที่ 20 กรกฎาคม เป็นความก้าวหน้าของโครงสร้างพื้นฐาน อย่างไรก็ตาม Regulation (EU) 2024/1781 หรือ Ecodesign for Sustainable Products Regulation (ESPR) กำหนดให้ข้อกำหนด DPP ที่เป็นรูปธรรมใช้ผ่าน Delegated Act ของแต่ละกลุ่มผลิตภัณฑ์ กฎหมายลำดับรองดังกล่าวจะระบุสินค้า ข้อมูล Data Carrier ตำแหน่ง Granularity ระดับ Model/Batch/Item และสิทธิการเข้าถึง

Timeline ของคณะกรรมาธิการที่เป็นปัจจุบันในเดือนกันยายน 2026 ระบุว่า หลังรับรอง ESPR Delegated Act ผู้ประกอบการจะมีช่วงเปลี่ยนผ่านอย่างน้อย 18 เดือน ดังนั้น “Registry ใช้งานได้แล้ว” ไม่เท่ากับ “สินค้าส่งออกทุกชนิดมีหน้าที่ตามกฎหมายแล้ว” เอกสารขายที่ระบุว่า “สินค้าส่งออกไป EU ทุกชนิดต้องมี DPP ตั้งแต่ปี 2026” จึงไม่ถูกต้อง ก่อนกำหนด Software ใน RFP ต้องจัด Product Classification ของสินค้าแต่ละกลุ่มให้ตรงกับกฎหมาย Delegated Act และวันที่เริ่มใช้

Battery Passport เป็นกรณีเฉพาะที่เริ่ม 18 กุมภาพันธ์ 2027

แบตเตอรี่เป็นกลุ่มสินค้าที่มีข้อกำหนดชัดเจนก่อน คำแนะนำฉบับปรับปรุงของคณะกรรมาธิการยุโรปซึ่งเผยแพร่วันที่ 21 สิงหาคม 2026 รวบรวม Data Point ของ Battery Passport 71 รายการ แต่จำนวนนี้ไม่ใช่ Schema 71 Field ร่วมสำหรับ DPP ทุกประเภท เอกสารระบุว่าแต่ละ Data Point เป็น Mandatory, Optional, ใช้ภายใต้เงื่อนไข หรือยังไม่ต้องกรอกสำหรับแบตเตอรี่แต่ละประเภท ตาม Article 77 ของ Regulation (EU) 2023/1542 ตั้งแต่ 18 กุมภาพันธ์ 2027 แบตเตอรี่รถยนต์ไฟฟ้า แบตเตอรี่ Light Means of Transport (LMT) และแบตเตอรี่อุตสาหกรรมที่มีความจุมากกว่า 2 kWh ซึ่งวางตลาดหรือเริ่มใช้งานใน EU ต้องมี Battery Passport

ขอบเขตความรับผิดชอบก็สำคัญ คณะกรรมาธิการอธิบายว่า Economic Operator ที่นำแบตเตอรี่สำเร็จรูปวางตลาดเป็นผู้รับผิดชอบสร้างและรักษา Passport ไม่ใช่ว่าผู้ส่งมอบชิ้นส่วนหรือ Module ทุกแห่งจะเป็นผู้รับผิดชอบตามกฎหมายโดยอัตโนมัติ แต่โรงงานวัสดุ Cell, Module หรือชิ้นส่วนในไทยอาจได้รับข้อกำหนดข้อมูลจากลูกค้าผ่านสัญญา การไม่ได้เป็น Passport Issuer จึงไม่ได้แปลว่าไม่ต้องเตรียมข้อมูล แต่ต้องแยกหน้าที่ตามกฎหมายออกจากหลักฐานที่สัญญาซื้อขายกำหนด

Registry เป็นดัชนี ไม่ใช่คลังกลางของข้อมูลละเอียดทั้งหมด

ตามข้อมูลของคณะกรรมาธิการ DPP Registry ทำหน้าที่เป็น Indexing Service สำหรับ Passport ของผลิตภัณฑ์ที่วางตลาดใน EU โดยเก็บ Unique Identifier ข้อมูลลงทะเบียน และ High-level Metadata มากกว่าจะเก็บข้อมูลละเอียดทั้งหมดใน Passport ข้อมูลละเอียดอยู่ในระบบแบบ Decentralised ที่ Economic Operator ผู้รับผิดชอบดูแล และแสดงตามสิทธิที่กฎหมายกำหนด

เมื่อแปลงเป็น RFP การถามเพียงว่า Vendor “Upload ทุกอย่างขึ้น DPP Cloud ได้ไหม” จึงไม่พอ โรงงานต้องกำหนดว่าหลักฐานใดอยู่ใน ERP, MES, QMS, LIMS, PLM, WMS หรือ Document Management ใช้รหัสใดเชื่อม ใครอนุมัติการเปิดเผย Service ใดลงทะเบียน Passport และการแก้ไข Source Data จะส่งต่ออย่างไรโดยไม่ทำลาย Audit Trail

กำหนดผลลัพธ์ของระบบตรวจสอบย้อนกลับในไทยก่อน

Traceability ไม่ใช่เพียง “มีประวัติ” แต่เป็นความสามารถในการระบุประวัติหรือที่อยู่ของสิ่งที่กำหนดเพื่อวัตถุประสงค์ที่ชัดเจน Product Safety, Quality Containment, Customer Audit, Anti-counterfeit, Warranty, Sustainability และ Export Compliance ต้องการ Granularity ระยะเก็บ และผู้ดูข้อมูลต่างกัน การรวมทุกวัตถุประสงค์เป็น Requirement กว้าง ๆ จะทำให้เก็บข้อมูลเกินจำเป็นและยังขาดหลักฐานสำคัญ

มตช. 22005-2567 ของ TISI เป็นมาตรฐานการตรวจสอบและรับรองแห่งชาติว่าด้วยหลักการทั่วไปและข้อกำหนดพื้นฐานสำหรับการออกแบบและดำเนินระบบตรวจสอบย้อนกลับในห่วงโซ่อาหารสัตว์และอาหารมนุษย์ ประกาศในราชกิจจานุเบกษาเมื่อ 8 พฤศจิกายน 2567 และอ้างอิงขอบข่าย ISO 22005:2007 มาตรฐานนี้ไม่ใช่ข้อบังคับทั่วไปสำหรับทุกอุตสาหกรรม แต่แนวคิดบริหารมีประโยชน์กว้างกว่าอาหาร ได้แก่ กำหนดวัตถุประสงค์ ออกแบบและดำเนินระบบให้บรรลุวัตถุประสงค์ แล้วตรวจประเมินและทบทวน

GS1 Global Traceability Standard ก็ให้กรอบ Process-neutral สำหรับ Traceability ข้าม Trading Party โดยไม่ผูกกับสินค้าและ Application เดียว เมื่อเริ่ม RFP ควรตกลงผลลัพธ์ 5 กลุ่ม:

1. ติดตามประวัติการผลิต: ย้อนจาก Finished Lot หรือ Serial ไปยังวัสดุ เครื่องจักร Process Condition งานและผลตรวจได้ตาม Granularity ที่ต้องการ
2. ติดตามปลายทาง: เดินหน้าออกจาก Input, Lot หรือ Serial ที่สงสัย ไปยัง Shipment, Customer, Delivery Point, Quantity และจุดที่ยังเหลืออยู่
3. ตัดสินใจ Containment: อธิบายขอบเขตผลกระทบจากความสัมพันธ์จริงของ Transformation, Aggregation, Split และ Rework ไม่ใช่เหมารวม “ผลิตวันเดียวกันทั้งหมด”
4. ส่งมอบหลักฐาน: ทำซ้ำได้ว่าใครอนุมัติ Source ใด เมื่อใด เปิดเผย Version ไหนให้ใคร
5. รองรับการเชื่อมในอนาคต: เชื่อม Product-specific DPP, Customer Portal หรือ EPCIS โดยไม่เปลี่ยนความหมายของ Source Record

หากต้องการดูโครงสร้างการลงทุนก่อน โปรดอ่าน ต้นทุนระบบตรวจสอบย้อนกลับในไทย ส่วนการแลกเปลี่ยน Event ระหว่างองค์กรดูได้จาก Traceability ใน Supply Chain ด้วย EPCIS บทความนี้จะเน้น Acceptance Evidence ใน RFP และ PoC ที่คำนึงถึง DPP

ออกแบบรหัส ความสัมพันธ์ และ Event ก่อนเลือก QR หรือ RFID

QR, Barcode, RFID และ Direct Marking เป็น Data Carrier ไม่ใช่ Traceability ด้วยตัวเอง หัวใจคือรหัสที่สแกนระบุอะไรอย่างไม่ซ้ำ และระบบตอบความสัมพันธ์กับ Event อะไรกลับมาได้

Identifier: อย่าให้เลขเดียวมีหลายความหมาย

อย่างน้อยต้องแยก Item, Production Lot, Unit Serial, Material Lot, Package/Logistic Unit, Location, Trading Party และ Equipment การเขียนทับ Customer Item ด้วย Internal Item, Supplier Lot ด้วย Receipt Lot หรือ Package เดิมด้วยรหัสหลัง Repack จะตัดสาย Traceability

ให้ความสำคัญกับ Issuing Authority, Uniqueness, การห้ามนำรหัสเก่ากลับใช้, Creation Time และการควบคุม Label Reprint มากกว่าการทำเลขให้อ่านง่าย สำหรับ DPP ต้องคงความสามารถในการ Mapping ระดับ Model, Batch หรือ Item ตามกฎหมายสินค้า การทำ Unit-level ให้ทุกสินค้าอาจสร้างภาระเกินจำเป็น ขณะที่การล็อกไว้แค่ Lot อาจไม่พอสำหรับหน้าที่หรือสัญญาที่ต้องการข้อมูลรายชิ้น Granularity จึงต้องเลือกได้ตาม Risk, Process และข้อกำหนด

Relationship: อย่าทำ Transformation, Split และ Rework หาย

Time Log อย่างเดียวสร้าง Manufacturing Genealogy ไม่ได้ หาก Material Lot A และ B กลายเป็น Semi-finished C และ C แบ่งเป็น Finished Lot D กับ E ต้องเก็บ A/B → C → D/E รวมถึงกรณีจริง เช่น Rework กลับเข้าล็อตใหม่ งาน Subcontract กลับมาหลาย Package การคัดชิ้นดีไปสร้างล็อตใหม่ Bulk Consumption และ Repacking

Genealogy เดียวกันรองรับทั้ง Trace Backward และ Trace Forward สำหรับมุมมองด้านยานยนต์ โปรดดู IATF 16949 และระบบ Traceability ในไทย

Event: ใช้คำอธิบายร่วมว่าเกิดอะไร ที่ไหน เมื่อไร

GS1 EPCIS 2.0.1 ทำให้ Application ต่างระบบสร้างและแชร์ Visibility Event ได้ทั้งภายในและระหว่างองค์กร Normative Artefact ครอบคลุมการตรวจ JSON/JSON-LD และนิยาม REST Query การกำหนด EPCIS Compliance ใน RFP ขึ้นกับ Trading Network และ Use Case แต่กรอบคำถาม Event ใช้งานได้ดี:

• What: Product, Lot, Serial หรือ Logistic Unit
• When: Event Time, Record Time และ Time Zone
• Where: Process, Machine, Warehouse, Shipping หรือ Receiving Location
• Why: Business Step และสถานะ เช่น Receive, Consume, Transform, Inspect, Hold, Release, Pack, Ship
• How: Sensor, Measurement หรือ Certification ที่เกี่ยวข้อง

อย่านำศัพท์มาตรฐานไปแปะหน้าจอโดยไม่ทำ Data Governance ต้อง Mapping ภาษาหน้างานไทย คำญี่ปุ่นของสำนักงานใหญ่ และรหัสอังกฤษของลูกค้าเข้าสู่ Business Vocabulary เดียว และป้องกันการนับ Physical Action หนึ่งครั้งซ้ำเพราะสองระบบรายงาน

12 คำถามที่ต้องมีใน RFP ระบบตรวจสอบย้อนกลับ

RFP ควรบังคับให้ Vendor ตอบ Responsibility และ Acceptance Evidence ไม่ใช่แค่ Yes/No ต่อ Function:

1. Scope/Purpose: ครอบคลุมสินค้า Site, Process, Customer, Regulation ใด และต้องลดเวลาในการตัดสินใจอะไร
2. Identification Granularity: ออกรหัส Item, Lot, Serial, Logistic Unit ที่ไหน และป้องกัน Duplicate/Reuse อย่างไร
3. Genealogy: แสดง Mixing, Splitting, Substitute, Rework, Subcontract, Sorting และ Repack อย่างไร
4. Event Capture: Record ใดเป็น Source of Truth ระหว่าง ERP/MES, Scanner, PLC, Inspection Device และ IoT Gateway
5. Time/Sequence: จัดการ ICT, UTC, กะข้ามวัน, Late Event, Clock Drift และ Offline Replay อย่างไร
6. Master Governance: ใครเป็น Owner ของ Item, BOM, Routing, Machine, Supplier, Customer, Location, Unit, Revision และ Effective Date
7. Data Quality: Missing, Duplicate, Conflict และ Unknown Code ถูกหยุดที่ไหน ใครอนุมัติ Exception
8. Forward/Backward Search: Search Key, Response Target, Quantity/Location/Destination และ Evidence Format คืออะไร
9. External Exchange: เชื่อม GS1/EPCIS, Customer API, CSV, Portal และ DPP Service พร้อม Version Control อย่างไร
10. Access Control: แยก Field สำหรับ Public, Customer, Authority/Auditor และ Internal อย่างไร
11. Retention/Change Evidence: จัดการระยะเก็บ เหตุผลแก้ไข ผู้อนุมัติ Backup และ Recovery Test อย่างไร
12. Operating Ownership: ใครทำ First Response, Data Stewardship, Interface Failure, Label Reprint, SLA และ Change Control

กำหนดรูปแบบคำตอบเป็น Standard, Configuration, Interface, Customisation, Process Change หรือ Unsupported คำว่า “รองรับ” ยังไม่ใช่หลักฐานเปรียบเทียบ แต่ละคำตอบต้องมี Assumption, Owner, Incremental Cost, Maintenance, Retest หลัง Upgrade และ PoC Scenario ที่พิสูจน์ได้

สร้าง Data Responsibility Matrix สำหรับ DPP รายผลิตภัณฑ์

ความผิดพลาดที่พบบ่อยคือโยนข้อมูล DPP ทั้งหมดให้หน่วยงานเดียว Product Identity อาจมาจาก Engineering, Material Declaration จาก Procurement/Supplier, Production Event จากโรงงาน, Quality จาก QMS, Destination จาก ERP/WMS และ Disclosure Approval จาก Legal, Quality, Sales แต่ละ Data Point ควรกำหนด:

• Legal Source: Regulation, Delegated Act, Customer Contract หรือ Internal Policy
• Applicability: Mandatory, Optional, Conditional, Not Applicable และผู้มีอำนาจตัดสิน
• Source System: Source of Truth และ Interface
• Granularity: Model, Batch, Item หรือ Shipment Unit
• Owner: ผู้รับผิดชอบความหมาย ความถูกต้อง การอนุมัติและแก้ไข
• Visibility: Public, Trading Partner, Authority/Auditor หรือ Internal
• Update Trigger: Design Revision, Production Complete, Inspection, Repair, Reuse
• Evidence: Provenance, Approval และ Change History
• Retention: ระยะตาม Product Life, Contract และกฎหมายที่ใช้

เมื่อมี Delegated Act ใหม่ Matrix นี้จะบอกได้ว่าข้อมูลใดมี Governance แล้ว ข้อมูลใดต้องขอ Supplier และข้อมูลใดต้องเพิ่มการเก็บใน Process ก่อนตัดสินใจซื้อ “DPP Module” เพิ่ม

PoC 90 วันที่สร้างหลักฐานแทนการสาธิตสินค้า

แผน 90 วันด้านล่างเป็นตัวอย่างวางแผน ไม่ใช่ระยะตามกฎหมาย Benchmark อุตสาหกรรม หรือการรับประกัน ต้องปรับตาม Product, Site, Machine, Party และ Data Quality จุดประสงค์คือกำจัดความไม่แน่นอนก่อนลงทุนตามลำดับ ไม่ใช่ทำ Enterprise Rollout ให้เสร็จในสามเดือน

วันที่ 1–15: ล็อกสินค้า กฎหมาย สัญญา และ Decision Right

เลือกสินค้าส่งออกหนึ่งชนิด Line ตัวแทนหนึ่งสาย และ Destination หนึ่งแห่ง ยืนยัน Product Classification และกฎหมายกับผู้เชี่ยวชาญ แยกหน้าที่ปัจจุบันออกจาก Requirement ในอนาคต หากเป็นแบตเตอรี่ที่เข้า Scope ให้ใช้ Regulation (EU) 2023/1542 และ Guidance ล่าสุด หากเป็นสินค้าอื่นให้ตรวจว่ามี ESPR Delegated Act แล้วหรือไม่ ห้าม Requirement กว้างว่า “DPP-ready” และเขียน Use Case เช่น “จาก Serial ที่ลูกค้าร้องเรียน ต้องสร้าง Material Lot, Inspection Evidence, ขอบเขตสินค้าทั้งหมดที่ได้รับผลกระทบจากสาเหตุเดียวกัน และ Destination ได้”

Deliverable ได้แก่ Applicability Note, Current Process, Identity Register, Data Responsibility Matrix, Exception Catalogue และ PoC Acceptance Sheet แยกผู้ตัดสินด้านกฎหมายออกจากผู้ตัดสินด้าน Solution

วันที่ 16–30: ทำ Physical Flow และ Data Flow ให้ตรงกัน

สังเกต Receive, Store, Issue, Transform, Mix/Split, Inspect, Pack และ Ship ในพื้นที่จริง ไม่ดูเฉพาะ Standard Work แต่ติดตาม Label Damage, Substitute, Rework, Bulk, Remainder, Night Shift, Network Loss และ Correction ทุกจุดต้องบันทึก Physical Identity, Capture Method, Actor, Source Application และ Relationship ที่ส่งต่อ

หากพบ Gap จำนวนมาก อย่า Automate ทุกจุดพร้อมกัน ให้จัดลำดับ Genealogy/Destination Gap ที่กระทบ Containment สูง แยก Workaround ที่ควบคุมได้ออกจากจุดที่ต้องเพิ่ม Reader, Device หรือ Interface จริง

วันที่ 31–60: เชื่อมห่วงโซ่หลักฐานตัวแทนหนึ่งเส้น

รับเฉพาะ Event ที่จำเป็นจาก ERP, MES, QMS, WMS และ IoT แล้วเชื่อมสินค้าที่เลือกทั้ง Upstream/Downstream หากจะใช้ EPCIS ภายนอก ให้ทำความหมายและ Data Quality ภายในให้เรียบร้อยก่อน ใส่ Normal Flow และ Exception จริงอย่างน้อยสองแบบ เช่น Split, Mix, Rework, Subcontract, Hold/Release หรือ Repack

ให้ความสำคัญกับ Repeatability: Input ที่ควบคุมชุดเดียวต้องสร้าง Trace Result และ Evidence Pack แบบเดิมได้ ทดสอบว่าการปฏิบัติงานภาษาไทยสามารถสร้างหลักฐานภาษาอังกฤษที่มีความหมายถูกต้องโดยไม่เปลี่ยน Source Meaning

วันที่ 61–75: ตั้งใจทำให้ Interface และ Permission พัง

สร้าง Scanner Loss, Network Interruption, Duplicate Delivery, Clock Drift, Unknown Item, Label Reprint, Interface Timeout และ Wrong Destination Association ตรวจว่าระบบไม่รับ Missing Evidence เงียบ ๆ Replay ไม่สร้าง Event ซ้ำ และ Correction ไม่ลบ Original Record

สลับ Role ระหว่าง Public, Customer, Internal Quality และ Administrator ตรวจว่า Cost, Supplier Term, Personal Data และ Commercial Detail ไม่หลุดทั้ง Screen, API และ Export DPP ไม่ใช่แค่ Public Page แต่ Access Control คือแกนของการออกแบบ

วันที่ 76–90: Mock Audit และ RFP Gate ด้วยหลักฐาน

ให้ Quality, Sales, IT, Management และผู้ใช้จริงทำ Mock Complaint/Recall Case เดียวกัน บันทึกเวลาเริ่ม คำถาม ขั้นตอนค้นหา เหตุผลตัดออก Output, Approval และเวลาจบ ส่ง Unresolved Item กลับ RFP ใช้ PoC Log, Reconciliation, Permission Test และ Recovery Result เป็น Contract Gate แทน Vendor Presentation

ตัวอย่าง Acceptance Matrix ของ PoC

ตัวเลข Threshold ต้องเป็นการตัดสินของบริษัท ตารางนี้เป็นเพียงแบบออกแบบ Test ไม่ใช่สถิติภายนอกหรือ Performance Promise

Freeze Expected Result และ Source Ledger ก่อนทดสอบ ใช้ข้อมูลจริงที่ทำ Anonymise, Exception จริง, Network Condition ของโรงงานไทย และผู้ใช้หน้างาน ไม่ใช้เฉพาะ Demo Record ของ Vendor

Integration Architecture ที่รักษาประวัติการผลิต

Product Mix ที่เหมาะสมต่างกันตามโรงงาน แต่ Responsibility แบ่งได้ชัด:

• ERP: Order, Purchase, Item, BOM, Production Order, Inventory, Shipment, Customer
• MES/QMS/LIMS: Execution, Equipment, Operator Qualification, Test, Disposition, Deviation, Rework
• WMS/Barcode/RFID: Location, Handling Unit, Movement, Pick, Pack, Dispatch Scan
• IoT/PLC/Gateway: Equipment State, Measurement, Time และ Edge Buffer
• Traceability Repository/EPCIS: Cross-system Genealogy, Event Search, Controlled Exchange
• DPP Service: Product Schema, Public/Restricted View, Data Carrier และ Registry Connection

ไม่จำเป็นต้อง Copy ทุกอย่างเข้าฐานเดียว เลือก Minimum Event และ Source Reference ที่ใช้ Traceability การแก้ไขต้องส่งจาก Governed Source System หาก Aggregation Layer แก้ค่าได้อิสระ จะไม่รู้ว่าหลักฐานใดเป็น Source of Truth

ต้องทดสอบ Offline และเวลาในโรงงานไทย

หากเครือข่ายหน้างานขาดได้ ให้ Queue ที่ Terminal/Gateway แยก Event Time ออกจาก Record Time และใช้ Replay ID ป้องกัน Duplicate กำหนดการเก็บ/แสดง ICT กับ UTC อย่าผสมเวลาสำนักงานใหญ่แบบไม่เป็นทางการ กะข้ามคืนอาจต้องมีทั้ง Calendar Date และ Production Date

Manual Contingency ก็เป็น System Requirement ถ้าใช้กระดาษยามฉุกเฉิน ต้องกำหนดว่าใคร Key-in ภายหลัง Material ใด Hold แนบ Original Record อย่างไร และป้องกัน Double Entry อย่างไร

ติดตามปลายทางและ Mock Recall เพื่ออธิบายขอบเขต

Destination Tracking ต้องทำมากกว่าขึ้นชื่อลูกค้า จาก Issue Origin ต้อง Reconcile Item/Lot/Serial, Package, Shipment Document, Delivery Point, Quantity, Date รวมถึง Return, Inventory และ WIP หาก Production, Scrap, Sample, Stock, Shipment และ Return ไม่สมดุล ผลที่ดูแคบก็ไม่น่าเชื่อถือ

Mock Recall ให้เลือก Material Lot ที่สงสัยแล้ว Trace Forward จากนั้นเลือก Finished Serial จาก Customer Complaint แล้ว Trace Backward ทั้งสองต้องอธิบายผ่าน Genealogy เดียวกัน สินค้าที่ตัดว่าไม่กระทบก็ต้องมี Exclusion Evidence

DPP ไม่ได้แทน Foundation นี้ Public View ที่สวยงามชดเชย Internal Genealogy ที่ขาดไม่ได้ ในทางกลับกัน Event และ Accountability ที่แข็งแรงทำให้ Mapping ไป Product-specific Schema ใหม่ง่ายขึ้น

ดึง Supplier และ Customer เข้าระบบแบบเป็นขั้น

Traceability ของโรงงานต่างประเทศจบแค่รั้วบริษัทไม่ได้ แต่การบังคับ Supplier ทุกแห่งใช้ API เดียวตั้งแต่วันแรกทำให้โครงการหยุด ลำดับที่เหมาะสมคือ:

1. จำกัด Wave แรกด้วย Product/Material Risk
2. สำรวจ COA, Lot, Origin/Material Declaration และ Shipping Data ที่ได้รับอยู่
3. ทำ Minimum Contract Specification สำหรับ Identity, Unit, Time, Correction และ Version
4. อนุญาต Maturity Level เช่น CSV, Portal, API, EPCIS แต่ใช้ Common Semantics
5. แชร์ Data-quality Finding และ Exception Process ก่อนพึ่ง Penalty อย่างเดียว
6. แยก Customer Disclosure ออกจาก Supplier-confidential Information

Field Name ตรงกันยังไม่ใช่ Interoperability ต้องตกลง Unit, Code System, Event Meaning, Time Zone, Update และ Cancellation หากใช้ EPCIS ต้องควบคุม Business Step/Disposition Vocabulary, Identity Issuance และ Query Access ร่วมกัน

ตรวจ BOI แยกจากการออกแบบระบบ

มาตรการยกระดับอุตสาหกรรม Smart and Sustainable Industry ของ BOI สนับสนุนการปรับปรุงประสิทธิภาพและยกระดับกิจการผลิต/บริการ หน้าอังกฤษปัจจุบันระบุ Minimum Investment ด้าน Efficiency Enhancement 1 ล้านบาท ไม่รวมค่าที่ดินและทุนหมุนเวียน พร้อมการยกเว้นอากรขาเข้าเครื่องจักรและสิทธิ CIT ภายใต้เงื่อนไข รวมทั้งเงื่อนไขเกี่ยวกับเครื่องจักรที่เชื่อมโยงอุตสาหกรรม Automation ในประเทศ

โครงการ Traceability ไม่ได้มีสิทธิอัตโนมัติ ต้องตรวจ Activity, Existing/New Project, Eligible Investment, Timing, Domestic Development/Certification และ Implementation Deadline กับประกาศล่าสุด BOI เจ้าหน้าที่ และที่ปรึกษาภาษี/กฎหมายที่เหมาะสม RFP ควรมี Base Case ที่คุ้มได้โดยไม่มี Incentive แล้วแยกกรณีได้รับอนุมัติ ไม่ใช้สิทธิที่ยังไม่อนุมัติเป็น ROI

KPI หลังนำระบบไปใช้

การ Go-live ไม่ใช่ผลลัพธ์ เก็บ Baseline ใน PoC แล้วตั้งเป้าหมายบริษัทเองสำหรับ:

• Completeness และ On-time Capture ของ Required Trace Event
• Unknown Code, Duplicate, Reversed Time, Unresolved Exception
• เวลา Trace Forward/Backward ของ Item ตัวแทน
• Quantity Reconciliation Variance และ Root Cause
• Label Reprint, Manual Capture, Offline Replay Frequency
• Supplier Timeliness และ Correction Lead Time
• Access Violation, Over-disclosure, Audit-log Gap
• เวลา Mock Recall เพื่อ Scope, Approve และเตรียม Notification
• Delay/Reject ของ DPP หรือ Customer Evidence Submission

ใช้ KPI หา Ownership, Master และ Interface ที่ขาด ไม่ใช้ลงโทษ Operator ตัวชี้วัด Missing อย่างเดียวกระตุ้นให้กรอก Placeholder ควรรวม Completeness, Accuracy, Timeliness และ Consistency

คำถามที่พบบ่อย

EU DPP บังคับสินค้าทุกชนิดตั้งแต่ปี 2026 หรือไม่?

ไม่ใช่ Registry เปิดใช้งานวันที่ 20 กรกฎาคม 2026 แต่ Requirement ภายใต้ ESPR ใช้เป็นขั้นตาม Product-group Delegated Act คณะกรรมาธิการระบุช่วงเปลี่ยนผ่านอย่างน้อย 18 เดือนหลังรับรอง Act ต้องตรวจ Classification และ Act ล่าสุดของแต่ละสินค้า

แบตเตอรี่ใดต้องมี Passport และเมื่อไร?

Article 77 ของ Regulation (EU) 2023/1542 ใช้ตั้งแต่ 18 กุมภาพันธ์ 2027 กับ EV Battery, LMT Battery และ Industrial Battery มากกว่า 2 kWh ที่วางตลาดหรือเริ่มใช้ใน EU Guidance วันที่ 21 สิงหาคม 2026 จัด Data Point 71 รายการและ Applicability ตามประเภท ต้องตรวจฉบับล่าสุดและบทบาทของบริษัท

ควรเริ่มระบบตรวจสอบย้อนกลับในไทยจากอะไร?

กำหนด Product, Purpose, Start/End Point, Granularity, Decision Owner และ Evidence ก่อนเลือก Technology ทำ Mapping Physical/Data Flow ของสินค้าตัวแทน แล้วทดสอบ Mix, Split, Rework และ Network Loss จริง

QR Code พอสำหรับติดตามประวัติการผลิตไหม?

ไม่พอ QR เป็นเพียงตัวนำ Identity/Link ประวัติการผลิตยังต้องมี Material-product Genealogy, Process/Inspection Event, Correction Evidence, Destination, Quantity Reconciliation และ Access Governance

EPCIS 2.0.1 จำเป็นหรือไม่?

ไม่ได้บังคับทุกโรงงาน แต่เป็นมาตรฐานที่มีประโยชน์ต่อการแชร์ Visibility Event ข้าม Application/บริษัท การเลือกใช้ขึ้นกับ Product Requirement และ Trading Network ต้องทำ Internal Data และ Vocabulary ก่อน

PoC 90 วันทำ Production Rollout เสร็จหรือไม่?

ไม่ใช่ นี่คือตัวอย่างเพื่อการตัดสินใจลงทุน จำกัด Product, Line, Destination แล้วพิสูจน์ Genealogy, Exception, Security, Failure และ Evidence ก่อนตัดสินใจ Scale

สรุป

ระบบตรวจสอบย้อนกลับในไทยสำหรับยุค DPP ไม่ควรเริ่มจากการซื้อระบบใหญ่ด้วยคำโฆษณาด้านกฎระเบียบ Registry เปิดใช้งาน 20 กรกฎาคม 2026 เป็น Milestone ของ Infrastructure แต่หน้าที่ ESPR ใช้เป็นขั้นผ่าน Product-specific Delegated Act ส่วนแบตเตอรี่เป็นกรณีเฉพาะภายใต้ Regulation (EU) 2023/1542 เริ่ม 18 กุมภาพันธ์ 2027 สำหรับประเภทที่ระบุ เมื่อเข้าใจขอบเขตนี้ โรงงานสามารถควบคุม Identity, Genealogy, Event, Destination, Ownership, Access และ Correction Evidence เพื่อแก้ปัญหาคุณภาพวันนี้และรองรับ DPP รายผลิตภัณฑ์ในอนาคต RFP ต้องขอ Responsibility/Evidence และ PoC ต้องทดสอบ Exception, Interface และ Permission แบบตั้งใจ

TOMAS TECH ช่วยโรงงานในประเทศไทยสำรวจ Physical/Data Flow จัดทำ Traceability RFP เชื่อม ERP/MES/WMS/IoT ออกแบบ Forward/Backward Trace, EPCIS Exchange และ Acceptance ของ PoC 90 วันได้ ระหว่างตรวจ Applicability ของ DPP รายผลิตภัณฑ์และก่อนเลือก Platform หรือ Vendor สามารถ ติดต่อเรา ได้

แหล่งข้อมูล

• European Commission, Digital Product Passport
• European Commission, The DPP Registry
• EUR-Lex, Regulation (EU) 2024/1781 (ESPR)
• European Commission, คำแนะนำ Battery Passport, 21 สิงหาคม 2026
• EUR-Lex, Regulation (EU) 2023/1542
• GS1, Global Traceability Standard 2.0
• GS1, EPCIS Standard 2.0.1
• TISI, มตช. 22005-2567
• Thailand BOI, Smart and Sustainable Industry