การสอบกลับตลอดห่วงโซ่อุปทานด้วย EPCIS 2.0: RFP และการตรวจรับคู่ค้า

การสอบกลับตลอดห่วงโซ่อุปทาน (Chain Traceability) ไม่ได้เสร็จสมบูรณ์เพียงเพราะโรงงานหนึ่งค้นประวัติภายในของตนเองได้ ระบบจะใช้งานจริงได้เมื่อซัพพลายเออร์ ผู้ผลิต ผู้ให้บริการโลจิสติกส์ และลูกค้าแลกเปลี่ยนเหตุการณ์ด้วยกติกาเดียวกันสำหรับตัวระบุ คำศัพท์ เวลา และการแก้ไข พร้อมให้ผู้รับสร้างผลการสอบกลับซ้ำได้เหมือนเดิม บทความนี้แปลง GS1 EPCIS 2.0 การนำคู่ค้าเข้าสู่ระบบ RFP, PoC, FAT/SAT และการซ้อม 24 ชั่วโมงให้เป็นเกณฑ์ตรวจรับที่นำไปใช้ได้

ข้อสรุป: จัดซื้อ “ความสามารถในการสร้างผลการสอบกลับซ้ำ” ไม่ใช่แค่ฐานข้อมูลกลาง

RFP สำหรับการสอบกลับตลอดห่วงโซ่อุปทานไม่ควรจบที่ “สร้างฐานข้อมูลรวม” หรือ “ค้นหาด้วยหมายเลข Lot ได้” ผลลัพธ์ที่ต้องรับมอบคือความสามารถในการรับเหตุการณ์ข้ามบริษัท ตรวจทั้งโครงสร้างและความหมายทางธุรกิจ แล้วทำการสอบกลับย้อนหลังและการสอบกลับไปข้างหน้าซ้ำให้ได้ชุดผลลัพธ์ที่คาดหวัง

จะใช้ Repository กลาง ระบบแบบกระจาย หรือ Message Broker เป็นการเลือกสถาปัตยกรรม แต่ทุกแบบต้องตกลงคำถามหกข้อร่วมกัน

GS1 Global Traceability Standard 2.0 ระบุมิติหลักห้าข้อคือ who, what, where, when และ why ส่วน how ในบทความนี้เป็นมุมมองเพิ่มสำหรับการ Implement ไม่ใช่มิติหลักข้อที่หกของ GTS

HTTP ตอบสำเร็จและ JSON ผ่าน Schema ยังไม่เพียงพอ หากผู้ส่งใช้ระดับพาเลทแต่ผู้รับใช้ระดับกล่องโดยไม่มีความสัมพันธ์ parent-child หากหายไปซึ่ง Time Zone หากคำว่า shipping หมายถึง “วางแผนส่ง” ในบริษัทหนึ่งแต่หมายถึง “ออกจากคลังจริง” ในอีกบริษัท หรือหากการแก้ไขเขียนทับประวัติ การติดตามปลายทางก็ล้มเหลว เกณฑ์รับจึงต้องเปรียบเทียบ Expected Trace Set กับผลของผู้รับ ระบุส่วนต่างและเก็บหลักฐาน

การสอบกลับภายในต่างจากการสอบกลับตลอดห่วงโซ่อุปทานอย่างไร

Internal Traceability เชื่อมการรับเข้า จัดเก็บ เบิกใช้ แปรรูป ตรวจสอบ บรรจุ และส่งออกภายในขอบเขตการบริหารเดียว Chain Traceability เชื่อม Event ข้ามขอบเขตนั้น เช่น Dispatch กับ Receipt, Material Input กับ Production Output และหน่วยโลจิสติกส์แม่กับหน่วยลูก

