Serial Number Tracking ในโรงงาน: ออกแบบข้อมูลและจุดสแกนให้ตามสินค้ารายชิ้นได้จริง
เมื่อโรงงานต้องตอบคำถามว่า สินค้าชิ้นนี้ผลิตเมื่อไร ใช้วัตถุดิบหรือชิ้นส่วนใด ผ่านสถานีไหน และอยู่ที่ใดในเวลานี้ การมีเพียงรหัสสินค้า SKU หรือเลขล็อตอาจยังไม่พอ ระบบ Serial Number Tracking ในโรงงาน คือการกำหนดตัวตนที่ไม่ซ้ำให้สินค้าหรือชิ้นส่วนแต่ละชิ้น แล้วบันทึกเหตุการณ์สำคัญตั้งแต่เริ่มผลิตจนถึงส่งมอบ เพื่อค้นหาประวัติระดับชิ้นได้โดยไม่ต้องไล่หาเอกสารหลายระบบ
คำตอบสั้น ๆ คือ Serial Number Tracking ไม่ได้เริ่มจากซื้อเครื่องสแกน แต่เริ่มจากการนิยามว่าอะไรคือหน่วยที่ต้องตามรอย กำหนดรหัสที่ไม่ซ้ำ กำหนดเหตุการณ์ที่ต้องบันทึก และออกแบบให้ผู้ปฏิบัติงานสแกนในจุดที่ระบบจะใช้ตัดสินใจจริง จากนั้นจึงเชื่อมข้อมูลกับ Work Order, BOM, QC, คลังสินค้า และการจัดส่งตามความเหมาะสม
ประเด็นสำคัญที่ควรรู้
- Serial number เหมาะเมื่อธุรกิจต้องแยกประวัติของสินค้าแต่ละชิ้น ไม่ใช่แค่ระบุว่าอยู่ในล็อตใด
- รหัสที่ไม่ซ้ำเพียงอย่างเดียวไม่ทำให้ตามรอยได้ ต้องมี event เช่น สร้างรหัส ประกอบ ผ่าน QC ย้ายสถานะ แพ็ก และส่งมอบ
- เลือกจุดสแกนจากจุดที่สถานะหรือความรับผิดชอบเปลี่ยน ไม่ใช่วางเครื่องสแกนทุกจุดของสายการผลิต
- ต้องกำหนดกติกากันข้อมูลซ้ำ สแกนผิด และการทำงานออฟไลน์ตั้งแต่ pilot เพื่อไม่ให้ประวัติสินค้าแตกเป็นหลายเส้นทาง
- Serial, batch/lot และ Work Order มักต้องใช้ร่วมกัน โดยเลือกความละเอียดตามความเสี่ยงของสินค้า กระบวนการรับประกัน และต้นทุนการเก็บข้อมูล
สารบัญ
- Serial Number Tracking คืออะไร
- ต่างจาก SKU, batch และ Work Order อย่างไร
- ข้อมูลและเหตุการณ์ที่ควรเก็บ
- ออกแบบ barcode และจุดสแกน
- Workflow ตัวอย่างในโรงงาน
- การเชื่อม ERP, MES, WMS และ QC
- ข้อจำกัด ความเสี่ยง และเกณฑ์เลือกใช้
- Checklist สำหรับ pilot
Serial Number Tracking คืออะไร
Serial Number Tracking คือระบบที่ทำให้สินค้าหรือชิ้นส่วนแต่ละหน่วยมีตัวระบุเฉพาะหนึ่งค่า แล้วเชื่อมตัวระบุนั้นกับข้อมูลหลักและเหตุการณ์ของหน่วยนั้นตลอดวงจรงาน เช่น การออกจากไลน์ การตรวจคุณภาพ การประกอบ การซ่อม การพักสินค้า การรับเข้าคลัง และการส่งออก จุดประสงค์ไม่ใช่เพียงนับจำนวน แต่คือทำให้ค้นหาประวัติและสถานะของ “ชิ้นนี้” ได้อย่างมีหลักฐาน
มาตรฐาน GS1 อธิบายระดับการระบุตัวตนไว้ชัดเจน: ระดับสินค้าเป็นการแยกชนิดสินค้า ระดับ batch/lot แยกกลุ่มสินค้าที่มีเงื่อนไขร่วมกัน และระดับ instance หรือ serialised identification แยกสินค้าทีละชิ้น การเลือกระดับควรขึ้นกับเป้าหมาย traceability และความเสี่ยง ไม่ควร serialise ทุกอย่างเพียงเพราะทำได้ อ่านพื้นฐาน Traceability เพื่อเห็นภาพระดับข้อมูลก่อนเริ่มออกแบบ
ในบริบทโรงงาน Serial Number Tracking มักให้คำตอบ 4 กลุ่มพร้อมกัน
- ตัวตน: รหัสนี้แทนสินค้า รุ่น และ revision ใด
- ประวัติการผลิต: ถูกผลิตตาม Work Order ไหน ผ่านสถานีหรือขั้นตอนใด เมื่อไร และโดยใครหรือเครื่องใด
- genealogy: ใช้วัตถุดิบ ชิ้นส่วน หรือ sub-assembly หมายเลขใดบ้าง และถูกบรรจุรวมกับสิ่งใด
- สถานะปัจจุบัน: ผ่าน QC แล้วหรือไม่ อยู่ใน hold, rework, WIP, คลัง หรืออยู่ระหว่างส่งมอบ
การมีคำตอบเหล่านี้ช่วยให้ทีม QC, ผลิต, คลัง และบริการหลังการขายใช้ข้อเท็จจริงชุดเดียวกัน แต่ผลลัพธ์จะน่าเชื่อถือเท่ากับความครบถ้วนของเหตุการณ์ที่บันทึกเท่านั้น
ต่างจาก SKU, batch และ Work Order อย่างไร
หลายโครงการล้มเหลวตั้งแต่แรกเพราะใช้คำว่า “รหัสสินค้า” ปนกัน จึงควรกำหนดหน้าที่ของรหัสแต่ละชนิดให้ชัดก่อนออกแบบ label และฐานข้อมูล
| รหัส | ตอบคำถามหลัก | ความละเอียด | ตัวอย่างการใช้งาน |
|---|---|---|---|
| SKU หรือ Item Code | เป็นสินค้าแบบใด | ระดับรุ่น/ชนิด | แยกเครื่องรุ่น A กับรุ่น B |
| Batch/Lot | อยู่ในกลุ่มการผลิตหรือเงื่อนไขใด | ระดับกลุ่ม | ควบคุมวัตถุดิบหรือสินค้าที่ผลิตช่วงเดียวกัน |
| Work Order | ทำงานตามคำสั่งผลิตใด | ระดับคำสั่งงาน | ผูกแผน ผลิตจริง และปริมาณ |
| Serial Number | เป็นชิ้นใดโดยเฉพาะ | ระดับชิ้น | ตรวจประวัติ เครื่องเดียว การรับประกัน หรือการซ่อม |
ตัวอย่างเช่น สินค้ารุ่นเดียวกัน 100 ชิ้นอาจผลิตภายใต้ Work Order เดียวและ batch เดียว แต่แต่ละชิ้นมี serial ไม่ซ้ำกัน หากพบข้อบกพร่องใน serial หนึ่งชิ้น ทีมงานจึงค้นหา test result, operator, สถานี และชิ้นส่วนที่ประกอบอยู่ภายในได้ โดยไม่ต้องกักทั้งล็อตเสมอไป ในทางกลับกัน หากความเสี่ยงเกิดในวัตถุดิบล็อตเดียว การเก็บ batch/lot ยังคงจำเป็นแม้สินค้าสำเร็จรูปจะมี serial แล้ว
บทความ Batch Tracking ด้วย Barcode อธิบายมุมมองระดับล็อต ส่วนบทความนี้เน้นการสร้างประวัติรายชิ้นและความสัมพันธ์แบบ parent-child จึงควรออกแบบสองส่วนให้ใช้ร่วมกัน ไม่ใช่เลือกอย่างใดอย่างหนึ่งโดยอัตโนมัติ
ข้อมูลและเหตุการณ์ที่ควรเก็บ
1. Master data ของ serial
ก่อนพิมพ์ label ระบบควรมีข้อมูลขั้นต่ำที่เชื่อม serial กับสินค้าและบริบทการผลิต เช่น serial_number, item code, item revision, unit of measure, สถานะเริ่มต้น, Work Order, วันที่สร้าง และแหล่งที่ออกเลขรหัส สำหรับสินค้าที่ต้องเก็บประวัติการซ่อมหรือการรับประกัน อาจต้องมีวันที่เริ่มรับประกัน เงื่อนไขบริการ หรือรุ่น firmware แต่ควรเพิ่มเฉพาะข้อมูลที่มีเจ้าของและมีขั้นตอนอัปเดตชัดเจน
อย่าสร้าง serial จากวันเวลาอย่างเดียวหากมีหลายไลน์หรือมีการทำงานออฟไลน์ เพราะอาจชนกันได้ ควรมีผู้รับผิดชอบการออกเลขที่ชัดเจน อาจเป็นระบบกลาง ช่วงเลขที่จองไว้ล่วงหน้า หรือรูปแบบรหัสที่มีตัวตรวจสอบตามความเหมาะสม ที่สำคัญคือระบบต้องตรวจ uniqueness ก่อนยืนยันการใช้งาน ไม่ใช่หวังพึ่งการอ่านด้วยตา
2. Event data: หลักฐานที่ทำให้ตามรอยได้
ทุกการสแกนไม่จำเป็นต้องเป็น event ที่มีคุณค่า เลือกเก็บเฉพาะจุดที่ตอบคำถามการปฏิบัติงานหรือความเสี่ยงได้จริง เช่น
| เหตุการณ์ | ข้อมูลสำคัญ | เหตุผลที่ควรบันทึก |
|---|---|---|
| serial issued / label printed | serial, item, source, timestamp | ป้องกันการใช้เลขซ้ำและตรวจ label ที่พิมพ์ผิด |
| component attached | serial สินค้าหลัก, serial/lot ชิ้นส่วน, station | สร้าง genealogy ของชิ้นงาน |
| operation completed | Work Order, operation, station, operator/device | ยืนยันความคืบหน้าและเส้นทางการผลิต |
| QC passed / failed | test type, result, reason code, attachment reference | แยกสินค้าใช้ได้, hold และ rework |
| packed / aggregated | serial ลูก, carton/pallet หรือ shipment | รักษาความสัมพันธ์เมื่อรวมบรรจุภัณฑ์ |
| shipped / returned / serviced | destination, transaction, timestamp | เชื่อมการผลิตกับหลังการขาย |
มาตรฐาน traceability ของ GS1 ใช้แนวคิด Critical Tracking Events และ Key Data Elements: ต้องรู้ก่อนว่าเหตุการณ์ใดสำคัญต่อการติดตาม และข้อมูลใดทำให้เหตุการณ์นั้นมีความหมาย ในระบบจริง ควรบังคับ schema ของ event มากกว่ารับข้อความอิสระ เช่น reason code สำหรับ reject หรือ station code ที่มาจาก master data เพื่อให้ค้นหาและรายงานได้สม่ำเสมอ
3. กติกาสถานะและความถูกต้องของลำดับเหตุการณ์
การเก็บประวัติแบบต่อท้ายอย่างเดียวอาจทำให้สินค้า “ผ่าน QC” ทั้งที่ยังไม่เคยเริ่มผลิต ควรกำหนด state transition ที่ตรวจได้ เช่น NEW → IN_PROCESS → QC_PENDING → PASS/HOLD/REWORK → PACKED → SHIPPED แล้วให้ระบบปฏิเสธหรือขอสิทธิ์เพิ่มเมื่อเกิดเหตุการณ์ข้ามลำดับ
สำหรับจุดสแกนที่เครือข่ายไม่เสถียร แอปมือถือหรือ handheld ควรเก็บ event ในเครื่องพร้อมรหัสคำขอที่ไม่ซ้ำ เมื่อเชื่อมต่อได้จึงส่งซ้ำอย่างปลอดภัย ฝั่ง server ต้องทำ idempotency เพื่อให้การกดส่งซ้ำหรือการ reconnect ไม่สร้าง event ซ้ำสองครั้ง แนวคิดนี้สำคัญกว่าความเร็วของหน้าจอ เพราะข้อมูล genealogy ที่ซ้ำหรือหายจะย้อนแก้ยากมาก
ออกแบบ barcode และจุดสแกน
เลือกข้อมูลก่อนเลือกรูปแบบ barcode
ไม่จำเป็นต้องใส่ข้อมูลทุกอย่างลงในสัญลักษณ์ barcode เสมอไป แนวทางที่ดูแลง่ายคือให้ barcode บรรจุ serial หรือ key ที่อ่านได้ แล้วให้ระบบดึงข้อมูลปัจจุบันจากฐานข้อมูล หากต้องใช้ข้อมูลแบบ dynamic หลายค่าใน label เดียว เช่น item, lot, serial หรือวันหมดอายุ ให้กำหนด data contract และ scanner parsing rules ร่วมกันก่อนเลือก symbology
ข้อมูลที่ควรระบุบน label แบบอ่านด้วยคนได้คือ item/รุ่น, serial, lot เมื่อเกี่ยวข้อง, วันที่พิมพ์ และ revision ของ label ไม่ควรพิมพ์ข้อมูลภายในที่เปลี่ยนบ่อยจน label กลายเป็นต้นตอของข้อมูลไม่ตรงกัน การตัดสินใจระหว่าง 1D, 2D หรือ RFID ควรอิงปริมาณข้อมูล สภาพพื้นผิว ระยะอ่าน ความเร็วของไลน์ และความสามารถของอุปกรณ์ ไม่ใช่ชื่อเทคโนโลยีเพียงอย่างเดียว ดูเกณฑ์เพิ่มได้จาก Barcode 1D vs 2D
วางจุดสแกนที่เปลี่ยนการตัดสินใจ
จุดสแกนที่ดีคือจุดที่เมื่อไม่สแกนแล้วระบบจะไม่รู้สถานะสำคัญ ไม่ใช่ทุกโต๊ะในไลน์ เริ่มจากแผนผังการไหลจริง แล้วทำเครื่องหมายจุดเปลี่ยนเจ้าของ จุดที่เกิดการประกอบ จุด QC จุด hold/rework จุดรวมบรรจุภัณฑ์ และจุดส่งออก จากนั้นให้ผู้ปฏิบัติงานทดลองสแกนตามลำดับงานจริงเพื่อดูว่ามีขั้นตอนใดเพิ่มภาระโดยไม่เพิ่มคุณค่าหรือไม่
โรงงานควรทดสอบ label กับวัสดุจริง แสงจริง ฝุ่น ความชื้น รอยโค้ง และระยะทำงานจริงก่อนสรุปชนิดเครื่องสแกน บทความ ข้อกำหนด Scanner สำหรับโรงงาน ช่วยตั้งคำถามเรื่องระยะอ่าน ความทนทาน และการเชื่อมต่อ โดยการเลือกอุปกรณ์ควรทำหลัง data contract และ workflow ชัดเจนแล้ว
Workflow ตัวอย่างในโรงงาน
ตัวอย่างนี้เป็นสายประกอบสินค้าที่ต้องให้บริการหลังการขายรายเครื่อง ไม่ใช่สูตรสำเร็จสำหรับทุกโรงงาน
- เปิดคำสั่งผลิต: ERP หรือระบบผลิตสร้าง Work Order พร้อมรุ่น จำนวน และ revision ที่อนุญาต ระบบจองช่วง serial หรือสร้าง serial ตามกติกา
- พิมพ์และยืนยัน label: พิมพ์ label ที่สถานีควบคุม จากนั้นสแกนทวนหนึ่งครั้งก่อนติดกับชิ้นงานเพื่อยืนยันว่า serial เชื่อมกับ item และ Work Order ถูกต้อง
- ประกอบชิ้นส่วนสำคัญ: ที่จุดประกอบ ผู้ปฏิบัติงานสแกน serial ของสินค้าหลักและ serial หรือ lot ของ component ที่มีความเสี่ยงสูง ระบบตรวจ BOM/revision และบันทึก parent-child relationship
- บันทึกผลทดสอบ: สถานี QC เรียก serial เดิม แสดง test plan ที่สอดคล้องกับรุ่น แล้วบันทึก pass/fail, reason code, ค่าที่วัดได้หรือ reference ของไฟล์ทดสอบ หาก fail ให้เปลี่ยนสถานะเป็น hold หรือ rework แทนการปล่อยไปขั้นถัดไป
- บรรจุและรวมหน่วย: สแกน serial สินค้าเข้า carton หรือ pallet เพื่อสร้างความสัมพันธ์กับกล่อง/พาเลต การแกะออกหรือบรรจุใหม่ต้องเป็น event แยก ไม่ควรแก้ข้อมูลเดิมทับ
- รับเข้าคลังและส่งมอบ: WMS หรือระบบจัดส่งยืนยัน serial ที่รับเข้าและ serial ที่ออกในเอกสารส่งมอบ เพื่อให้ค้นหาย้อนจากลูกค้าไปยังประวัติการผลิตได้
เมื่อมีเคสคุณภาพ เช่น serial หนึ่งชิ้นถูกส่งกลับ ทีมงานควรเริ่มจาก serial นั้นแล้วถามย้อนขึ้นไปว่าใช้ component ใดร่วมกันบ้าง ผ่าน test station ใด และมีสินค้าชิ้นอื่นที่มีเงื่อนไขเดียวกันหรือไม่ ซึ่งต่างจาก Production Tracking ด้วย Barcode ที่เน้นความคืบหน้าของงานผลิตภาพรวมมากกว่า genealogy รายชิ้น
การเชื่อม ERP, MES, WMS และ QC
การเชื่อมระบบไม่จำเป็นต้องทำทุกอย่างพร้อมกัน แต่ต้องกำหนดว่าระบบใดเป็นเจ้าของข้อมูลแต่ละประเภท
| ข้อมูลหรือการตัดสินใจ | เจ้าของข้อมูลที่พบบ่อย | สิ่งที่ระบบ Serial Tracking ควรทำ |
|---|---|---|
| Item, revision, BOM, Work Order | ERP หรือ MES | อ้างอิงและตรวจสิทธิ์การผลิต |
| จุดปฏิบัติงานและ event หน้างาน | แอป production หรือ MES | รับ scan event พร้อม validation |
| ผล QC และการอนุมัติ | QMS หรือโมดูล QC | บันทึกผล/สถานะและ reference อย่างมี audit trail |
| คงคลังและตำแหน่ง | WMS | รับเข้า ย้าย จ่าย และตรวจสถานะพร้อม serial |
| ประวัติบริการ | Service system | เรียก genealogy และเพิ่ม return/repair event |
เริ่มด้วย integration ขนาดเล็กที่มี contract ชัดเจน เช่น API สำหรับตรวจว่า Work Order เปิดอยู่หรือไม่ และ API สำหรับส่งสถานะ QC แทนการเขียนฐานข้อมูลข้ามระบบโดยตรง ทุก event ควรมี event_id, serial, event type, occurred_at, source device/user และ reference transaction เพื่อให้ตรวจสอบซ้ำได้
การเชื่อม Work Order สำคัญเป็นพิเศษ เพราะทำให้ serial ไม่เป็นเพียงเลขบน label บทความ Work Order Barcode คืออะไร ช่วยอธิบายการใช้รหัสคำสั่งงานเป็นจุดเชื่อมระหว่างแผนการผลิตกับข้อมูลหน้างาน เมื่อโรงงานมี WMS, ERP หรือ application เดิมอยู่แล้ว Arc Tech สามารถช่วยวิเคราะห์ workflow, ออกแบบ data contract และเชื่อม handheld, scanner, printer กับระบบที่มีอยู่ได้หลังประเมิน requirement และข้อจำกัดของแต่ละระบบ
ประโยชน์ที่คาดหวังและตัวชี้วัดที่ควรวัด
Serial Tracking ที่ออกแบบดีช่วยให้ทีมค้นหาประวัติชิ้นงานเร็วขึ้น ลดการคีย์เลขผิด และจำกัดขอบเขตการตรวจสอบเมื่อมีปัญหาคุณภาพ แต่ไม่ควรตั้งเป้าผลลัพธ์เป็นเปอร์เซ็นต์ตายตัวก่อน pilot เพราะขึ้นกับ baseline, วินัยการสแกน, คุณภาพ label และความพร้อมของข้อมูลเดิม
แทนที่จะวัดคำโฆษณา ให้ตั้ง acceptance criteria ที่ตรวจได้ เช่น
- ค้นหาประวัติจาก serial ที่ทดสอบได้ภายในเวลาที่ตกลงกัน พร้อม Work Order, สถานะ QC และ component/lot ที่กำหนด
- ระบบปฏิเสธ serial ที่ไม่มีอยู่ สถานะไม่อนุญาต หรือ component ที่ไม่ตรงกับ BOM/revision ตาม rule ที่ตั้งไว้
- event ที่ส่งซ้ำจาก handheld ไม่สร้างรายการซ้ำ และรายการออฟไลน์กลับเข้าสู่ระบบตามลำดับที่ตรวจสอบได้
- สุ่มตรวจสินค้าระหว่าง WIP/คลัง/จัดส่งแล้ว label อ่านได้ด้วยอุปกรณ์ที่เลือกในสภาพหน้างาน
- ทีม QC และผลิตตอบคำถาม trace-back และ trace-forward จากชุดทดสอบเดียวกันได้ผลตรงกัน
ข้อจำกัด ความเสี่ยง และเกณฑ์เลือกใช้
เมื่อ serialisation อาจเกินความจำเป็น
สินค้าอุปโภคบริโภคปริมาณมากที่ไม่มีข้อกำหนดรายชิ้น อาจได้ประโยชน์จาก lot tracking มากกว่า serial tracking รายชิ้น เพราะการพิมพ์ ตรวจ และเก็บ event ทุกหน่วยมีต้นทุน หากเป้าหมายคือจัดการ recall ตามล็อตหรือควบคุมวันหมดอายุ การทำ batch/lot ให้ครบก่อนอาจคุ้มกว่า
ความเสี่ยงที่มักถูกมองข้าม
- label ไม่ทนสภาพงาน: serial อยู่ในฐานข้อมูลแต่อ่านไม่ได้หน้างาน ต้องทดสอบวัสดุ กาว ริบบอน และตำแหน่งติดจริง
- ข้อมูลต้นทางไม่ตรง: item revision หรือ BOM เปลี่ยนโดยไม่มีการควบคุม ทำให้ validation ให้ผลผิด
- ยอมให้ override ง่ายเกินไป: ผู้ใช้ข้ามสถานะ QC ได้โดยไม่มีเหตุผลหรือ audit trail
- integration แบบไม่มี retry contract: เครือข่ายหลุดแล้ว event หาย หรือส่งซ้ำเป็นสองรายการ
- สแกนเพื่อเก็บข้อมูลแต่ไม่ใช้ตัดสินใจ: ภาระเพิ่มแต่ไม่มีเจ้าของรายงานหรือการแก้ปัญหา
ก่อนลงทุนเพิ่มอุปกรณ์ ควรทดลองด้วย กลุ่มสินค้า Scanner ของ Arc Tech ที่เหมาะกับสภาพงานจริง และทดสอบกับ label/ระยะอ่านของโรงงาน ไม่ควรสรุปความเข้ากันได้จากสเปกบนกระดาษเพียงอย่างเดียว
Checklist สำหรับ pilot
ขอบเขตธุรกิจ
- เลือกสินค้าหนึ่งรุ่นหรือหนึ่ง Work Order ที่มีเหตุผลชัดว่าต้องตามรายชิ้น
- ระบุคำถาม trace-back และ trace-forward ที่ pilot ต้องตอบได้
- กำหนดว่า serial, lot และ Work Order เชื่อมกันอย่างไร
- ระบุผู้รับผิดชอบของ master data, label, QC result และการแก้ exception
ข้อมูลและระบบ
- ตรวจ uniqueness ของ serial และกติกาการออกเลขก่อนเริ่มใช้งานจริง
- ระบุ state transition, reason code และสิทธิ์การ override
- กำหนด event schema, device/user identifier, timestamp และ idempotency key
- ทดสอบกรณี offline, duplicate scan, scan ผิดรุ่น, rework, return และเปลี่ยน carton
- ระบุระบบเจ้าของข้อมูลและวิธี retry/reconcile เมื่อ API หรือ integration ขัดข้อง
หน้างานและอุปกรณ์
- ทดสอบ label บนวัสดุและสภาพแวดล้อมจริง รวมถึงรอยโค้ง ฝุ่น และแสง
- วัดเวลาการสแกนเทียบกับ takt time และปรับหน้าจอให้เหลือข้อมูลที่ผู้ใช้ต้องตัดสินใจ
- เตรียมขั้นตอน fallback เมื่อ scanner หรือ printer หยุดทำงาน โดยไม่เปิดช่องให้ใช้ serial ซ้ำ
- ฝึกทีมผลิต QC คลัง และ IT ด้วยตัวอย่างเหตุการณ์เดียวกัน
คำถามที่พบบ่อย
Serial Number Tracking ต่างจากการนับสต็อกอย่างไร
การนับสต็อกตอบว่ามีสินค้ากี่หน่วยและอาจตอบว่ามีอยู่ที่ใด ส่วน Serial Number Tracking ระบุได้ว่าสินค้าหน่วยใดเป็นหน่วยใด พร้อมประวัติการผลิต คุณภาพ การย้าย และการส่งมอบ จึงเหมาะกับสินค้าที่ต้องตรวจสอบรายชิ้น การซ่อม หรือการรับประกัน
ต้องใช้ QR Code เสมอหรือไม่
ไม่จำเป็น รูปแบบสัญลักษณ์ควรตามข้อมูลที่ต้องเข้ารหัส พื้นที่บน label คุณภาพการพิมพ์ ระยะอ่าน และเครื่องสแกนที่ใช้ หาก barcode เก็บเพียง serial แล้วดึงข้อมูลจากระบบ 1D อาจเพียงพอในบางงาน แต่หากต้องใช้ข้อมูลหลายส่วนหรือมีพื้นที่จำกัด 2D อาจเหมาะกว่า ควรทดสอบจริงก่อนตัดสินใจ
ใช้ serial เดิมหลังสินค้ากลับมาซ่อมได้หรือไม่
โดยทั่วไปควรรักษา serial เดิมเพื่อให้ประวัติบริการเชื่อมกับประวัติการผลิตได้ แล้วเพิ่ม repair/return event ใหม่ใน audit trail ไม่ควรลบหรือเขียนทับเหตุการณ์เดิม หากมีการเปลี่ยนตัวสินค้าให้ลูกค้า ควรบันทึกความสัมพันธ์ระหว่าง serial เดิมและ serial ใหม่อย่างชัดเจน
Serial number ต้องเชื่อมกับ batch/lot ด้วยหรือไม่
บ่อยครั้งควรเชื่อมกัน เพราะ serial ให้ความละเอียดระดับชิ้น ขณะที่ lot ช่วยระบุชุดวัตถุดิบหรือเงื่อนไขร่วมกัน เมื่อมีปัญหาคุณภาพ ทีมงานจึงเริ่มจาก serial หนึ่งชิ้นแล้วขยายไปยังชิ้นอื่นที่ใช้ lot เดียวกันได้ อย่างไรก็ดี ฟิลด์และกติกาที่แน่นอนควรเลือกตาม risk assessment ของสินค้า
เริ่ม pilot โดยไม่เปลี่ยน ERP ทั้งระบบได้หรือไม่
ได้ในหลายกรณี หากระบุขอบเขตและ integration contract ชัดเจน อาจเริ่มจาก serial registry และ scan event application ที่ตรวจ Work Order จาก ERP และส่งสถานะ QC กลับไปก่อน แล้วขยายไป WMS หรือ MES ภายหลัง วิธีนี้ต้องกำหนด source of truth และขั้นตอน reconcile ให้ชัดเพื่อไม่ให้เกิดข้อมูลซ้ำหรือขัดกัน
ข้อมูลจาก handheld ต้องทำงานออฟไลน์อย่างไร
แอปควรเก็บ event ในเครื่องพร้อม event ID หรือ idempotency key ที่ไม่ซ้ำ แสดงสถานะว่าอะไรยังไม่ได้ส่ง และซิงก์เมื่อเชื่อมต่อได้ ฝั่งรับข้อมูลต้องประมวลผลซ้ำอย่างปลอดภัยและรายงานรายการที่ขัดกับกติกา การเก็บ offline โดยไม่มีการ reconcile มีความเสี่ยงให้ genealogy ขาดช่วง
สรุปและแนวทางเริ่มต้น
Serial Number Tracking ที่ใช้งานได้จริงคือการผสานรหัสเฉพาะต่อชิ้นกับ event ที่มีความหมาย, data contract ที่ตรวจสอบได้ และจุดสแกนที่สอดคล้องกับงานจริง ไม่ใช่เพียงติด barcode เพิ่มหนึ่งดวง โรงงานควรเริ่มจากสินค้าและ Work Order ที่มีความเสี่ยงหรือบริการหลังการขายชัดเจน ทดสอบ trace-back/trace-forward ด้วยข้อมูลจริง แล้วขยายเมื่อทีมใช้ข้อมูลนั้นแก้ปัญหาได้จริง
หากองค์กรกำลังวางระบบติดตามสินค้ารายชิ้น Arc Tech สามารถช่วยเก็บ requirement ออกแบบ workflow และเชื่อม scanner, handheld, barcode printer กับ ERP/WMS/MES หรือระบบเดิมได้ โดยประเมินความพร้อมของข้อมูล หน้างาน และข้อจำกัดการเชื่อมต่อก่อนกำหนดแนวทางพัฒนา
