Trace Forward/Back: RFP และตรวจรับคำตอบ 24 ชั่วโมง

Trace Forward คือการเริ่มจากล็อตวัตถุดิบ งานระหว่างผลิต สินค้าสำเร็จรูป หรือหมายเลขซีเรียล แล้วติดตามไปข้างหน้าว่าถูกแปรรูปเป็นสินค้าใด บรรจุในหน่วยใด เคลื่อนไปคลังใด และส่งให้ลูกค้ารายใด ส่วน Trace Back จะย้อนกลับไปยังวัตถุดิบ ซัพพลายเออร์ และเงื่อนไขกระบวนการ แต่การมีข้อมูลอยู่ในฐานข้อมูลยังไม่ใช่หลักฐานว่าระบบติดตามได้จริง ระบบต้องเดินผ่านการแปรรูป การแบ่ง การรวม การจัดกลุ่ม การบรรจุใหม่ งานแก้ไข และงานภายนอก พร้อมเปิดเผยจุดข้อมูลขาด และสร้างผลลัพธ์ที่หน่วยงานกำกับหรือลูกค้าตรวจสอบซ้ำได้ภายในเวลาที่กำหนด

บทความนี้เปลี่ยนคำจำกัดความให้เป็นข้อกำหนดสำหรับเลือกซื้อระบบ: RFP การสาธิต FAT SAT และการซ้อมเรียกคืน ทั้งบริบท 24 ชั่วโมงของ FDA และความคืบหน้า Digital Product Passport ของ EU มีประโยชน์ แต่การบังคับใช้ขึ้นกับผลิตภัณฑ์ เขตอำนาจ และบทบาท โปรดตรวจสอบกับฝ่ายคุณภาพ ฝ่ายกฎหมาย และหน่วยงานที่เกี่ยวข้อง

Trace Forward และ Trace Back ต้องพิสูจน์อะไร?

GS1 Global Traceability Standard วางภาษากลางเรื่อง trace back, track/trace forward หลัก one-step-up/one-step-down ระหว่างคู่ค้า และข้อมูลเพื่อตอบ Who, What, Where, When, Why ผู้ซื้อควรแยกสามประเด็น

ประเด็นแรกคือทิศทาง Trace Back เริ่มจากสินค้าที่ถูกร้องเรียนหรือซีเรียลสินค้าสำเร็จรูป แล้วย้อนหาวัตถุดิบ การรับเข้า ซัพพลายเออร์ และเงื่อนไขการผลิต Trace Forward เริ่มจาก input ที่มีข้อสงสัย แล้วหา output บรรจุภัณฑ์ และปลายทางทั้งหมด หากเร็วเพียงทิศเดียวก็ยังเชื่อมสาเหตุกับขอบเขตผลกระทบไม่ได้

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

ประเด็นที่สามคือการทำซ้ำ ต้องเก็บ ID ตั้งต้น เวอร์ชัน master data เขตเวลา สิทธิ์ ตัวกรอง และเวลาที่ query หากผลข้อมูลสดเปลี่ยนได้ ต้องตรึง snapshot และ query manifest ที่ใช้ส่ง

ออกแบบการติดตามประวัติการผลิตเป็น Event Graph

รายงานเรียงตามเวลาอาจดูครบแต่แทนการแยกและการรวมล็อตไม่ได้ ควรออกแบบวัตถุและเหตุการณ์เป็น node ที่เชื่อมด้วยความสัมพันธ์ชัดเจน

GS1 EPCIS 2.0.1 กำหนด ObjectEvent, AggregationEvent, TransactionEvent, TransformationEvent และ AssociationEvent โดยมีมิติ what, when, where, why TransformationEvent เชื่อม input กับ output ส่วน AggregationEvent แทนความเป็น parent-child ได้ artefacts ของ EPCIS 2.0 มี JSON/JSON-LD และส่วนที่เกี่ยวข้องกับ REST แต่การใช้ EPCIS ไม่รับประกันคุณภาพข้อมูล การปฏิบัติตามกฎหมาย หรือประสิทธิภาพ query โดยลำพัง RFP ต้องถามว่าระบบรักษาความหมายของงานจริงและส่งออกหลักฐานที่ทดสอบได้หรือไม่

Event การผลิตขั้นต่ำที่ต้องจำลอง

สมมติ A และ B ถูกผสมเป็น C จากนั้น C แบ่งเป็น C1/C2 และ C1 บรรจุในกล่อง K การค้นจาก A ไปข้างหน้าต้องถึง C, C1, C2, K และปลายทาง ส่วนการค้นจาก K ย้อนกลับต้องถึง C1, C, A และ B หากจำนวนไม่ตรง ต้องอธิบาย yield ตัวอย่าง ของเสีย และความคลาดเคลื่อนด้วย reason code ไม่ใช่ลบลิงก์ให้ยอดดูสวย