ภายในบริษัท คนอาจเข้าใจว่า A-100, WH1 และ OK หมายถึงอะไร แต่คู่ค้าไม่รู้ว่า A100-R2 ของตนเป็นสินค้าเดียวกันหรือไม่ WH1 คือโรงงานหรือคลัง และ OK คือผ่านตรวจหรือพร้อมส่ง การเปิดหน้าจอภายในให้คู่ค้าดูจึงไม่ใช่ Interoperability

GS1 Global Traceability Standard 2.0 อธิบายว่าแต่ละองค์กรจัดการข้อมูล Traceability ของตนเอง และ End-to-end Traceability ต้องเข้าถึงและรวมข้อมูลจากหลายองค์กร มาตรฐานนี้เป็นกลางทางเทคโนโลยี จึงไม่บังคับว่าต้องรวมข้อมูลทั้งหมดไว้จุดเดียว หากค้นพบ เรียกใช้ ตรวจสิทธิ์ และรวม Event ที่จำเป็นได้ภายในเวลาที่กำหนด ระบบแบบกระจายก็ทำงานได้

ไม่ควรรอให้ระบบภายใน “สมบูรณ์ 100%” แล้วค่อยคุยกับคู่ค้า เพราะระดับ Lot หรือ Reason Code ที่ออกแบบฝ่ายเดียวอาจไม่ตรงหน่วยส่งของซัพพลายเออร์ วิธีที่เหมาะกว่าคือเลือกหนึ่ง Product Family และหนึ่ง Chain แล้วออกแบบ Event ภายในและข้ามบริษัทพร้อมกัน ตั้งแต่ Supplier Shipping, Receiving, Production Input, Transformation, Packing, Shipping, Logistics Handover ถึง Customer Receiving

สำหรับการควบคุมภายในที่เกี่ยวข้อง อ่านคู่มือภาษาไทยเรื่อง ระบบบริหารการเปลี่ยนแปลง 4M และ IoT Retrofit สำหรับเครื่องจักรเก่า

ใช้ GS1 EPCIS 2.0 แลกเปลี่ยนเหตุการณ์ระหว่างบริษัท

EPCIS เป็นมาตรฐาน GS1 สำหรับแทนค่า Capture และ Query Visibility Event ในห่วงโซ่อุปทาน EPCIS 2.0 รองรับ JSON/JSON-LD นอกเหนือจาก XML มี RESTful Binding สำหรับ Capture และ Query เชื่อม Sensor Observation เข้ากับ Event และมีรายละเอียดเกี่ยวกับ Authentication/Authorisation ดูได้จาก ข้อกำหนด EPCIS 2.0.1 และ Artefact ที่ GS1 เผยแพร่ เช่น OpenAPI, JSON Schema, SHACL, JSON-LD Context และ Ontology

Artefact เหล่านี้ช่วยใน RFP และการทดสอบ โดยตรวจ Payload กับ Schema และเทียบ Operation กับ OpenAPI ได้โดยไม่ต้องอ่านเฉพาะ PDF ของ Vendor แต่การผ่าน Schema ไม่ได้ยืนยันความหมายทางธุรกิจ คู่ค้าต้องตกลงด้วยว่า Shipping Event ถูก Trigger ตอนไหน และแต่ละค่า Vocabulary หมายถึงอะไร

เลือกความสัมพันธ์ของเหตุการณ์ให้ตรงกับข้อเท็จจริง

หากลูกค้ารับ SSCC ของพาเลทแต่ค้นกล่องข้างใต้ไม่ได้ Granularity ของ Trace จะขาด หาก Finished Lot ไม่เชื่อม Transformation กับ Input ก็ Trace-back ถึง Supplier Lot ไม่ได้ ในทางกลับกัน การทำ Serial ทุกชิ้นก็ไม่ใช่คำตอบเสมอไป GTS 2.0 อธิบาย Class, Batch/Lot และ Instance โดยควรเลือกระดับตามเป้าหมาย ความเสี่ยง ต้นทุน และการประสานคู่ค้า

บริหาร CBV เป็นสัญญาความหมายร่วมกัน

