Batch Tracking ด้วย Barcode: วางระบบติดตามล็อตให้ตรวจสอบย้อนกลับได้จริง
การติดตามสินค้าเป็นล็อต (Batch หรือ Lot) ไม่ได้เริ่มจากการพิมพ์บาร์โค้ดให้สแกนได้เท่านั้น แต่เริ่มจากการกำหนดว่า “ล็อตนี้คืออะไร” และทุกจุดในกระบวนการต้องบันทึกความสัมพันธ์กับล็อตเดิมอย่างสม่ำเสมอ ตั้งแต่วัตถุดิบ รับเข้า ผลิต ตรวจคุณภาพ จัดเก็บ จนถึงส่งมอบ บทความนี้อธิบายวิธีออกแบบ Batch Tracking ด้วย Barcode ให้ทีมปฏิบัติการค้นหาย้อนกลับได้จริง และนำข้อมูลไปใช้ตัดสินใจเมื่อเกิดข้อร้องเรียนหรือการกักกันสินค้า
คำตอบสั้น: ระบบ Batch Tracking ที่ใช้งานได้จริงต้องมีรหัสสินค้าที่ชัดเจน รหัสล็อตที่ไม่ซ้ำตามกติกาธุรกิจ จุดสแกนที่ผูกกับเหตุการณ์ และข้อมูลที่เชื่อม input กับ output ของการผลิต เมื่อสแกน ณ จุดรับเข้า ผลิต ย้ายคลัง หรือส่งออก ระบบจึงตอบได้ว่าล็อตหนึ่งมาจากไหน ถูกใช้กับงานใด อยู่ที่ใด และไปถึงปลายทางใดบ้าง
ประเด็นสำคัญที่ควรรู้
- Batch Tracking เหมาะกับการติดตาม “กลุ่มสินค้า” ที่ผลิต รับเข้า หรือควบคุมคุณภาพร่วมกัน ไม่ใช่การระบุตัวสินค้ารายชิ้นแบบ Serial Number
- บาร์โค้ดเป็นช่องทางรับข้อมูลหน้างาน ส่วนความสามารถในการตรวจสอบย้อนกลับเกิดจากกติกาข้อมูลและเหตุการณ์ที่ระบบเก็บไว้
- ต้องบันทึกความสัมพันธ์ระหว่างวัตถุดิบ ล็อตระหว่างผลิต และสินค้าสำเร็จรูป มิฉะนั้นจะค้นหาได้เพียงตำแหน่งปัจจุบัน ไม่ใช่การ trace ได้ครบเส้นทาง
- เริ่มจาก Critical Tracking Events ที่มีความเสี่ยงต่อธุรกิจ เช่น รับวัตถุดิบ ปล่อยงานผลิต QC กักกัน ย้ายคลัง และส่งมอบ ก่อนเพิ่มจุดสแกนอื่น
- ควรทดสอบด้วยสถานการณ์จริงอย่าง “ต้องกักกันล็อตหนึ่ง” แล้ววัดเวลาที่ใช้ค้นหา ปริมาณที่ได้รับผลกระทบ และรายการปลายทางที่ระบบแสดงได้
สารบัญ
- Batch Tracking คืออะไร
- Batch ต่างจาก Lot และ Serial Number อย่างไร
- ข้อมูลขั้นต่ำที่ระบบต้องมี
- ออกแบบ Barcode และจุดสแกน
- Workflow ตัวอย่างตั้งแต่รับเข้าไปจนถึงส่งมอบ
- เชื่อม Barcode กับ ERP, WMS หรือระบบผลิต
- ข้อผิดพลาดและ checklist ก่อนเริ่ม
Batch Tracking คืออะไร
Batch Tracking คือการเก็บประวัติของสินค้าในระดับ “ล็อต” เพื่อให้รู้ว่าสินค้ากลุ่มใดมีที่มา ผ่านขั้นตอนใด อยู่ที่ใด และถูกส่งต่อไปที่ใด ไม่จำเป็นต้องเหมือนกันทุกอุตสาหกรรม: ล็อตอาจหมายถึงวัตถุดิบจากผู้ส่งมอบหนึ่งครั้ง ชุดผลิตหนึ่งกะ ผลิตภัณฑ์ที่ผ่านเงื่อนไขกระบวนการเดียวกัน หรือชุดสินค้าที่ได้รับการตรวจคุณภาพพร้อมกัน
มาตรฐาน GS1 อธิบายการระบุระดับล็อตว่าเป็นการใช้รหัสสินค้า ร่วมกับ Batch/Lot ID เพื่อแยกสินค้าชนิดเดียวกันคนละล็อตออกจากกัน ต่างจากการระบุระดับ Serial ที่แยกรายชิ้นได้อย่างเฉพาะเจาะจง GS1 Global Traceability Standard จึงเป็นหลักคิดที่ดีในการเริ่มกำหนดระดับของข้อมูล ไม่ใช่รูปแบบบาร์โค้ดสำเร็จรูปที่ใช้ได้กับทุกโรงงาน
สำหรับภาพรวมการตรวจสอบย้อนกลับและเหตุการณ์ที่ควรบันทึก อ่านต่อได้ที่ Traceability คืออะไร และ ระบบ Traceability ในโรงงานด้วย Barcode
Batch ต่างจาก Lot และ Serial Number อย่างไร
ในงานจริงคำว่า Batch และ Lot มักใช้แทนกันได้เมื่อหมายถึงกลุ่มที่ต้องติดตามร่วมกัน แต่ทีมต้องนิยามให้ชัดใน Data Dictionary ขององค์กร เช่น Batch อาจเกิดจากคำสั่งผลิต ส่วน Lot อาจเป็นรหัสจากผู้ส่งมอบ การปล่อยให้แต่ละแผนกตีความต่างกันทำให้ข้อมูลเชื่อมกันไม่ได้ แม้สแกนบาร์โค้ดครบทุกจุดแล้วก็ตาม
| ระดับการระบุ | ตอบคำถามได้ | เหมาะกับ | ข้อควรระวัง |
|---|---|---|---|
| Product/Class | สินค้าคือชนิดใด | นับสต็อกทั่วไป | แยกสินค้าชนิดเดียวกันคนละรอบไม่ได้ |
| Batch/Lot | กลุ่มนี้ผลิตหรือรับเข้ารอบใด | วัตถุดิบ อาหาร เคมี ชิ้นส่วน และสินค้าควบคุมคุณภาพ | หลายหน่วยในล็อตเดียวกันอาจอยู่คนละตำแหน่งได้ |
| Serial | ชิ้นนี้คือชิ้นใด | อุปกรณ์มูลค่าสูง งานซ่อม หรือสินค้าที่ต้องติดตามรายชิ้น | ภาระการติดฉลากและบันทึกข้อมูลสูงกว่า |
การเลือกระดับจึงต้องเริ่มจากคำถามที่องค์กรต้องตอบเมื่อมีปัญหา หากต้องการรู้ว่าชิ้นส่วนใดถูกใช้ในสินค้าสำเร็จรูปชุดใด Batch/Lot มักเพียงพอ แต่หากต้องแยกประวัติของอุปกรณ์แต่ละชิ้น อาจต้องใช้ Serial ร่วมด้วย ไม่ควรบังคับใช้ Serial กับทุกกระบวนการโดยไม่มีเหตุผลทางความเสี่ยงและการปฏิบัติงาน
ข้อมูลขั้นต่ำที่ระบบต้องมี
บาร์โค้ดที่อ่านได้แต่ไม่มีบริบทจะไม่ช่วยให้ trace ย้อนกลับได้ ระบบควรมี master data และ event data ที่เชื่อมกัน โดยอย่างน้อยประกอบด้วย:
- รหัสสินค้าและชื่อหน่วยนับที่ใช้จริง
- Batch/Lot ID พร้อมกติกาการออกเลขและสถานะ เช่น usable, hold, rejected หรือหมดอายุ
- รหัสวัตถุดิบหรือส่วนประกอบที่เข้าไปในงานผลิต และปริมาณที่ตัดใช้
- เอกสารอ้างอิง เช่น ใบรับเข้า คำสั่งผลิต ใบโอน หรือเลขที่ส่งมอบ
- เวลา จุดปฏิบัติงาน ตำแหน่ง ผู้ปฏิบัติงานหรืออุปกรณ์ที่สร้างเหตุการณ์
- ความสัมพันธ์ input-to-output เมื่อมีการแปรรูป แบ่งบรรจุ รวมล็อต หรือแยกล้อต
GS1 เรียกเหตุการณ์สำคัญว่า Critical Tracking Events และเรียกข้อมูลที่อธิบายเหตุการณ์ว่า Key Data Elements ตัวอย่างเช่น receiving, packing, shipping, สถานที่ และเวลาของเหตุการณ์ GS1 Traceability แนวทางนี้ช่วยให้ทีมเริ่มจากข้อมูลที่มีประโยชน์ต่อการตรวจสอบ ไม่ใช่เก็บทุกฟิลด์เพียงเพราะสแกนเนอร์ส่งค่าได้
ออกแบบ Barcode และจุดสแกน
1. กำหนดรหัสก่อนเลือกรูปแบบสัญลักษณ์
ให้ระบุว่า label ต้องบรรจุข้อมูลอะไรบ้างก่อน เช่น รหัสสินค้า Batch/Lot ID วันที่เกี่ยวข้อง และหน่วยบรรจุ หากต้องแลกเปลี่ยนข้อมูลตามมาตรฐาน GS1 การใช้ Application Identifier สามารถทำให้ความหมายของข้อมูลแต่ละส่วนชัดเจน เช่น AI (10) สำหรับ Batch/Lot ตาม GS1 Logistic Label Guideline แต่การใช้รูปแบบใดควรตรวจความสามารถของระบบเดิม เครื่องพิมพ์ และอุปกรณ์สแกนร่วมกัน
2. แยก label ตามหน่วยที่เกิดเหตุการณ์
สินค้าชิ้นย่อย กล่อง และพาเลทอาจต้องใช้รหัสคนละบทบาท หากนำเลขล็อตเดียวไปติดทุกกล่องโดยไม่บันทึกความสัมพันธ์ของการรวม/แยกหน่วย ระบบจะรู้เพียงล็อต แต่ไม่รู้ว่ากล่องใดถูกส่งไปกับพาเลทใด ในงานที่ต้องติดตาม logistic unit ควรออกแบบความสัมพันธ์ระหว่างกล่องกับหน่วยขนส่งให้ค้นย้อนหลังได้
3. วางจุดสแกนให้สอดคล้องกับการตัดสินใจ
จุดสแกนที่มีคุณค่ามักอยู่ก่อนหรือหลังจุดที่เปลี่ยนสถานะ เช่น รับวัตถุดิบเข้าคลัง เบิกเข้าคำสั่งผลิต รับผลผลิต เข้าจุด QC กักกัน ปล่อยใช้ ย้ายตำแหน่ง และโหลดขึ้นรถ ไม่จำเป็นต้องเพิ่มจุดสแกนที่สร้างภาระ แต่ต้องไม่มีช่องว่างในเส้นทางที่ทำให้ตอบไม่ได้ว่าล็อตเปลี่ยนมือหรือสถานะเมื่อใด
การเลือกอุปกรณ์ควรทดสอบกับ label จริง ระยะสแกน แสง ฝุ่น ถุงมือ และจังหวะงานของหน้างาน ไม่ใช่ทดสอบเฉพาะในสำนักงาน ดูเกณฑ์พื้นฐานได้จาก ข้อกำหนด Scanner สำหรับโรงงาน และ สินค้าและโซลูชัน Scanner
Workflow ตัวอย่างตั้งแต่รับเข้าไปจนถึงส่งมอบ
ตัวอย่างต่อไปนี้เป็น workflow สำหรับโรงงานที่รับวัตถุดิบ ผลิตเป็นสินค้าสำเร็จรูป และจัดส่งผ่านคลัง ควรปรับตามกติกา QC และเอกสารขององค์กร
- รับเข้า: สแกนรหัสสินค้าและ Batch/Lot จากผู้ส่งมอบ ตรวจรับจำนวน แล้วสร้างเหตุการณ์ receiving พร้อมตำแหน่งรับเข้าและเอกสารอ้างอิง
- จัดเก็บและเบิกใช้: สแกนล็อตขณะ put-away และสแกนอีกครั้งเมื่อตัดใช้กับคำสั่งผลิต ระบบต้องป้องกันการเลือกล็อตที่ถูก hold หรือไม่ตรงกับข้อกำหนดของงาน
- ผลิตและบรรจุ: บันทึกความสัมพันธ์ระหว่างล็อตวัตถุดิบกับ Batch ของสินค้าระหว่างผลิต/สินค้าสำเร็จรูป เมื่อแบ่งหรือรวมล็อต ต้องเก็บ parent-child relationship แทนการเขียนทับประวัติเดิม
- ตรวจคุณภาพ: สแกนเพื่อผูกผลตรวจ สถานะ hold/release และเหตุผลการไม่ผ่านกับล็อตที่ถูกต้อง การเปลี่ยนสถานะต้องมีผู้รับผิดชอบและเวลา
- คลังและส่งมอบ: สแกนล็อตหรือหน่วยขนส่งระหว่างย้าย หยิบ แพ็ก และส่งออก เพื่อให้ตอบได้ว่าล็อตเดียวกันกระจายอยู่ตำแหน่งใดและถูกส่งไปในเอกสารใด
- ค้นหาเหตุการณ์: เมื่อพบข้อผิดพลาด ให้ค้นหาย้อนกลับจากล็อตสินค้าสำเร็จรูปไปหาวัตถุดิบ และค้นหาไปข้างหน้าจากล็อตวัตถุดิบไปยังสินค้าสำเร็จรูป/เอกสารส่งมอบ โดยไม่แก้ไข event เดิม
การออกแบบ Work Order และ event model มีผลโดยตรงกับขั้นตอนนี้ โดยเฉพาะเมื่อสถานะงานและการตัดใช้ต้องเชื่อมกัน อ่านรายละเอียดต่อได้ที่ Work Order Barcode คืออะไร และ การติดตามการผลิตด้วย Barcode
เชื่อม Barcode กับ ERP, WMS หรือระบบผลิต
เป้าหมายของการเชื่อมระบบไม่ใช่ส่งค่าที่สแกนได้เข้า API ทุกครั้งอย่างเดียว แต่คือทำให้เหตุการณ์มีความหมายสอดคล้องกันในทุกระบบ ควรตกลงอย่างน้อยว่าใครเป็นเจ้าของ master data ของสินค้า/ล็อต ระบบใดออกเลข Batch ระบบใดอนุมัติสถานะ และจะจัดการอย่างไรเมื่ออุปกรณ์หน้างานออฟไลน์
ตารางด้านล่างเป็นตัวอย่างขอบเขตความรับผิดชอบที่ควรหารือก่อนพัฒนา:
| ส่วนงาน | ความรับผิดชอบที่ควรกำหนด | ตัวอย่างการตรวจสอบ |
|---|---|---|
| ERP | คำสั่งผลิต รายการสินค้า และสถานะธุรกรรมหลัก | ไม่สร้าง Batch ซ้ำในเอกสารเดียวกัน |
| WMS | ตำแหน่งคงคลัง การย้าย การหยิบ และการจอง | ไม่ย้ายล็อตที่ถูก hold ไปยังตำแหน่งพร้อมจ่าย |
| MES/แอปหน้างาน | เหตุการณ์ผลิต การตัดใช้ และผลตรวจ | ทุก event มีเวลา จุดงาน และผู้ปฏิบัติงาน |
| Barcode service | การอ่าน แปลรหัส และตรวจรูปแบบข้อมูล | แจ้งเตือนเมื่อรหัสไม่ครบหรือไม่ตรงกับสินค้า |
| Integration/API | การส่งข้อมูล การตอบกลับ และการ retry | ป้องกัน event ซ้ำด้วย event ID หรือ idempotency key |
หากต้องสร้างแอปเชื่อมอุปกรณ์กับระบบเดิม ควรทำ pilot โดยใช้ข้อมูลจริงจำนวนจำกัดก่อน: ทดสอบการสแกนซ้ำ เน็ตหลุด การพิมพ์ label ซ้ำ การยกเลิกรายการ และการย้อนสถานะ ไม่ควรถือว่า API เชื่อมสำเร็จแล้วแปลว่า traceability สำเร็จโดยอัตโนมัติ
ประโยชน์ที่วัดได้และข้อจำกัด
เมื่อข้อมูลครบ ระบบช่วยให้ทีมลดเวลาค้นหาต้นทางและปลายทางของล็อต แยกพื้นที่/สินค้าที่ต้องกักกันได้แคบลง และตรวจสอบความสอดคล้องระหว่างเอกสารกับสินค้าหน้างานได้ดีขึ้น ประโยชน์เหล่านี้จะเกิดขึ้นได้เมื่อ label อ่านได้จริงและพนักงานสแกน ณ จุดที่กำหนดอย่างสม่ำเสมอ
ข้อจำกัดสำคัญคือ Batch Tracking ไม่สามารถสร้างประวัติที่ไม่เคยถูกบันทึกได้ หากมีการเบิกวัตถุดิบโดยไม่สแกน หรือมีการนำล็อตมารวมกันโดยไม่ลงเหตุการณ์ ข้อมูลหลังจากนั้นจะมีช่องว่าง นอกจากนี้ การใช้ล็อตเดียวกับสินค้าที่แยกไปหลายที่ช่วยตอบได้ในระดับกลุ่ม แต่ไม่เทียบเท่าการติดตามรายชิ้นแบบ Serial
ข้อผิดพลาดและ checklist ก่อนเริ่ม
ข้อผิดพลาดที่พบบ่อย
- กำหนดรูปแบบเลขล็อตในแต่ละแผนกไม่เหมือนกัน หรืออนุญาตให้ออกเลขซ้ำโดยไม่มีขอบเขตสินค้า/โรงงาน
- พิมพ์ label ใหม่โดยไม่เก็บความสัมพันธ์กับ label เดิม ทำให้สแกนเจอล็อตแต่ค้นหาต้นทางไม่ได้
- ให้ผู้ใช้พิมพ์เลขล็อตยาว ๆ แทนการสแกนโดยไม่มี validation
- เก็บเฉพาะสถานะปัจจุบัน แล้ว overwrite ประวัติ event เดิม
- เลือก scanner หรือ media label โดยไม่ได้ทดสอบกับพื้นผิว ความเร็วงาน และสภาพแวดล้อมจริง
- ออกแบบรายงานก่อนกำหนด data contract ของเหตุการณ์ จึงมีข้อมูลหน้าตาคล้ายกันแต่ใช้ค้นหาร่วมกันไม่ได้
Checklist สำหรับ pilot
- นิยาม Batch/Lot, Serial, สินค้า และหน่วยบรรจุเป็นลายลักษณ์อักษร
- ระบุ Critical Tracking Events และผู้รับผิดชอบแต่ละจุด
- กำหนดฟิลด์บังคับของเหตุการณ์ รวมถึงเวลา สถานที่ และเอกสารอ้างอิง
- ทดสอบ label และ scanner กับสินค้า/บรรจุภัณฑ์จริง
- ทดสอบการรวมล็อต แยกล้อต กักกัน ปล่อยใช้ และแก้ไขรายการตามสิทธิ์
- ทดสอบ backward trace และ forward trace ด้วยล็อตที่จำลองปัญหา
- วัดเวลา ความครบถ้วนของผลค้นหา และรายการที่ต้องตรวจสอบด้วยมือ
- วางแผน integration กับ ERP, WMS หรือระบบผลิตโดยมีเจ้าของข้อมูลชัดเจน
FAQ
Batch Tracking ต่างจากการนับสต็อกอย่างไร
การนับสต็อกตอบปริมาณของสินค้า ส่วน Batch Tracking ผูกปริมาณนั้นกับล็อต เหตุการณ์ สถานที่ และความสัมพันธ์กับต้นทาง/ปลายทาง จึงใช้ค้นหาผลกระทบของล็อตหนึ่งได้
ต้องใช้ QR Code เสมอหรือไม่
ไม่จำเป็น รูปแบบบาร์โค้ดต้องเลือกจากข้อมูลที่ต้องเข้ารหัส ความสามารถของเครื่องพิมพ์/สแกนเนอร์ และระบบปลายทาง บาง workflow ใช้ 1D ได้เพียงพอ บาง workflow ต้องการข้อมูลแบบ 2D หรือการอ้างอิงข้อมูลจากระบบ
Batch Number ควรสร้างจากวันที่ผลิตหรือไม่
วันที่อาจเป็นส่วนหนึ่งของกติกาได้ แต่ไม่ควรเป็นข้อเดียวที่ทำให้ล็อตไม่ซ้ำ ควรออกแบบให้รองรับหลายไลน์ผลิต หลายกะ การผลิตซ้ำ และกรณีแก้ไขตามนโยบายควบคุมข้อมูลขององค์กร
ถ้าพบสินค้ามีปัญหาหนึ่งล็อต ระบบควรทำอะไร
เริ่มจากเปลี่ยนสถานะล็อตตามขั้นตอนอนุมัติ แล้วใช้ backward trace เพื่อค้นหาวัตถุดิบ/เหตุการณ์ต้นทาง และ forward trace เพื่อค้นหาสินค้าสำเร็จรูป คลัง และเอกสารส่งมอบที่เกี่ยวข้อง การดำเนินการจริงต้องอยู่ภายใต้นโยบายคุณภาพและกฎระเบียบของธุรกิจนั้น
ใช้มือถือแทน Scanner ได้หรือไม่
ทำได้ในบางกรณี แต่ควรทดสอบความเร็ว ความเสถียรของการอ่าน label คุณภาพการเชื่อมต่อ และการใช้งานระหว่างสวมถุงมือหรือทำงานต่อเนื่อง หาก workflow มีปริมาณสูงหรือสภาพแวดล้อมเฉพาะ อุปกรณ์อุตสาหกรรมอาจเหมาะกว่า
ต้องเปลี่ยน ERP ทั้งระบบหรือไม่
ไม่จำเป็นเสมอไป หลายโครงการเริ่มจากเสริมการรับข้อมูลผ่าน Barcode และเชื่อมกับระบบเดิม แต่ต้องสำรวจ API, ขอบเขตข้อมูล, สิทธิ์ และวิธีจัดการข้อผิดพลาดก่อนตัดสินใจ
สรุปและแนวทางเริ่มต้น
Batch Tracking ด้วย Barcode จะช่วยให้ข้อมูลล็อตเดินทางพร้อมสินค้าก็ต่อเมื่อองค์กรกำหนดรหัส เหตุการณ์ และความสัมพันธ์ของข้อมูลอย่างชัดเจน เริ่มจาก workflow ที่มีความเสี่ยงสูงที่สุด วางจุดสแกนที่ตอบการตัดสินใจ แล้วทดลองค้นหาย้อนกลับทั้งสองทิศทางด้วยข้อมูลจริงก่อนขยายผล
หากองค์กรกำลังวางระบบติดตามล็อตหรือ Traceability Arc Tech สามารถช่วยสำรวจ Requirement ออกแบบ workflow และประเมินแนวทางเชื่อม Barcode Scanner เครื่องพิมพ์ label และระบบ ERP/WMS เดิมให้เหมาะกับกระบวนการทำงานจริงได้ ติดต่อ Arc Tech เพื่อเริ่มจากการวิเคราะห์จุดรับเข้า ผลิต และส่งมอบที่สำคัญของหน้างาน