เวลา สถานที่ ผู้เกี่ยวข้อง และเหตุผลสำคัญเท่ากับ ID

กำหนดขอบเขตความไม่ซ้ำของ lot ID เขตเวลา การ sync นาฬิกาอุปกรณ์ สถานที่จริง/สถานที่เชิงธุรกิจ ผู้ทำ/ผู้อนุมัติ และรหัสขั้นตอน เก็บเวอร์ชันหรือช่วงมีผลของ master data เพื่อแสดงความหมายในอดีต แยก event time ออกจาก record time เพราะ terminal offline อาจส่งข้อมูลช้าหนึ่งวัน ระบบต้องบอกได้ว่าข้อมูลมีอยู่แล้วหรือยัง ณ จุดตัดเวลา

เปลี่ยนการติดตามปลายทางเป็นข้อกำหนด RFP 24 ชั่วโมง

คำว่า “ติดตามได้” “real time” หรือ “รองรับ EPCIS” ยังตรวจรับไม่ได้ ต้องวาง input, processing, output, เวลา, exception และ evidence ไว้ในข้อกำหนดเดียวกัน

ขอบเขตระบบ

ระบุสินค้า วัตถุดิบ โรงงาน คลังภายนอก งานจ้างช่วง หน่วยขาย ระยะเก็บข้อมูล และระดับ ID ว่าเป็น lot, batch, serial, case หรือ pallet หาก partner ยังให้รายละเอียดไม่ได้ ให้บันทึกผู้ถูกสอบถาม เวลา และสถานะคำตอบแทนการตีความว่าไม่มีผลกระทบ

Bidirectional query ที่เขียนในสัญญาได้

ตัวอย่างข้อความ: “ผู้ใช้ฝ่ายคุณภาพที่มีสิทธิ์สามารถใส่ล็อตที่ valid ใดก็ได้ ระบบจะเดินความสัมพันธ์ upstream/downstream โดยไม่วนไม่สิ้นสุด ครอบคลุม transformation, split, aggregation, repacking และ return พร้อม export ผลลัพธ์และ unresolved links” กำหนดปริมาณและ performance จากข้อมูลตัวแทน ไม่คัดลอกตัวเลขที่ไม่มีเหตุผล

นาฬิกา 24 ชั่วโมงเริ่มตรงไหน

หน้า FDA Food Traceability Rule อธิบายในบริบทที่เข้าเกณฑ์ว่า เมื่อ FDA ขอข้อมูล ต้องจัดส่งข้อมูลที่เกี่ยวข้อง รวมถึง electronic sortable spreadsheet โดยทั่วไปภายใน 24 ชั่วโมง หรือเวลาที่สมเหตุผลซึ่ง FDA เห็นชอบ FDA จัด Traceability Readiness Tabletop Exercises ระหว่าง 9 มีนาคมถึง 1 เมษายน 2026 และเผยแพร่ข้อมูลวันที่ 10 มิถุนายน 2026 โดยทดสอบการรับ record request และส่ง sortable spreadsheet ภายใน 24 ชั่วโมง

การแปลงเป็น acceptance test ต้องวัดครบตั้งแต่รับคำขอ ตรวจสิทธิ์ ยืนยันขอบเขต extract สอบถาม partner review exception อนุมัติคุณภาพ สร้างไฟล์ และส่ง ไม่ใช่วัด SQL เพียงอย่างเดียว โรงงานที่อยู่นอกกฎนี้อาจใช้เป็นเป้าหมายภายในที่เข้มสำหรับลูกค้าหรือวิกฤตได้

จาก Congressional directive FDA ระบุว่าไม่มีเจตนา enforce rule นี้ก่อนวันที่ 20 กรกฎาคม 2028 บทความนี้ไม่เรียกข้อความดังกล่าวว่า final compliance date โปรดตรวจสอบผลิตภัณฑ์ บทบาท และประกาศล่าสุดของ FDA

กำหนดชุดข้อมูลส่งมอบ

ไฟล์ electronic ไม่ได้แปลว่าตรวจด้วยเครื่องได้ PDF ภาพสแกนเรียงและ reconcile ยาก ให้ผูก human summary, sortable rows, relationships และ exceptions ด้วย request ID เดียว

ประเมิน EPCIS 2.0 ใน RFP อย่างไร?