Core Business Vocabulary สำหรับ Business Step, Disposition และ Field ที่เกี่ยวข้องไม่ใช่เพียง Code List ฝ่าย IT ต้องกำหนด Standard Term, Extension, Mapping จากรหัสคู่ค้า, วิธีรับ Unknown Value, Owner, Version, Effective Date และ Retirement Date

Label บนหน้าจอแปลเป็นไทย อังกฤษ ญี่ปุ่น หรือเวียดนามได้ แต่ Canonical Code ที่ส่งต้องไม่ขึ้นกับภาษา ผู้รับไม่ควรต้องเดาความหมายจากข้อความแปล

สถาปัตยกรรมขั้นต่ำสำหรับการแลกเปลี่ยนเหตุการณ์ EPCIS

ภาพแสดง Supplier, Manufacturer, Logistics Provider และ Customer แลกเปลี่ยน Event ที่ได้รับอนุญาต โดยแต่ละฝ่ายยังเก็บข้อมูลของตนเอง ภาพตั้งใจไม่ใส่ Central Database เพื่อย้ำว่าเงื่อนไขสำเร็จคือ Event Contract ไม่ใช่ตำแหน่ง Repository ทั้งนี้ไม่ได้หมายความว่าห้ามใช้ฐานข้อมูลกลาง

Supplier บันทึก Object, Logistics Unit, Time, Place และ Transaction เมื่อส่ง Manufacturer รับ Object เดียวกันหรือหน่วยที่ Mapping แล้วบันทึกส่วนต่างเป็น Exception การผลิตเชื่อม Input กับ Output การบรรจุเชื่อมกล่องกับพาเลท Logistics บันทึก Handover และ Arrival ส่วน Customer บันทึก Receipt

Trace-back เริ่มจาก Finished Lot ที่สงสัย ย้อนผ่าน Transformation, Input Material และ Supplier Dispatch ส่วน Trace-forward เริ่มจาก Material Lot ผ่าน Finished Goods, Pallet, Shipment และ Destination การ Split, Aggregate, Repack, Return และ Subcontract ทำให้เส้นทางแตกแขนง รายชื่อ “หนึ่งขั้นก่อนหน้าและหนึ่งขั้นถัดไป” จึงไม่พอ

แลกเปลี่ยนตัวระบุในรูปแบบมาตรฐานกลางที่ควบคุมแล้ว

GS1 Thailand อธิบายการใช้ GTIN, GLN, SSCC เพื่อระบุ Barcode/RFID เพื่อ Capture และ EPCIS/Digital Link เพื่อ Sharing อย่างไรก็ตาม RFP ยังต้องกำหนด Check Digit, URI Form, Leading Zero, Packaging Hierarchy, การนำ ID กลับมาใช้, Mapping Local ID และการออก Label ใหม่

ข้อมูล PoC ควรรวม Leading Zero, ความยาวสูงสุด, Packaging Level หลายแบบ และ Local Lot Name ซ้ำกัน ปัญหาจริงจาก Spreadsheet มีค่ากว่าตัวอย่างที่สะอาดเพียงรายการเดียว

ใช้กติกาเวลาเดียวกัน

eventTime คือเวลาที่เหตุการณ์จริงเกิด recordTime หรือเวลา API รับคือเวลาที่ Repository บันทึก สองค่านี้ต่างกันหลัง Offline ต้องมี Time Zone Offset, Clock Source, Permitted Skew และกติกาสำหรับ Delayed/Unknown Timestamp

ห้ามเรียงประวัติจากลำดับที่รับเพียงอย่างเดียว เก็บทั้ง Event Time และ Record Time ตรวจ Future Timestamp และแยก Event ที่ลำดับขัดแย้งเพื่อสอบสวน

อย่าซ่อนการแก้ไขด้วยการเขียนทับ

