Serial Number Tracking คืออะไร: ติดตามสินค้าและชิ้นส่วนระดับรายชิ้น

การรู้ว่าสินค้า 100 ชิ้นอยู่ในคลัง ไม่ได้แปลว่าองค์กรรู้ว่า “ชิ้นใด” ถูกส่งให้ลูกค้ารายใด ผ่านการตรวจเมื่อไร หรือเคยซ่อมอะไร หากสินค้าแต่ละชิ้นมีอายุ ประวัติ การรับประกัน หรือความเสี่ยงต่างกัน การติดตามระดับ Lot อาจยังหยาบเกินไป Serial Number Tracking จึงใช้ตัวระบุไม่ซ้ำเพื่อเชื่อมเหตุการณ์ตลอดวงจรชีวิตของแต่ละชิ้น

คำตอบสั้น: Serial Number Tracking คือการกำหนดหมายเลขเฉพาะให้สินค้า ชิ้นส่วน หรือทรัพย์สินแต่ละหน่วย แล้วบันทึก Event เช่น ผลิต ตรวจ รับเข้า ย้าย ประกอบ ส่งมอบ คืน และซ่อม ระบบต้องควบคุม Serial ไม่ให้ซ้ำ กำหนดสถานะและสิทธิ์ให้ชัด และเชื่อม Barcode/RFID กับฐานข้อมูลโดยไม่ใช้ Serial เป็นเพียงข้อความที่สแกนแล้วจบ

ประเด็นสำคัญที่ควรรู้

• SKU บอกประเภทสินค้า, Lot บอกกลุ่มการผลิต, Serial Number บอกตัวตนของหนึ่งชิ้น
• Serial มีประโยชน์เมื่อองค์กรต้องรู้ Chain of custody, ประวัติซ่อม, การรับประกัน หรือความสัมพันธ์ระหว่าง Component กับ Finished good
• ความไม่ซ้ำต้องถูกควบคุมจากแหล่งกำเนิดและตรวจซ้ำทุกจุดรับข้อมูล
• Barcode หรือ RFID เป็นวิธี Capture; ความถูกต้องของ Traceability อยู่ที่ Event, Master data และ Integration
• ไม่จำเป็นต้อง Serialise ทุกชิ้น ควรเลือกระดับตามความเสี่ยง มูลค่าข้อมูล และภาระการปฏิบัติงาน

สารบัญ

1. Serial Number Tracking คืออะไร
2. Serial ต่างจาก SKU, Lot และ Asset ID อย่างไร
3. Workflow และข้อมูลที่ต้องเก็บ
4. Barcode/RFID และสถาปัตยกรรมระบบ
5. วิธีเริ่ม Implementation
6. Best Practice และ Troubleshooting

Serial Number Tracking คืออะไร

Serial Number Tracking คือการติดตาม Object ระดับ Instance หรือรายชิ้น โดยแต่ละชิ้นมี Identifier ที่ไม่ซ้ำภายใน Scope ที่กำหนด GS1 Global Traceability Standard แยกระดับการระบุเป็น Class, Batch/Lot และ Instance; ระดับ Instance ช่วยแยกวัตถุที่เป็นชนิดเดียวกันออกจากกันและเชื่อม Observations ของชิ้นนั้นข้ามเวลาได้

ตัวอย่างเช่น Notebook รุ่นเดียวกัน 20 เครื่องมี SKU เดียวกัน แต่มี Serial ต่างกัน หากเครื่องหนึ่งส่งซ่อม ระบบต้องรู้ประวัติของเครื่องนั้นโดยไม่กระทบอีก 19 เครื่อง ในการผลิต Motor หนึ่งตัวอาจมี Serial ของ Finished good และบันทึก Serial ของ Component สำคัญที่ประกอบอยู่ภายใน ทำให้ย้อนกลับได้ทั้งทางขึ้นและลงของโครงสร้าง

Serial ไม่ได้เท่ากับ Barcode บาร์โค้ดเป็น Data carrier ที่ช่วย Capture ค่า Serial โดยรวดเร็ว ระบบยังต้อง Validate, เก็บ Event และตัดสิน Business rule ดูพื้นฐานการติดตามโรงงานได้จาก Barcode Traceability ในโรงงาน