ขอ sample event และ live query/export แทนสไลด์ “รองรับ”

1. ObjectEvent แทนการสังเกตหรือสถานะของ ID ได้หรือไม่
2. TransformationEvent เก็บหลาย input และหลาย output โดยไม่สูญหายหรือไม่
3. AggregationEvent เพิ่ม/ถอดสมาชิก case/pallet ได้หรือไม่
4. หลัง repack ยังย้อน old parent → children → new parent ได้หรือไม่
5. ใช้ JSON/JSON-LD schema และ REST artefact เวอร์ชันใด
6. extension ของ partner ที่ไม่รู้จักถูกแยกและแจ้งอย่างไร
7. correction ถูก overwrite หรือเก็บประวัติการแก้ไข

หากมี integration layer แปลงข้อมูล native เป็นมาตรฐาน ต้อง version mapping, rounding, หน่วย, timezone และ code translation HTTP สำเร็จก็ยังอาจมีหน่วยหรือ business step ผิด จึงทดสอบ syntax กับ semantic แยกกัน

ทำให้ Trace Forward ล้มเหลวโดยตั้งใจใน FAT/SAT

FAT ที่มีแต่ happy path ไม่เผยจุดที่พังในเหตุเรียกคืน ใช้ข้อมูลที่มีความสัมพันธ์เหมือน production และใส่ความผิดปกติ

Core scenario

• input หนึ่งตัวแบ่งเป็นหลายสินค้า
• หลาย input ผสมเป็น intermediate เดียว
• ถอด case จาก pallet หนึ่งแล้วรวมใต้ pallet ใหม่
• ฉลากเสียและออกใหม่ตามขั้นตอนควบคุม
• rework ถูกนำกลับเข้าอีกวัน
• คลังภายนอกแบ่งส่งหลายลูกค้า
• ของคืนส่วนหนึ่งทำลายและส่วนหนึ่งกักกัน

Exception injection

FAT ตรวจ relationship, API, query, export, authorization, correction และ recovery ด้วย dataset คงที่ SAT ทำซ้ำกับอุปกรณ์ เครือข่าย ผู้ใช้ ฉลาก และกะจริง เพื่อเห็น delay/งานมือระหว่าง PLC, MES, WMS, ERP และการฟื้นจาก offline

ตัวอย่างสมมติ: test pack 500 lots มีช่องว่างตั้งใจ 10 จุดและความผิดปกติเวลา 4 แบบ ตั้งเป้า approved export ภายใน 8 ชั่วโมง จำแนกช่องว่าง 100% และ relation error 0 ตัวเลขนี้เป็นสมมติ ไม่ใช่ราคาตลาดหรือ KPI สากล ต้องปรับตามความเสี่ยง ปริมาณ และเขตอำนาจ

GS1 Global Traceability Checklist มี 73 control points ใน 12 sections และวิธีประเมินกำหนด mandatory “musts” 100% นำแนวคิด gate มาใช้ได้: bidirectional traversal, gap visibility, authorization, reproducibility และ backup recovery เป็นข้อบังคับแม้คะแนนเฉลี่ยสูง แต่อย่าเรียกคะแนนภายในว่า GS1 certification

เปลี่ยน Mock Recall จาก Search Demo เป็นการซ้อมงาน

ให้ฝ่ายคุณภาพ ผลิต คลัง จัดซื้อ ฝ่ายขาย กฎหมาย ผู้บริหาร และ partner ภายนอกร่วม โดยไม่บอกกราฟล็อตที่ถูกต้องล่วงหน้า

1. ผู้มีอำนาจเปิด request ID และเริ่มเวลา
2. คุณภาพยืนยัน ID และขอบเขต
3. ทีมระบบ export upstream/downstream
4. หน้างาน reconcile stock จริง กักกัน และบันทึกส่ง
5. จัดซื้อถาม supplier โลจิสติกส์ถาม warehouse
6. owner ของ exception จัดประเภท missing/late/invalid
7. ผู้อนุมัติคุณภาพตรึงเวอร์ชันส่ง
8. reviewer อิสระตรวจทำซ้ำและข้อมูลตกหล่น

วัดมากกว่า query runtime แยกเวลาหาผู้มีสิทธิ์ รอ warehouse จัดประเภทจุดขาด และขออนุมัติ หลังผ่านเป้า 24 ชั่วโมงให้หาคอขวดและงานมือเพื่อปรับปรุง

Data Quality และ Governance ต้องเปิดเผยข้อมูลขาด