การสแกนผิดและจับคู่ Lot ผิดเกิดขึ้นได้ หากผู้ส่งแก้ระเบียนที่เคยส่งอย่างเงียบ ๆ ประวัติของสองฝ่ายจะแตกต่าง ควรใช้ Error Declaration หรือวิธียกเลิกแล้วออกเหตุการณ์ใหม่โดยอ้างเหตุการณ์เดิม และเก็บว่าใครแก้อะไร เมื่อใด เพราะอะไร และคู่ค้าได้รับเมื่อใด

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

นำคู่ค้าเข้าสู่ระบบผ่านด่านตรวจสอบหกขั้น

การติดตั้งคลังข้อมูล EPCIS ยังไม่เท่ากับนำคู่ค้าเข้าสู่ระบบ แต่ละด่านต้องมีเงื่อนไขเริ่มต้น หลักฐาน การตรวจอัตโนมัติ การทบทวนทางธุรกิจ ผู้อนุมัติ และกติกาการทดสอบซ้ำ

ด่านที่ 1: จับคู่ตัวระบุ

ทำรายการสินค้า Lot หมายเลขประจำชิ้น หน่วยโลจิสติกส์ สถานที่ คู่สัญญา และธุรกรรม แล้วจับคู่ระบบตัวระบุของสองฝ่าย กำหนดผู้มีสิทธิ์ออกรหัสและอายุการใช้งาน ทดสอบเลขศูนย์นำหน้า ความยาวสูงสุด ระดับบรรจุภัณฑ์ ชื่อ Lot ภายในที่ซ้ำกัน และภาชนะหมุนเวียน

ด่านที่ 2: คำศัพท์และสถานการณ์ธุรกิจ

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

ด่านที่ 3: เวลา ลำดับ และการแก้ไข

ตกลงเขตเวลา ความละเอียด การเทียบเวลานาฬิกา ความล่าช้าที่ยอมรับได้ การปฏิเสธเหตุการณ์ที่ลงเวลาในอนาคต และผู้กำหนดเวลาบันทึก ทดสอบข้อมูลซ้ำ ข้อมูลมาผิดลำดับ การบันทึกย้อนหลัง การยกเลิก และการแก้ไขข้อผิดพลาด เกณฑ์ผ่านไม่ใช่ “ไม่เกิดข้อผิดพลาด” แต่ต้องตรวจพบ เก็บประวัติ และได้ผลเดียวกันหลังประมวลผลใหม่

ด่านที่ 4: Schema และส่วนเชื่อมต่อ

ตรวจชนิดสื่อ JSON/JSON-LD ช่องบังคับ ค่าที่อนุญาต URI หน่วย Operation ใน OpenAPI การแบ่งหน้า และคำค้นด้วยเครื่อง ทดสอบการยืนยันตัวตน การกำหนดสิทธิ์ การหมุนเวียน Certificate/Token การเก็บข้อมูลลับ ขีดจำกัดคำขอ เวลารอ การส่งซ้ำ และบันทึกตรวจสอบ พร้อมควบคุมเวอร์ชัน Extension และ Namespace ของผลิตภัณฑ์

ด่านที่ 5: ทดสอบสถานการณ์ธุรกิจ

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

ด่านที่ 6: เริ่มใช้งานจริงและติดตามผล

กำหนดค่าฐานของ Schema คำศัพท์ ตารางจับคู่ Certificate และปลายทางเชื่อมต่อที่อนุมัติแล้ว ติดตามการปฏิเสธ อายุของรายการที่พักตรวจ รหัสที่ไม่รู้จัก เวลาที่ผิดปกติ ความล่าช้าของคู่ค้า การแก้ไขที่ยังไม่มาถึง และความครบถ้วนของผลการสอบกลับ ไม่ใช่ดูแต่จำนวนเหตุการณ์

คู่ค้ารายเล็กอาจใช้พอร์ทัล ตัวแปลง CSV หรือเกตเวย์ที่มีผู้ดูแล แทนการติดตั้ง EPCIS โดยตรงได้ แต่ทุกช่องทางต้องแปลงเข้าสู่กติกาเดียวกันและผ่านการตรวจสอบเดียวกัน