ในสายการผลิต Event ระดับ Serial ควรเชื่อมกับผลผลิตและสถานีตามแนวทาง Production Tracking ด้วย Barcode เพื่อให้หมายเลขแต่ละชิ้นมีบริบทมากกว่าการเป็นรายการรหัสแยกกัน

Serial ต่างจาก SKU, Lot และ Asset ID อย่างไร

หนึ่งวัตถุอาจมีหลาย Identifier แต่ต้องรู้บทบาท เช่น เครื่องจักรอาจมี Manufacturer serial และ Asset ID ภายในองค์กร การเก็บทั้งสองค่าไม่ใช่ปัญหา หากมี Mapping และ Owner ชัดเจน ปัญหาเกิดเมื่อระบบใช้ค่าเหล่านี้แทนกันโดยไม่กำหนด Scope

เปรียบเทียบ Batch เพิ่มเติมที่ Batch Tracking ด้วย Barcode และ Lot Tracking คืออะไร

Decision Guide: ควรติดตามระดับไหน

ใช้ Serial-level เมื่ออย่างน้อยหนึ่งเงื่อนไขต่อไปนี้สำคัญ:

• ต้องตรวจสอบ Chain of custody ของแต่ละชิ้น
• การรับประกันและการซ่อมอ้างอิงรายเครื่อง
• Component สำคัญต้องเชื่อมกับ Finished good
• สินค้าแต่ละชิ้นมี Configuration หรือ Calibration ต่างกัน
• กฎอุตสาหกรรมหรือข้อกำหนดลูกค้าต้องการ Instance-level
• ความเสียหายของหนึ่งชิ้นต้องแยกออกโดยไม่หยุดทั้ง Lot

หากกระบวนการตัดสินใจระดับ Lot เพียงพอ การ Serialise ทุกชิ้นจะเพิ่มจำนวน Scan, Storage และ Exception โดยไม่จำเป็น

Workflow และข้อมูลที่ต้องเก็บ

Critical Tracking Events ตัวอย่าง

Commission/Create serial → Print/encode → Apply label → Verify
→ Receive material → Consume/assemble → Quality test
→ Pack/aggregate → Ship → Receive → Install/use
→ Return/repair → Retire

ทุก Event ควรตอบคำถาม: Serial ใด, เกิดอะไร, เมื่อใด, ที่ใด, กับ Work order/Order ใด และใครหรือระบบใดบันทึก ข้อมูลดังกล่าวควรเป็น Immutable audit trail หรือมีประวัติการแก้ไข ไม่ควรเขียนทับสถานะล่าสุดแล้วทิ้งอดีตทั้งหมด

Data model ขั้นต่ำ

• serial_id และ namespace/issuer
• product_id หรือ SKU
• lot_id หากต้องเชื่อมกับ Batch
• status ปัจจุบัน พร้อม State transition ที่อนุญาต
• location, owner/custodian และ last event
• work_order, production line, timestamp และ operator/device
• parent_serial / child_serial สำหรับ Assembly genealogy
• Quality result, repair history และ retirement reason ตาม Scope

Arc Tech Expert Tip: อย่าใช้ Serial string เป็น Primary key ทางเทคนิคโดยไม่พิจารณา Namespace เพราะ Supplier สองรายอาจออกค่าเหมือนกัน ควรสร้าง Internal immutable ID และกำหนดความไม่ซ้ำแบบ issuer + serial หรือมาตรฐานที่องค์กรเลือก

State machine ป้องกันข้อมูลย้อนแย้ง

ตัวอย่างสถานะ created → produced → quality_passed → packed → shipped ควรมี Transition rule ระบบต้องปฏิเสธการ Ship Serial ที่ยังไม่ผ่าน Quality หรือแจ้งเตือนเมื่อ Serial เดียวถูกสแกนเข้า Packing สอง Order การเก็บเพียงข้อความสถานะโดยไม่มี Rule ทำให้ Traceability ดูครบแต่เชื่อถือไม่ได้

Barcode, RFID และสถาปัตยกรรมระบบ

เลือก Data carrier

เทคโนโลยีสามารถใช้ร่วมกันได้ เช่น พิมพ์ Data Matrix ที่มี Serial และติด UHF Tag ซึ่งผูกกับ Serial เดียวกัน Barcode เป็น Fallback สำหรับ Exception ส่วน RFID ช่วย Bulk read แต่ Mapping ต้องมีแหล่งจริงเพียงหนึ่งเดียว

สถาปัตยกรรมแนะนำ