ความล้มเหลวอันตรายที่สุดไม่ใช่ error message แต่คือผลไม่ครบที่ดูเหมือนครบ แยก unknown, not captured, failed validation, not applicable, partner pending และบันทึกการตัด row ของผู้ใช้เป็น filter ใน manifest

ISO 22005:2007 ครอบคลุมหลักการและข้อกำหนดพื้นฐานในการออกแบบและนำระบบ traceability ของห่วงโซ่อาหาร/อาหารสัตว์ไปใช้ หน้า ISO ระบุว่า edition 2007 ถูก review และ confirmed ในปี 2022 และยัง current บทเรียนที่ถ่ายโอนได้คือกำหนด purpose, scope, responsibility, procedure และ record ก่อนเลือกเทคโนโลยี

เตรียมรองรับ EU DPP ไม่ได้แปลว่าต้องเก็บทุกอย่าง

Regulation (EU) 2024/1781 วางกรอบ ESPR ที่รวม DPP แต่รายละเอียดพัฒนาโดย product-specific delegated acts และมาตรการที่เกี่ยวข้อง ห้ามเขียนว่าสินค้าทุกชนิดต้องมี field เหมือนกันทันที

หน้า DPP ของ European Commission แสดง indicative timeline: registry operational 20 กรกฎาคม 2026, remaining standards กันยายน 2026 และ iron/steel ไตรมาส 4 ปี 2026 พร้อมระบุการพึ่งพา publication requirements RFP จึงควรทำ ID, event, data owner, access policy, version และ evidence link ให้ขยายได้ แทนการล็อก field ที่ยังไม่ชัด

ระบบ Trace Forward กับ DPP ไม่ใช่สิ่งเดียวกัน ระบบแรกเน้นความสัมพันธ์ event และการหาขอบเขตผลกระทบ ส่วน DPP รวมการเข้าถึงและแลกเปลี่ยนข้อมูลสินค้าที่กำหนด แต่ทั้งคู่ต้องมี ID ประวัติ version access และ external exchange ที่น่าเชื่อถือ

12 คำถามในการสาธิตระบบ

1. จากล็อต input นี้จะแสดง output และปลายทางทั้งหมดอย่างไร
2. จากสินค้าสำเร็จจะย้อนหลาย input lot อย่างไร
3. split, merge, rework, repack ใช้ event ใด
4. แยก unresolved link ออกจาก no relationship ได้หรือไม่
5. เก็บ event time, record time, correction time หรือไม่
6. แสดง master ที่ลบ/เปลี่ยนตามอดีตได้หรือไม่
7. ใช้ EPCIS 2.0 JSON/JSON-LD และ REST artefact ใด
8. validate extension นอกมาตรฐานอย่างไร
9. ใครอนุมัติแพ็กเกจ 24 ชั่วโมง
10. sortable data, relationship, exception, manifest ใช้ request ID เดียวกันได้หรือไม่
11. หลัง restore backup ทำ query เดิมซ้ำได้หรือไม่
12. ผู้ซื้อใส่ abnormal event ใน FAT/SAT ได้หรือไม่

ใช้ lot ที่ผู้ซื้อเลือกในการสาธิตสด เดินทั้งสองทิศทาง drill-down หนึ่ง row ถึง source record และให้ reviewer อีกคนคำนวณผลจาก export ใหม่

FAQ: RFP และการตรวจรับ Trace Forward

Trace Forward คืออะไร?

คือความสามารถเริ่มจากวัตถุดิบ ชิ้นส่วน ล็อต หรือซีเรียล แล้วตาม downstream ไปยังสินค้า หน่วยบรรจุ/โลจิสติกส์ ที่เก็บ และปลายทาง รวม transformation, split, aggregation, repacking และ return

Trace Back ต่างอย่างไร?

Trace Back ย้อนจากสินค้าสำเร็จหรือของร้องเรียนไป input, supplier และเงื่อนไข Trace Forward เริ่มจาก input ที่ต้องสงสัยไปหา output และลูกค้าที่ได้รับผล การเรียกคืนต้องเชื่อมสองทิศทาง ณ baseline เดียว

ERP ติดตามประวัติการผลิตทั้งหมดได้หรือไม่?

บางกรณีได้ แต่ transformation, split และ de-aggregation อาจอยู่ในเครื่องจักร MES WMS หรือ partner ต้องทดสอบ event ที่ต้องการด้วยข้อมูลตัวแทน ดูการกำหนดขอบเขตก่อนประเมินงบในคู่มือต้นทุนระบบ Traceability ในไทย

ติดตามปลายทางภายใน 24 ชั่วโมงเพียงพอหรือไม่?