สิ่งที่ต้องเขียนใน RFP

แยกความรับผิดชอบของผู้ใช้งาน ผู้ให้บริการโซลูชัน คู่ค้า ผู้กำกับตัวระบุ ผู้ดูแลโครงสร้างพื้นฐาน และฝ่ายความมั่นคงสารสนเทศ อย่าใช้ประโยคกว้างว่า “คุณภาพข้อมูลเป็นหน้าที่ลูกค้า” แต่กำหนดผู้รับผิดชอบตั้งแต่การเก็บข้อมูล การแปลง การตรวจสอบ การกระทบยอด จนถึงการอนุมัติแก้ไข

การทดสอบสมรรถนะต้องจำลองการส่งปลายเดือน การซ้อมเรียกคืน และข้อมูลที่พุ่งเข้าหลังเครือข่ายฟื้นตัว ไม่ใช่ดูเพียงปริมาณเฉลี่ย คำค้นต้องรองรับ Lot วัตถุดิบที่แตกไปยังสินค้าสำเร็จและปลายทางจำนวนมาก รวมถึงการเรียกประวัติจากคลัง การเรียงลำดับหลังฟื้นตัว การมองเห็นคิว และ Certificate หมดอายุ

ใช้ PoC เพื่อค้นหาความหมายและขั้นตอนที่ไม่ตรงกัน

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

เกณฑ์จบ PoC ที่วัดได้ควรรวม:

• สอบกลับย้อนหลังจาก Lot สินค้าสำเร็จถึง Lot วัตถุดิบที่คาดหวังทั้งหมดได้
• สอบกลับไปข้างหน้าจาก Lot วัตถุดิบถึงสินค้า หน่วยโลจิสติกส์ และปลายทางทั้งหมดได้
• ข้อมูลซ้ำไม่เพิ่มเหตุการณ์ และรหัสเดียวแต่เนื้อหาต่างกันถูกพักตรวจสอบ
• ตรวจพบ Offset ที่หาย เวลาอนาคต และความต่างระหว่าง eventTime กับ recordTime
• คำศัพท์ที่ไม่รู้จักไม่ถูกแปลงเป็นค่าเริ่มต้นอย่างเงียบ ๆ
• การแก้ไขปรับชุดผลที่มีผลโดยยังเก็บต้นฉบับ
• คำค้นข้ามสิทธิ์คู่ค้าถูกปฏิเสธและมีหลักฐานตรวจสอบ
• พนักงานคู่ค้าส่งซ้ำ แก้ไข และค้นตามคู่มือปฏิบัติการได้

ทุกประเด็นจาก PoC ต้องผูกกลับไปยัง RFP ตารางจับคู่ คำศัพท์ คู่มือปฏิบัติการ หรือสมมติฐานทางการค้า การพบปัญหามากไม่ใช่ความล้มเหลว ความเสี่ยงคือทำสัญญาโดยยังไม่พบปัญหา

ตรวจรับให้สมบูรณ์ด้วย FAT และ SAT

FAT ตรวจชุดข้อกำหนดที่ตกลงและสถานการณ์ที่ทำซ้ำได้ในสภาพแวดล้อมของผู้ส่งมอบ ส่วน SAT ใช้เครือข่าย การยืนยันตัวตน ข้อมูลหลัก อุปกรณ์ การเชื่อมต่อคู่ค้า และผู้ปฏิบัติงานในสภาพแวดล้อมใกล้เคียงการใช้งานจริง ระบบของบริษัทเดียวผ่านยังไม่ถือว่าทั้งห่วงโซ่ผ่าน