Printer/Encoder → Verification → Scanner/Handheld/Reader
→ Edge/Mobile App validation → Traceability service
→ MES/WMS/ERP/QMS/Service system ผ่าน API
→ Event store + Master data + Audit/Analytics

Mobile Application ควร Validate รูปแบบและตรวจ Server ตามระดับความเสี่ยง หาก Offline ต้อง Queue Event พร้อม Device ID, timestamp และ unique event ID เมื่อ Sync ระบบต้องใช้ Idempotency เพื่อไม่สร้าง Event ซ้ำ แนวทางเชื่อมอุปกรณ์อยู่ใน Handheld เชื่อม ERP และ API

วิธีเริ่ม Implementation

1. กำหนดคำถามธุรกิจ

เริ่มจากคำถาม เช่น “Component Serial ใดอยู่ในสินค้าชิ้นที่ลูกค้าส่งคืน” หรือ “Serial นี้ผ่านสถานีทดสอบใดและผลเป็นอย่างไร” ถ้าระบบตอบคำถามไม่ได้ แม้มี Serial ครบก็ยังไม่เกิด Traceability

2. ระบุ Scope และ Identifier governance

กำหนดสินค้า/ชิ้นส่วน จุดออก Serial โครงสร้าง ความยาว Character set และเจ้าของ Namespace ห้ามให้หลายระบบออก Serial ชุดเดียวกันโดยไม่มี Coordinator

3. Map Event และ Failure mode

วาด Workflow ปกติและ Exception: ฉลากเสีย พิมพ์ซ้ำ Rework Split/Merge เปลี่ยน Component คืนสินค้า และ Scrap แต่ละเหตุการณ์ต้องมี SOP และสิทธิ์ผู้อนุมัติ

4. เลือกอุปกรณ์และ Integration

เลือก Printer/Verifier, Scanner หรือ Handheld สำหรับองค์กร ตามจุดใช้งาน จากนั้นทดสอบ API, Offline และ Business rule end-to-end

5. Pilot และ Reconciliation

Pilot หนึ่ง Product family และ Work center วัด Duplicate rate, Missing event, Scan time, Manual override และเวลาสืบย้อน แล้วทำ Reconciliation ระหว่าง Physical object กับ System ก่อนขยาย

Checklist ก่อน Go-live

• Serial generation มี Owner และ Backup plan
• รูปแบบฉลากอ่านได้ตลอด Lifecycle
• Printer reprint/void ถูกควบคุม
• Duplicate scan และ Duplicate serial ถูกปฏิเสธ
• Parent-child genealogy ตรวจได้ทั้งสองทิศทาง
• Offline event Sync แล้วไม่ซ้ำ
• User role แยก Create, Reprint, Override และ Retire
• Backup/restore และ Audit log ผ่านการทดสอบ
• KPI และทีมรับผิดชอบ Exception ชัดเจน

Case Study แบบย่อ: โรงงานสมมติใช้ Serial กับ Finished good แต่ไม่ได้เก็บ Component relation เมื่อลูกค้าส่งคืนจึงรู้เฉพาะเครื่องปลายทาง หลังปรับสถานี Assembly ให้สแกน Component serial และ Finished serial เป็นคู่ พร้อม Rule ป้องกัน Component เดียวอยู่สองเครื่อง ทีมสามารถค้น Genealogy ได้ แต่ต้องเพิ่ม Exception flow สำหรับการเปลี่ยนชิ้นส่วนระหว่าง Rework เพื่อไม่ให้ข้อมูลเดิมค้าง

Best Practice และ Troubleshooting

Common Mistakes

• สร้าง Serial จาก Excel หลายไฟล์จนค่าอาจซ้ำ
• พิมพ์ซ้ำโดยไม่ Void ฉลากเดิม
• เก็บเฉพาะสถานะล่าสุด ไม่มี Event history
• Scan แล้ว Beep แต่ไม่ตรวจว่า Server รับ Transaction สำเร็จ
• ไม่กำหนด Timezone และเวลาอุปกรณ์ ทำให้ลำดับ Event สับสน
• Serialise ทุกอย่างโดยไม่ประเมินภาระและคุณค่าของข้อมูล

Troubleshooting

พบ Serial ซ้ำ: Quarantine วัตถุที่เกี่ยวข้อง ตรวจ Issuer/Print log และห้ามแก้ด้วยการเติมตัวอักษรหลังจากผลิตแล้วโดยไม่มี Audit