ไม่พอ ต้องมีขอบเขต ความครบ การแสดง gap การอนุมัติ การทำซ้ำ และ output ที่เครื่องอ่านได้ ใช้ 24 ชั่วโมงตามบริบท FDA ที่เข้าเกณฑ์หรือเป็น buyer-defined gate ไม่ใช่ deadline สากล

EPCIS 2.0 ทำให้ปฏิบัติตามกฎหมายอัตโนมัติหรือไม่?

ไม่ EPCIS เป็นรูปแบบร่วมของ visibility event แต่ไม่ตัดสินกฎหมายและไม่แทน data capture, quality, retention, authorization หรือความรับผิดชอบดำเนินงาน

ควรใช้ Serial Number แทน Lot เมื่อใด?

พิจารณาระดับเรียกคืน ความสามารถกระบวนการ ฉลาก ภาระสแกน และข้อกำหนดลูกค้า เชื่อม serial/lot ด้วย packing และ aggregation event อ่านเพิ่มที่การทำ Serial Number Traceability

ควรซ้อมเรียกคืนบ่อยเพียงใด?

ไม่มีความถี่สากลในบทความนี้ ฝ่ายคุณภาพควรอิงกฎหมาย ลูกค้า ความเสี่ยง และการเปลี่ยนแปลงใหญ่ และทดสอบใหม่หลังเปลี่ยน interface หรือ warehouse อ่านการออกแบบ Recall Traceability

ข้อมูลขาดหนึ่งรายการทำให้ไม่ผ่านเสมอหรือไม่?

ความรุนแรงแต่ละ gap ไม่เท่ากัน ต้องกำหนดผลกระทบ หลักฐานทดแทน และเวลาปิดล่วงหน้า แต่ระบบที่ไม่รู้ว่าขาดและแสดงว่าครบเป็นความล้มเหลวร้ายแรง ให้แยก mandatory gate กับ improvement item

สรุป: ซื้อแพ็กเกจหลักฐาน 24 ชั่วโมงที่ตรวจสอบซ้ำได้

คุณค่าของ Trace Forward/Back คือเดินผ่าน transformation, split, aggregation, repacking ได้สองทิศทาง อธิบาย Who, What, Where, When, Why เปิดเผยจุดขาด และสร้างแพ็กเกจที่ทำซ้ำได้ทันเวลา กำหนด event graph, output, exception, authorization และ reproducibility ใน RFP ใส่ความผิดปกติใน FAT/SAT และซ้อมเรียกคืนเป็นงานจริงที่รวม partner กับ approval

แม้อยู่ในขั้นกำหนด RFP หรือ FAT/SAT โดยใช้ ERP, MES และ WMS เดิมของโรงงานไทย ก็สามารถ ติดต่อ TOMAS TECH ได้ หากแชร์ล็อตเป้าหมาย ขอบเขตกระบวนการ และรูปแบบส่งที่ต้องการ เราช่วยจัด data inventory และ acceptance scenario ได้

เอกสารอ้างอิง

• GS1 Global Traceability Standard: https://www.gs1.org/standards/gs1-global-traceability-standard/current-standard
• GS1 EPCIS 2.0.1: https://ref.gs1.org/standards/epcis/2.0.1/
• GS1 EPCIS artefacts: https://ref.gs1.org/standards/epcis/artefacts
• FDA Food Traceability Rule: https://www.fda.gov/food/food-safety-modernization-act-fsma/fsma-final-rule-requirements-additional-traceability-records-certain-foods
• FDA Tabletop Exercises report: https://www.fda.gov/media/192993/download
• FDA release, 10 June 2026: https://www.fda.gov/food/hfp-constituent-updates/fda-releases-report-traceability-readiness-tabletop-exercises-and-updated-faqs
• GS1 Global Traceability Checklist: https://www.gs1.org/standards/global-trace-check-list/current-standard
• European Commission, Digital Product Passport: https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en
• Regulation (EU) 2024/1781: https://eur-lex.europa.eu/eli/reg/2024/1781/oj
• ISO 22005:2007: https://www.iso.org/standard/36297.html

*บทความนี้เป็นข้อมูลทั่วไปสำหรับ RFP และการออกแบบตรวจรับ ไม่ใช่คำปรึกษากฎหมาย การประเมินความสอดคล้อง การรับรอง หรือคำแนะนำผลิตภัณฑ์ โปรดตรวจสอบกฎหมาย สัญญาลูกค้า และการตัดสินคุณภาพกับผู้รับผิดชอบ ตัวอย่างเวลา จำนวน KPI และคะแนนทั้งหมดเป็นสมมติฐาน*