FAT ควรกำหนด EPCIS/CBV Profile, Extension Namespace, Payload ทั้งกรณีถูกและผิด ผลตรวจโครงสร้างและความหมาย ชุดผลการสอบกลับที่คาดหวัง พฤติกรรมเมื่อข้อมูลซ้ำ ล่าช้า ผิดลำดับ แก้ไข หรือผิดสิทธิ์ รูปแบบทดสอบสมรรถนะ และประเด็นค้างให้แน่นอน

SAT ต้องพิสูจน์ว่า Barcode, RFID, PLC หรือ Gateway จริงสร้างตัวระบุและ eventTime ถูกต้อง ERP/WMS/MES กระทบยอดกับ EPCIS ได้ Certificate, Token, Firewall, DNS และการเทียบเวลาใช้งานได้ การส่งซ้ำหลัง Offline ไม่สร้างรายการซ้ำ รายการพักตรวจมองเห็นได้ การแปลไม่เปลี่ยนรหัสมาตรฐานกลาง และทีมคุณภาพ โลจิสติกส์ และ IT ใช้คู่มือปฏิบัติการสอบสวนและอนุมัติได้

ขอบเขตข้อเท็จจริงของ EU DPP และ FDA

มาตรฐานไม่ใช่รูปแบบตามกฎหมายโดยอัตโนมัติ EPCIS เป็นทางเลือกที่มีประโยชน์สำหรับการแลกเปลี่ยนเหตุการณ์ แต่ไม่ควรกล่าวว่ากฎหมายทุกฉบับบังคับใช้ EPCIS

EU Digital Product Passport Registry

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

จึงไม่ควรเขียนว่า EU เก็บข้อมูลผลิตภัณฑ์ทั้งหมดไว้กลางเดียว ผลิตภัณฑ์ทุกชนิดถูกบังคับใช้ DPP แล้ว หรือ EPCIS เป็นรูปแบบ DPP ที่กฎหมายบังคับ บทเรียนเชิงออกแบบคือการทำงานร่วมกันของตัวระบุที่ไม่ซ้ำ Metadata การลงทะเบียน แบบจำลองที่เครื่องอ่านได้ การจัดการสิทธิ์ และข้อมูลแบบกระจาย

FDA Food Traceability Rule และข้อกำหนด 24 ชั่วโมง

หน้ากฎปัจจุบันของ FDA ระบุเหตุการณ์ติดตามสำคัญ (CTE) และองค์ประกอบข้อมูลหลัก (KDE) สำหรับอาหารและกิจการที่อยู่ในขอบเขต เอกสารที่กำหนดและในกรณีที่เกี่ยวข้อง ตารางอิเล็กทรอนิกส์ที่จัดเรียงได้ต้องส่งภายใน 24 ชั่วโมงหลังคำขอ หรือเวลาที่สมเหตุผลตามที่ FDA ตกลง หน้าเดียวกันระบุว่ารัฐสภาสั่งไม่ให้ FDA บังคับใช้ก่อน 20 กรกฎาคม 2028 และ FDA ตั้งใจปฏิบัติตาม ซึ่งไม่ใช่การยกเลิกกฎ

ใน การซ้อมความพร้อมด้านการสอบกลับปี 2026 ผู้เข้าร่วมต้องค้นเอกสารของผลิตภัณฑ์และช่วงวันที่ที่กำหนด แล้วจัดทำตารางอิเล็กทรอนิกส์ที่จัดเรียงได้ภายใน 24 ชั่วโมง FDA รายงานว่าการประสานห่วงโซ่อุปทานเชิงรุก มากกว่าเทคโนโลยีใดเทคโนโลยีหนึ่ง ทำให้ได้ผลดีที่สุด ข้อความนี้ไม่ได้หมายความว่า FDA บังคับหรือรับรอง EPCIS

ซ้อมติดตามปลายทางภายใน 24 ชั่วโมง

24 ชั่วโมงอาจเป็นข้อกำหนดสำหรับกรณีที่อยู่ในขอบเขต FDA แต่บทความนี้ไม่อ้างว่าเป็นกำหนดกฎหมายสากลสำหรับบริษัทไทย ให้ใช้เป็นเป้าหมายวัดความพร้อมหลังตรวจสอบกฎหมายและสัญญาลูกค้า