Event หายระหว่าง Offline: ตรวจ Queue persistence, Retry policy และ Event ID อย่าให้ผู้ใช้สร้างรายการใหม่แทนรายการค้างโดยไม่ Reconcile

Genealogy ไม่ตรง: ตรวจ Rework, Component replacement, Split/Merge และ Transaction order สร้างรายงาน Orphan parent/child เป็นประจำ

สแกน Serial ได้แต่ค้นไม่พบ: แยกปัญหา Decode, Format, Namespace และ Master data อาจเป็นฉลากของ Supplier ที่ยังไม่ถูก Register

ลำดับ Event ย้อนเวลา: บันทึกทั้ง device time และ server received time พร้อม Timezone และนโยบาย Clock synchronization

ประเด็นสำคัญสำหรับการตัดสินใจ

Serial Number Tracking ทำให้ Traceability ละเอียดถึงแต่ละชิ้น เหมาะกับสินค้าและชิ้นส่วนที่ต้องมีประวัติ การรับประกัน การซ่อม หรือ Genealogy แต่ความสำเร็จขึ้นกับ Identifier governance, Event model, State rule และการเชื่อมระบบ ไม่ใช่การพิมพ์ Serial ลงฉลากเท่านั้น

หากต้องการออกแบบ Serial Tracking ที่เชื่อม Scanner, Handheld, Printer และ Software ทีม Arc Tech พร้อมช่วยวิเคราะห์ Workflow ตั้งแต่จุดสร้างรหัสจนถึง After-sales และออกแบบ Pilot ผ่าน Arc Tech Industrial Digital Solutions โดยเริ่มจากคำถามธุรกิจและข้อมูลที่ต้องตรวจสอบย้อนหลัง

FAQ

Beginner

Serial Number เหมือน SKU หรือไม่?
ไม่เหมือน SKU ระบุประเภทสินค้า ส่วน Serial แยกสินค้าแต่ละชิ้นภายในประเภทเดียวกัน

Serial Number จำเป็นต้องเป็นตัวเลขเท่านั้นหรือไม่?
ไม่จำเป็น อาจเป็นตัวอักษรและตัวเลข แต่ต้องกำหนด Character set รูปแบบ และความไม่ซ้ำให้ชัด

Business

ต้องติดตาม Serial ทุกสินค้าไหม?
ไม่ต้อง เลือกตามความเสี่ยง Lifecycle และคำถามที่ต้องตอบ ระดับ Lot อาจเพียงพอสำหรับบางรายการ

Manufacturing

Serial Tracking ช่วย Trace component ได้อย่างไร?
บันทึก Parent-child relation ตอน Assembly และอัปเดตเมื่อ Rework ทำให้ค้น Component ที่อยู่ใน Finished good แต่ละชิ้นได้

Technical

Barcode แบบใดเหมาะกับ Serial?
ขึ้นกับพื้นที่ ฉลาก มาตรฐาน และเครื่องอ่าน Code 128/GS1-128 และ Data Matrix เป็นตัวเลือกที่พบบ่อย แต่ต้องทดสอบคุณภาพจริง

ควรให้ ERP หรือ MES ออก Serial?
ไม่มีคำตอบเดียว ต้องกำหนด System of record ตามกระบวนการและควบคุมไม่ให้สองระบบออกค่าใน Namespace เดียวกัน

Buying Guide

ต้องใช้ Handheld หรือ Fixed scanner?
Handheld ยืดหยุ่นกับงานคน ส่วน Fixed scanner เหมาะกับจุดอัตโนมัติ เลือกตาม Cycle time และ Layout

Troubleshooting

พิมพ์ฉลาก Serial ผิดควรทำอย่างไร?
Void ฉลากเดิม บันทึกเหตุผลและผู้อนุมัติ แล้ว Reprint ผ่านกระบวนการควบคุม ห้ามทิ้งฉลากผิดโดยไม่มี Record

บทความที่เกี่ยวข้อง

• Lot Tracking คืออะไร
• Batch Tracking ด้วย Barcode
• Barcode Traceability ในโรงงาน
• Handheld เชื่อม ERP และ API

แหล่งอ้างอิง

• GS1 Global Traceability Standard
• GS1 Global Traceability Standard Reference
• GS1 Digital Signatures Standard