กำหนดเวลาเริ่ม ตัวระบุ ช่วงวันที่ ช่องข้อมูลที่ต้องส่ง รูปแบบไฟล์ และผู้อนุมัติให้ชัด แล้วให้ทีมปฏิบัติด้วยช่องทางติดต่อและคู่มือปกติ

1. บันทึกคำขอและแต่งตั้งผู้รับผิดชอบเหตุการณ์
2. กำหนดสินค้า Lot ช่วงเวลา สถานที่ และข้อยกเว้นให้แน่นอน
3. สอบกลับย้อนหลังผ่านการแปรรูป วัตถุดิบ และเหตุการณ์ของซัพพลายเออร์
4. สอบกลับไปข้างหน้าผ่านผลิตภัณฑ์ บรรจุภัณฑ์ หน่วยโลจิสติกส์ และปลายทาง
5. กระทบยอด EPCIS, ERP/WMS และคำตอบของคู่ค้า
6. สร้างไฟล์ที่จัดเรียงได้โดยควบคุมชนิดข้อมูล รหัส และเขตเวลา
7. ให้ฝ่ายคุณภาพและกำกับดูแลอนุมัติ พร้อมระบุข้อยกเว้น
8. ส่งผ่านช่องทางปลอดภัยและเก็บหลักฐานการรับภายในเป้าหมาย

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

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

ห้าจุดที่มักเสื่อมหลังเริ่มใช้งานจริง

1. ข้อมูลหลักหรือคำศัพท์เปลี่ยนโดยไม่แจ้ง: ต้องวิเคราะห์ผลกระทบ แจ้งคู่ค้า กำหนดช่วงรองรับเวอร์ชันเดิม และทดสอบซ้ำใน Sandbox
2. Certificate/Token หมดอายุ: เฝ้าระวังล่วงหน้า กำหนดผู้รับผิดชอบ และรักษา eventTime ขณะข้อมูลรอในคิว
3. รายการพักตรวจกลายเป็นคลังที่สอง: ติดตามสาเหตุ ผู้รับผิดชอบ อายุรายการที่เก่าสุด และผลประมวลผลซ้ำ
4. คู่ค้าออก ควบรวม หรือเปลี่ยนระบบ: จัดการสิทธิ์ข้อมูลเดิม ระยะเก็บ การส่งออก และการสืบทอดตัวระบุ
5. คิดว่าผ่านครั้งเดียวแล้วใช้ได้ตลอด: ทดสอบการสอบกลับ กรณีผิด การแก้ไข สิทธิ์ และการกู้คืนหลังการเปลี่ยนแปลงสำคัญ

คำถามที่พบบ่อยเกี่ยวกับการสอบกลับตลอดห่วงโซ่อุปทาน

การสอบกลับตลอดห่วงโซ่อุปทานคืออะไร

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

มีการสอบกลับภายในแล้วเพียงพอหรือไม่

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

EPCIS 2.0 เป็นข้อบังคับหรือไม่

ไม่ใช่สำหรับทุกบริษัทหรือทุกกฎหมาย แต่เป็นตัวเลือกที่มีประโยชน์สำหรับการทำงานร่วมกัน ด้วย JSON/JSON-LD, REST, คำศัพท์ร่วม Artefact สำหรับตรวจสอบ และบริบท Sensor หากยังใช้ EDI พอร์ทัล หรือไฟล์ ต้องแปลงเข้าสู่แบบจำลองเหตุการณ์เดียวกันได้อย่างน่าเชื่อถือ

การสอบกลับไปข้างหน้าต่างจากการสอบกลับย้อนหลังอย่างไร

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

ทำอย่างไรให้ติดตามปลายทางได้ภายใน 24 ชั่วโมง

ต้องซ้อมทั้งการกำหนดขอบเขต การติดต่อคู่ค้า การกระทบยอด EPCIS กับ ERP/WMS การตัดสินข้อยกเว้น การส่งออกไฟล์ที่จัดเรียงได้ การอนุมัติ และการส่งอย่างปลอดภัย และต้องตรวจว่ากำหนด 24 ชั่วโมงใช้ตามกฎหมายกับผลิตภัณฑ์และเขตอำนาจของคุณหรือไม่

หากคู่ค้าทำ EPCIS ไม่ได้ควรทำอย่างไร

ใช้พอร์ทัล แบบ CSV เกตเวย์ที่มีผู้ดูแล หรือการแปลง EDI ได้ แต่ต้องแปลงเข้าสู่ตัวระบุ คำศัพท์ เวลา และกติกาการแก้ไขเดียวกัน พร้อมผ่านด่านตรวจสอบเดียวกัน

ควรแบ่งบทบาทของ PoC, FAT และ SAT อย่างไร

PoC เป็นกิจกรรมก่อนทำสัญญาเพื่อค้นหาความหมายที่ไม่ตรงกัน ตรวจความเป็นไปได้ทางเทคนิค และประเมินภาระของคู่ค้า จากนั้น FAT ใช้ยืนยันข้อกำหนดที่ตกลงและกรณีผิดปกติในสภาพแวดล้อมที่ผู้ส่งมอบควบคุม ส่วน SAT ใช้ปิดการตรวจรับด้วยเครือข่าย อุปกรณ์ ข้อมูลหลัก การเชื่อมต่อคู่ค้า และผู้ปฏิบัติงานจริงในสภาพแวดล้อมใกล้เคียงการใช้งานจริง

สรุป: สิ่งที่ต้องแชร์คือสัญญาที่ตรวจสอบได้ ไม่ใช่แค่ฐานข้อมูล

การสอบกลับตลอดห่วงโซ่อุปทานสำเร็จเมื่อ who, what, when, where, why และรายละเอียดวิธีดำเนินการของ how ถูกแลกเปลี่ยนภายใต้ตัวระบุ คำศัพท์ เวลา และกติกาแก้ไขร่วมกัน และผู้รับสร้างผลการสอบกลับย้อนหลังและไปข้างหน้าซ้ำได้

EPCIS 2.0 และ CBV 2.0 เป็นฐานที่ใช้งานได้ผ่าน JSON/JSON-LD, REST คำศัพท์ บริบท Sensor และ Artefact สำหรับตรวจสอบ แต่ไม่แทนการตกลงความหมายหรือรับประกันการปฏิบัติตามกฎหมาย จัดการการนำคู่ค้าเข้าสู่ระบบผ่านด่านตรวจสอบ เขียน RFP ให้มีสิ่งส่งมอบและผู้รับผิดชอบ ใช้ PoC ค้นหาความไม่ตรงกัน และรับความสามารถในการทำซ้ำด้วย FAT/SAT กับการซ้อมจับเวลา

TOMAS TECH สามารถช่วยจัดทำบัญชีเหตุการณ์ EPCIS/CBV Profile ขั้นตอนนำคู่ค้าเข้าสู่ระบบ RFP, PoC และ FAT/SAT โดยเชื่อมกับ ERP, WMS และ MES เดิม เริ่มหารือได้ตั้งแต่ก่อนเลือกผลิตภัณฑ์หรือทดลองกับกลุ่มผลิตภัณฑ์เดียวผ่าน หน้าติดต่อภาษาไทย

แหล่งข้อมูลปฐมภูมิ

• GS1 Global Traceability Standard 2.0
• GS1 EPCIS overview
• GS1 EPCIS Standard 2.0.1
• GS1 EPCIS / CBV artefacts
• GS1 Thailand: Traceability
• European Commission: DPP Registry
• European Commission: Digital Product Passport
• FDA: Food Traceability Rule
• FDA: Traceability Readiness Exercises